Ivan, refatorar até chegar num ponto onde o design seja interessante é muitas vezes mais rápido do que fazer aquele puta design logo de cara, quando vc nao tem ainda todos os requisitos levantados.
Muitas vezes, é melhor chegar logo num release pra poder mostrar pro cliente se o seu código é mesmo o que ele quer do que se preocupar com retrabalhos. Pelo menos, quando vc faz um release, o cliente pode ver o que está acontecendo 
Como já diziam…
Eu discordava um pouco dessa estratégia, mas hoje já acredito nela.
Fazendo uma coisa suficientemente pensada no começo (seprando bem os conceitos) fica relativamente fácil refatorar depois.
tem muitas discussoes a respeito disso. Depende de como vc pretende desenvolver seu produto.
Ainda vejo muito desenvolverem as coisas sem pensar no usuário do outro lado. Meu software mais usavel de todos foi um que teve um prototipo em Smalltalk, desenvolvido bem fake, sem pensar em nada. Quando as telas e as funcionalidades estavam boas, a gente jogou tudo fora e foi implementar na tecnologia escolhida (que eu nao vou mencionar pq nao é educado falar palavrao na mesa).
Quando vc tem certeza de que vc vai refatorar aquilo, mesmo reaproveitando uma parte do codigo, vc nao liga de nao fazer uma obra de arte naquilo, vc larga mais o código e termina bem antes. Daí vc pode usar esse tempo (que deve estar previsto) pra aplicar padroes, reescrever partes, jogar fora aquele remendo que vc fez e trocar por um código genérico, etc. Eu ainda gostaria de estar num projeto onde, passado tudo isso, ainda desse pra fazer fine tuning do código, observando eficiencia, essas coisas. Nunca me aconteceu, pq todos os prazos estouram e o que o cliente nao ve, o coracao (dele) nao sente.
[]s!!
Mais sobre Just-In-Time Design nesse artigo na DW:
http://www-106.ibm.com/developerworks/java/library/j-xp07013.html
ola pessoal…
pelo visto o topico deu o que falar…
qdo postei a pergunta falava em um pequeno design e nao em design imenso…
minha duvida é/era vale a pena pegar uma atividade de uma semana e de repente gastar dois dias fazendo um design ao invés de ir fazendo e ficar na tentativa/erro…
meu feeling diz que sim, q um design mesmo ‘pequeno’ e em ‘papel de pao’ tem alguma valia… mas vira e mexe me questiono isso… e tento ir pro tradicional…
tem um artigo interessante no site abaixo… vale a pena uma lida
http://brazil.joelonsoftware.com/Articles/NothingSimpleSeems.html
[]’
try this … or not …
[quote=“louds”]UML é uma besta tão gigante que ainda ta para ser criado um projeto que use todos os 999999999 diagramas.
Por isso que sou adepto do SML, a starfield modeling language.[/quote]
todos sabem que eh dificil eu e o louds concordarmos em alguma coisa. mas aqui estou 100% com ele.
UML como documentacao e para msotrar para outroa pessoa, ou apra ESBOCAR as classes, com certeza.
agora tem empresa que o manager (que ja nao programa a seculos) da o UML para o programador fazer e tem de ser daquele jeito? Isso nao existe…! Bem, existe, mas imagina a “burocracia”! Programar é arte. Nao da para chegar e falar “Ei Da Vinci, pinta essa guria aqui, ja desenhei.”
Existe o outro lado da moeda entretanto.
UML também pode trabalhar ao seu favor. O diagrama de deployment, se lembro bem, é aquele para ser feito durante toda uma segunda daquelas que voce encarna o Garfield.
UML (digo todos aqueles 9 chatíssimos e burocráticos diagramas) é mais uma daquelas coisas cujo uso que atribuiram não é o mais adequado. É específicação demais que, no final, acabando atrapalhando o programador (como o Paulo disse, "Nao da para chegar e falar “Ei Da Vinci, pinta essa guria aqui, ja desenhei.” "). Mas, como documentação final de projeto (e como guia para auxiliar nas manutenções), UML é o que há de melhor ainda.
Especificações e design devem ser feitos da maneira mais simples possível para que o programador possa conseguir traduzir a vontade do cliente com a maior liberdade possível para criar (arte).
EDITADO: que post mais acaciano!! IGNOREM ISSO, por favor
Eu acho que vocês estão sendo um pouco radicais nessa idéia de “Programar é arte”. Pode parecer absurdo falar pro Da Vinci pintar a guria já desenhada, mas não seria pedir para o cara que colore as histórias em quadrinhos.
No mercado existem todos os tipos de programadores, e com o crescimento do modelo de fábrica de software a tendência é ter o analista fazendo o design em UML e o programador implementando os detalhes no código.
Então se você está em um projeto em que todos tem o conhecimento e experiência necessárias para fazer algo decente sem um design detalhado, tudo bem, mas se é um projeto grande com pessoas mais inexperientes, a UML pode ajudar muito.
Aí é que está, Bani: essas técnicas favorecem o uso de programadores inexperientes sem habilidade criativa no desenvolvimento.
Daí acontece um dos fenomenos mais danosos para o bom cumprimento de um projeto: a perda de informacao. Existe o ótimo, que é o que o cliente precisa. Logo abaixo na escala de importancia vem o que o cliente quer. Se atendermos até aí já tá bom. O terceiro lugar fica com o malhor que o fábrica consegue produzir baseado nas informacoes recebidas. Em quarto, o que o cliente pediu. Daí pra frente, podemos chamar de “incompleto” qualquer resultado.
Pois bem, com programadores inexperientes que nao vao questionar a UML, e um analista que nao tem contato com o código, lidando com o departamento comercial do cliente, que nível vc acha que dá pra atingir? Eu acredito que vai no máximo até o quarto grau, isto é, o que ele pediu. Conforme a informacao vai passando de mao em mao, ela vai perdendo a nitidez e ganhando ruídos (necessidades imaginarias, desejos pessoais, enfim, coisas que nao fazem parte da informacao inicial).
Fora os problemas que comecam a aparecer dentro da empresa quando vc tem programadores experientes e/ou questionadores: a briguinha interna pra ver quem tem razao, o analista ou o programador. Sem um mediador, nao há consenso. Quando o analista tem mais poder, aparecem os bugs e as implementacoes fora da especificacao (já que o analista nao participa da fase de “arredondar”). Quando o programador tem mais poder, vc atrasa tudo pq o analista tem que ir sozinho arrumar a especificacao e os programadores tem que ficar esperando.
O bom mesmo é ter programadores inexperientes fazendo pequenas mudancas, ou implementando alguma coisa para a qual já existe um teste de unidade, ou trabalhando em conjunto com caras experientes que possam ensinar e utilizar o potencial produtivo dos novatos. Criar, deixe para os artistas. Isso pra mim significa um time misto, com programadores também, e se possível, alguém do “outro lado”, isto é, um representante do cliente.
Eu tive a oportunidade de desenvolver um projeto onde até os menores detalhes podiam ser perguntados para o cliente, e foi muito saudável, pq o software roda há quase um ano sem mudar uma linha sequer.
Chega, já falei demais!!
[]s!!
Bom, posso estar errado, mas poucos são suficientemente loucos para usar todos os n diagramas da UML nos seus projetos - excluindo os puristas da OO, claro. Até hoje, por exemplo, participei de dois projetinhos (pequenos mesmo) com UML em que usamos só o Caso de Uso e o Diagrama de Classes. Não vejo mal nenhum nisso, acho que depende da dimensão do sistema a ser implementado - além daqueles fatores que todo mundo já conhece, prazo, custo, disponibilidade da equipe, saco…
Mas tem uma coisa que mudou sim: é difícil convencer os analistas “estruturados” e “essenciais” de que o desenvolvimento orientado por objetos pode (e deve, dizem alguns) ser iterativo - projeta, implementa, refatora… A maioria ainda quer “analisar” e entregar o modelo ao programador que se vira para transformar um amontoado de diagramas em algo vivo. Esta eu acho a parte complicada, a mudança de cultura. Aqui onde trabalho convivo com isso todos os dias. Somos os “garotos da OO” aqui. 
Lá vai uma pergunta idiota de alguém que começou a ler sobre XP agora: Como conciliar a XP com o conceito de fábrica de software? Eu sou particularmente hostil ao “ambiente” de fábrica, então a pergunta pode ser apenas preconceito meu. Queria saber a opinião de quem tem experiência nisso…
Opa! Enquanto eu escrevia o dukejeffrie disse o que eu penso tb…
Certa vez perguntaram para o Jacobson (rational) se ele conhecia xp e ele respondeu: NÃO… eu não conheço xp… respirou e respondeu novamente: É LÓGICO QUE EU CONHECO XP !!! Mas eu acho que só funciona com equipes pequenas e com programadores de alto nível…
Bom, eu vou um pouco mais longe… acho que rup não funciona.
"você já teve que fazer um diagrama de sequencia de um método getName() da vida ? "
"já desenhou o diagrama de estado do elevador ? "
"já colocou métodos toString e equals em seu diagrama de classes ? "
Cara, como é bom estar de volta
Sempre vi o trio programador/desenvolvedor/analista como uma equipe com um objetivo único: resolver um problema (de forma artística talvez, como diria o Paulo
Acompanhei a discussão aqui… e notei uma coisa… todos discutiram preferências no que diz respeito à análise, métodos, procedimentos e etc. etc. Mas um princípio fundamental no desenvolvimento de software, é a comunicação e entrosamento da equipe, se todos conhecem UML, com certeza ele será uma melhor opção, caso contrário, que usem folhas de papel, rascunhos, inventem um padrão, etc.! O importante é que todos os envolvidos no projeto ENTENDAM COM CLAREZA sua documentação. É preciso, claro, levar em consideração outros aspectos, prevendo-se que outra equipe pode vir à mexer com o mesmo sistema (em uma estrutura modular, isso é possível) pode-se utilizar um padrão conhecido (UML) ou qualquer estilo de documentação que torne as coisas claras.
Agora, quanto a pergunta: Devemos fazer um design ou projetar o software antes de começar a codificar? Bom… na minha opinião sim… no entanto, sou totalmente a favor da construção de protótipos… sempre fiz isso e isso me ajuda muito a descobrir pequenos bugs nas lógicas de negócio e/ou situações não previstas… e pra quem acha que se perde muito tempo construíndo protótipos… recentemente fiz um comparativo com o tempo de desenvolvimento que eu mesmo levava antes e depois de começar a trabalhar desta forma… e acreditem. cheguei a entregar diversos projetos antes do prazo, com folga
[]s!
Carlos H.
Olá, poderia passar mais detalhes sobre SML, a starfield modeling language.
Obrigado