Comentários sobre: MundoJava 39 – Patterns no Desenvolvimento de Software Moderno http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/ O blog da ASPERCOM Treinamentos www.aspercom.com.br Thu, 19 Jan 2012 15:20:54 +0000 hourly 1 http://wordpress.org/?v=3.0.1 Por: Manassés Loiola de Souza http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/#comment-10357 Manassés Loiola de Souza Fri, 09 Apr 2010 17:08:43 +0000 http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/#comment-10357 As explicações relacionadas a design ficaram muito claras. Essa parte do artigo é excelente para quem está começando o estudo de padrões de arquitetura. Muito útil a citação "CamadasXPartições" e a utilização de Façade para interface entre módulos de um sistema... As explicações relacionadas a design ficaram muito claras. Essa parte do artigo é excelente para quem está começando o estudo de padrões de arquitetura.
Muito útil a citação “CamadasXPartições” e a utilização de Façade para interface entre módulos de um sistema…

]]> Por: Alexandre Gandra http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/#comment-10218 Alexandre Gandra Fri, 26 Mar 2010 14:43:53 +0000 http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/#comment-10218 Boa, mas não concordo com isso aqui, não: "É melhor ter um design ruim com testes do que ter um design bom sem testes." Primeiro porque se o sistema tem design ruim, provavelmente os testes também serão ruins: frágeis (falso negativo), confusos e cegos (passa erro). Argh! Segundo porque geralmente dá para ir criando novos testes com o tempo. Isso aconteceu comigo. Peguei um sistema com design ok, mas sem nenhum teste automatizado. Eu seguia mais ou menos o seguinte ciclo para as alterações que fiz nele: 1. Criava alguns testes para capturar o comportamento antigo, mas restritos à parte que eu iria alterar. Pass. 2. Modificava estes testes para capturar o novo comportamento. Fail. 3. Modificava o código principal até Pass. De vez em quando enforcava o passo 1. Por outro lado, reconheço que fazer isso é difícil pois o design, mesmo estando ok, não favorecia os testes. Mas nada que um pouco de refactoring criatividade não resolviam. Boa, mas não concordo com isso aqui, não: “É melhor ter um design ruim com testes do que ter um design bom sem testes.”

Primeiro porque se o sistema tem design ruim, provavelmente os testes também serão ruins: frágeis (falso negativo), confusos e cegos (passa erro). Argh!

Segundo porque geralmente dá para ir criando novos testes com o tempo.

Isso aconteceu comigo. Peguei um sistema com design ok, mas sem nenhum teste automatizado. Eu seguia mais ou menos o seguinte ciclo para as alterações que fiz nele:
1. Criava alguns testes para capturar o comportamento antigo, mas restritos à parte que eu iria alterar. Pass.
2. Modificava estes testes para capturar o novo comportamento. Fail.
3. Modificava o código principal até Pass.

De vez em quando enforcava o passo 1.

Por outro lado, reconheço que fazer isso é difícil pois o design, mesmo estando ok, não favorecia os testes. Mas nada que um pouco de refactoring criatividade não resolviam.

]]> Por: Daniel Soares http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/#comment-10213 Daniel Soares Fri, 26 Mar 2010 03:12:12 +0000 http://blog.aspercom.com.br/2010/03/25/mj-39-designpatterns/#comment-10213 Realmente interessante o artigo. Nunca tinha me interessado por TDD, porém no curso de CSM ficou nítida a sua importância, já estou me aprofundando no assunto .. Realmente interessante o artigo. Nunca tinha me interessado por TDD, porém no curso de CSM ficou nítida a sua importância, já estou me aprofundando no assunto ..

]]>