Aqui na empresa júnior da faculdade nós estamos tentando definir um processo de desenvolvimento de software para padronizar o desenvolvimento.
O problema é que a maioria das metodologias que estudamos é muito rígida e, com certeza, não vai ser seguida por ninguém se a adotarmos. Também pensamos em usar XP mas achamos que a documentação gerada é muito pouca, e no nosso caso é interessante ter documentação para darmos continuidade a projetos de alunos que se formaram.
Alguém conhece algum processo que possa ser útil? Se não acharmos vamos ter que definir um próprio mesmo.
Tem uma falha muito comum no seu pensamento: achar que codigo nao eh documentacao. Codigo limpo, bem testado, refatorado e usado eh melhor do que qualquer chumaço de papel de 40kg.
Em um sistema bem escrito, nao é problema nenhum, por exemplo, fazer a engenharia reversa de um pacote pra ver o UML, entender o diagrama, jogar ele fora, mexer no codigo, refatorar de novo, e passar pra proxima tarefa
Se vc focar em um processo onde a regra numero 1 eh escrever codigo legivel, e a regra numero 2 eh manter esse codigo legivel, vc vai se surpreender com a pouca necessidade por texto corrido pra manter o conhecimento sobre o projeto rodando
[quote=“baiano_mg”]Aqui na empresa júnior da faculdade nós estamos tentando definir um processo de desenvolvimento de software para padronizar o desenvolvimento.
O problema é que a maioria das metodologias que estudamos é muito rígida e, com certeza, não vai ser seguida por ninguém se a adotarmos. Também pensamos em usar XP mas achamos que a documentação gerada é muito pouca, e no nosso caso é interessante ter documentação para darmos continuidade a projetos de alunos que se formaram.
Alguém conhece algum processo que possa ser útil? Se não acharmos vamos ter que definir um próprio mesmo.
Aguardo sugestões.
Grato[/quote]
Porque voce nao defini um processo de desenvolvimento misturando o melhor do XP com o RUP por exemplo ?
Aqui na empresa eu vou fazer um trabalho desse tipo, pois nos estamos reformulando o processo de desenvolvimento, basicamente eu estou com o mesmo problema que o seu.
Como o cv disse um codigo bem feito eh melhor do que 40kg de papel, mas ca entre nos, nao eh todo mundo que sabe fazer um codigo muito bom (poucos toman cuidado com isso) …
…e isso implora pra que alguem pergunte: e o que é código bom? Pelo que eu vi até hoje, muita gente acha que é só encher de javadoc, entulhar de pattern, e o código fica lindo. Outros acham que código bom é aquele que roda rápido, outros acham que código bom tem um nível elevado de abstração, outros acham…
Bom, enfim, o que é código bom pra vcs? Como vcs medem isso? Se vcs estao pensando em definir um processo que torne o codigo o principal produto dos projetos (que é o que a XP faz), então tá na hora de saber como medir a qualidade dele
…e isso implora pra que alguem pergunte: e o que é código bom? Pelo que eu vi até hoje, muita gente acha que é só encher de javadoc, entulhar de pattern, e o código fica lindo. Outros acham que código bom é aquele que roda rápido, outros acham que código bom tem um nível elevado de abstração, outros acham…
Bom, enfim, o que é código bom pra vcs? Como vcs medem isso? Se vcs estao pensando em definir um processo que torne o codigo o principal produto dos projetos (que é o que a XP faz), então tá na hora de saber como medir a qualidade dele ;)[/quote]
Para mim codigo bom, eh aquele que eh auto-explicativo, sao aplicadas corretamente tecnicas de refactoring e patterns, por exemplo tomamos como base uma classe Funcionario, com um metodo para calcular um salario :
// metodo ruim
public double calcular(....)
)
// metodo bom
public double calcularSalario(....)
Eh claro, no caso de uma linguagem orientada a objetos, a linguagem eh utilizada na forma OO e nao procedural, eh utilizado interfaces, etc. …
[quote=“douglasfs”][quote=“baiano_mg”]Aqui na empresa júnior da faculdade nós estamos tentando definir um processo de desenvolvimento de software para padronizar o desenvolvimento.
O problema é que a maioria das metodologias que estudamos é muito rígida e, com certeza, não vai ser seguida por ninguém se a adotarmos. Também pensamos em usar XP mas achamos que a documentação gerada é muito pouca, e no nosso caso é interessante ter documentação para darmos continuidade a projetos de alunos que se formaram.
Alguém conhece algum processo que possa ser útil? Se não acharmos vamos ter que definir um próprio mesmo.
Aguardo sugestões.
Grato[/quote]
Porque voce nao defini um processo de desenvolvimento misturando o melhor do XP com o RUP por exemplo ?
Aqui na empresa eu vou fazer um trabalho desse tipo, pois nos estamos reformulando o processo de desenvolvimento, basicamente eu estou com o mesmo problema que o seu.
Como o cv disse um codigo bem feito eh melhor do que 40kg de papel, mas ca entre nos, nao eh todo mundo que sabe fazer um codigo muito bom (poucos toman cuidado com isso) …[/quote]
Acho que a melhor solucao vai ser essa mesmo. Manter uma coisas boas do XP, como Pair Programming e Refactoring, mas colocar mais um pouco de documentacao e analise de requisitos. Tipo obrigar a ter o digrama das classes persistentes, o diagrama de classes e algum outro que seja simples e necessario. Mas isso ainda e so uma ideia. Ainda tenho que amadurecer bem essa ideia.
Ja que voce ta passando por uma situacao parecida, bem que a gente podia trocar umas ideias.
Falow (ignorem a falta de acentos no post, isso eh que eh teclado ruim)
[quote=“baiano_mg”][quote=“douglasfs”][quote=“baiano_mg”]Aqui na empresa júnior da faculdade nós estamos tentando definir um processo de desenvolvimento de software para padronizar o desenvolvimento.
O problema é que a maioria das metodologias que estudamos é muito rígida e, com certeza, não vai ser seguida por ninguém se a adotarmos. Também pensamos em usar XP mas achamos que a documentação gerada é muito pouca, e no nosso caso é interessante ter documentação para darmos continuidade a projetos de alunos que se formaram.
Alguém conhece algum processo que possa ser útil? Se não acharmos vamos ter que definir um próprio mesmo.
Aguardo sugestões.
Grato[/quote]
Porque voce nao defini um processo de desenvolvimento misturando o melhor do XP com o RUP por exemplo ?
Aqui na empresa eu vou fazer um trabalho desse tipo, pois nos estamos reformulando o processo de desenvolvimento, basicamente eu estou com o mesmo problema que o seu.
Como o cv disse um codigo bem feito eh melhor do que 40kg de papel, mas ca entre nos, nao eh todo mundo que sabe fazer um codigo muito bom (poucos toman cuidado com isso) …[/quote]
Acho que a melhor solucao vai ser essa mesmo. Manter uma coisas boas do XP, como Pair Programming e Refactoring, mas colocar mais um pouco de documentacao e analise de requisitos. Tipo obrigar a ter o digrama das classes persistentes, o diagrama de classes e algum outro que seja simples e necessario. Mas isso ainda e so uma ideia. Ainda tenho que amadurecer bem essa ideia.
Ja que voce ta passando por uma situacao parecida, bem que a gente podia trocar umas ideias.
Falow (ignorem a falta de acentos no post, isso eh que eh teclado ruim)[/quote]
Beleza, nos podemos trocar uma ideia, de preferencia no forum, assim todo mundo pode aprender com a nossa experiencia.
Logo logo vou comecar essa pesquisa de processos … :lol:
[quote=“baiano_mg”]Aqui na empresa júnior da faculdade nós estamos tentando definir um processo de desenvolvimento de software para padronizar o desenvolvimento.
[/quote]
Um bom comeco e padronizar o ambiente de desenvolvimento. Existe uma ferramenta que ajuda a fazer isto. Chama-se maven. Eu acho lindo O processo de devel deles esta documentado em
…e isso implora pra que alguem pergunte: e o que é código bom? Pelo que eu vi até hoje, muita gente acha que é só encher de javadoc, entulhar de pattern, e o código fica lindo. Outros acham que código bom é aquele que roda rápido, outros acham que código bom tem um nível elevado de abstração, outros acham…
Bom, enfim, o que é código bom pra vcs? Como vcs medem isso? Se vcs estao pensando em definir um processo que torne o codigo o principal produto dos projetos (que é o que a XP faz), então tá na hora de saber como medir a qualidade dele ;)[/quote]
Para mim codigo bom, eh aquele que eh auto-explicativo, sao aplicadas corretamente tecnicas de refactoring e patterns, por exemplo tomamos como base uma classe Funcionario, com um metodo para calcular um salario :
// metodo ruim
public double calcular(....)
)
// metodo bom
public double calcularSalario(....)
Eh claro, no caso de uma linguagem orientada a objetos, a linguagem eh utilizada na forma OO e nao procedural, eh utilizado interfaces, etc. …
Essa discussao pode ir longe … :)[/quote]
E os outros foristas ? Ninguem vai opinar sobre o que eh um codigo bom ?
Um código bom não é necessariamente simples… e também o que é simples para uns é complicado para outros.
Bom, tudo depende de alguma coisa…
Por exemplo, o código da biblioteca xvid eu considero um ótimo código, altamente portável para uma leva de SO’s, com ou sem otimizações específicas para cada processador, entre outras coisas… e tudo dentro do padrão Mpeg-4!
Eu não faço a mínima idéia do que ele faz internamente (quantização? I-frame? que que é isso?), mas por ser um código bom, eu consigo utilizá-lo em meus programas…
Na minha opinião código bom é mais ou menos isso: você inclui ele no começo (import), e basta alguns métodos pra fazer todo o trabalho! (Xvid tem 3 funções, se não me engano!) Na verdade, o que é simples é a utilização do código…
Eu acho que código bom…
:arrow: é fácil de ler. Principalmente com a ajuda de um editor com quebra automática de linha
:arrow: é fácil de usar. Principalmente se tem um javadoc da hora que nao te obriga a abrir o fonte
:arrow: é fácil de lembrar. Quando vc tem tres funcoes, ou sabe que todas as propriedades de um objeto comecao com “get”, vc nao tem que olhar nem o fonte e nem o javadoc toda hora.
Acho que foi o Dijkstra que falou que códigos sao escritos para ser lidos, e ocasionalmente executados por uma máquina… eu acho que eh 90% verdade…
:arrow: eh facil de testar: voce nao precisa de um ambiente complexo, container ou de nenhuma magica pra testar um determinado codigo.
:arrow: eh facil de mudar: as mudancas se refletem em poucos lugares, e mudar o funcionamento interno ou externo de um metodo ou classe estraga poucos outros lugares.
Na verdade isso nao eh um paradigma, eh uma proposicao. E eu discordo.
Eu diria que quanto mais responsabilidades uma classe tem, mais complexa ela fica.
Quanto mais coisas um método faz, mais complexo ele fica
Quanto mais elementos um laço manipula, mais complexo ele fica.
Isso tem a ver com invariantes, coisas que a gente não trabalha no mundo real. É raríssimo ver alguém que precisou disso, ou que escreveu um comentario no código sobre os invariantes usados.
Acho que a gente lida com invariantes, ao menos na cabeça, quando escreve testes. Por isso ficou tao popular o TDD, vc é obrigado a pensar no que fica constante e no que precisa ser sempre verdade em um determinado ponto do código.
Eu ia falar de novo sobre AOP mas o e-mail ia ficar muito comprido…
[quote=“dukejeffrie”]Eu diria que quanto mais responsabilidades uma classe tem, mais complexa ela fica.
Quanto mais coisas um método faz, mais complexo ele fica
Quanto mais elementos um laço manipula, mais complexo ele fica.[/quote]
:?: …e não é isso que determina se o código é mais generalista ou especialista?
:arrow: paradigma ou proposição… Acho que fui compreendido.
Eu estou trabalhando com o Praxis na materia Engenharia de Software 2 e acho que ele ainda eh muito burocratico para a nossa empresa jr. Com certeza o pessoal nao ia seguir.
[quote=“maresp”][quote=“dukejeffrie”]Eu diria que quanto mais responsabilidades uma classe tem, mais complexa ela fica.
Quanto mais coisas um método faz, mais complexo ele fica
Quanto mais elementos um laço manipula, mais complexo ele fica.[/quote]
:?: …e não é isso que determina se o código é mais generalista ou especialista?[/quote]
Acho que nao… nao sei, vc me confundiu! : )
Especialista é quem resolve um problema com escopo fechado, por exemplo, calcular o fatorial de um inteiro positivo.
Generalista é quem calcula fatorial de qq número, e ainda sabe o que fazer quando vc nao dá um número pra ele.
Nos dois casos, a “responsabilidade” do código, no sentido que eu queria usar, é “calcular fatorial”.
