Elizeu_Santos wrote:rsrsrs então pera ai.
eu te dou um projeto pra fazer, você simplesmente abre o eclipse, da um "add jars" no junit e começa a programar?

e quando outro programador for fazer manutenção no seu sistema? ah ta, ele vai abrir mil classes uma a uma lendo os "//" e "/** */" e vai entender tudo néh?

sempre que ele tiver duvida de algo ele vai ter que procurar dentro do código. rsrs

isso sim é ser programador!

Elizeu_Santos wrote:rsrsrs então pera ai.
eu te dou um projeto pra fazer, você simplesmente abre o eclipse, da um "add jars" no junit e começa a programar?

e quando outro programador for fazer manutenção no seu sistema? ah ta, ele vai abrir mil classes uma a uma lendo os "//" e "/** */" e vai entender tudo néh?

sempre que ele tiver duvida de algo ele vai ter que procurar dentro do código. rsrs

isso sim é ser programador!

Elizeu_Santos wrote:foi mal mano, então tenho de admitir VOCÊ É O CARA!

deve ser engenheiro do Google ou quem sabe da IBM no mínimo. o mais provável é que você~e seja engenheiro da Nasa e que faça metade do serviço sozinho!

classe tal herda de tal... implementa tal.... ai você vai nos testes e descobre tudo que a outra tem... ou você vai abrindo todas as classes pra ver... quando você poderia simplesmente olhar em um pedaço de papel ¬¬. e por fim, se desse algo errado, você faria testes para entender melhor como funciona.

veja que você já menosprezou até os comentários de código.
não vou me exaltar ou levar sua opinião em consideração, já entendi seu artigo ¬¬.

Elizeu_Santos wrote:..

immortalSoul wrote:

Elizeu_Santos wrote:foi mal mano, então tenho de admitir VOCÊ É O CARA!

deve ser engenheiro do Google ou quem sabe da IBM no mínimo. o mais provável é que você~e seja engenheiro da Nasa e que faça metade do serviço sozinho!

classe tal herda de tal... implementa tal.... ai você vai nos testes e descobre tudo que a outra tem... ou você vai abrindo todas as classes pra ver... quando você poderia simplesmente olhar em um pedaço de papel ¬¬. e por fim, se desse algo errado, você faria testes para entender melhor como funciona.

veja que você já menosprezou até os comentários de código.
não vou me exaltar ou levar sua opinião em consideração, já entendi seu artigo ¬¬.

É justamente por não ser um "engenheiro da google ou da IBM ou qualquer outro que faça metade do serviço sozinho" é que ele prefere um código bem escrito, limpo e com muitos testes. E quanto mais bem escrito o código estiver, menos comentários vão ser necessários, concorda?

Os testes são ( ou podem ser) uma documentação muito mais eficiente do que um diagrama UML. E o melhor é que ele sempre vai ter que estar atualizado, ao contrário do que sempre acontece na prática com os casos de uso, por exemplo. E além disso os testes são capaz de fazer muito mais, mostrando se alguma intervenção no código afetou alguma funcionalidade.

Sobre a UML, o esforço pra manter os documentos atualizado é bem elevado. A empresa precisa estar bem avançada na implantação de seus processos para que os documentos reflitam de fato a situação do sistema no momento. Por isso existe uma aproximação forte entre a UML e o 'modelo em cascata'. Na verdade o tal 'modelo em cascata' é em espiral. Mas nesse modelo a mudança é desencorajada e evitada. Não que não possa acontecer ( existem processos para gestão da mudança), mas é algo que se tenta minimizar.
Para desenv. software é quase sempre melhor adotar uma abordagem mais flexivel e que aceite melhor a mudança, que não veja a mudança como algo que deva ser evitado. Os testes permitem essa flexibilidade e a manutenção é mais simples.

Marcio_Nogueira wrote:Estaria errado utilizar UML para representar as classes, interfaces e objetos do sistema em conjunto com testes unitários / integração?