Mentat wrote: > Se o que est� dispon�vel n�o � bom, reescreve-se do zero. Claro que > isto n�o significa que voc� n�o possa pegar alguns conceitos e c�digo j� > existentes...
N�o exatamente! O Joel est� querendo passar algo que muita gente tem problemas quando entra num projeto grande ou porta sistemas legados: achar que pode reescrever todo o software na versao n e e ainda chegar � data-limite com uma versao n+1 com funcionalidade equivalente enquanto disputando com a concorr�ncia. Mito. Suponha que vc tenha uma base de c�digo de, digamos, 5 anos de constante uso, e de repente encontre uma classe de 5 p�ginas que poderia ter sido feita em meia. � pq o programador anterior era est�pido? N�o, aquilo s�o BUG FIXES. Seu c�digo pode estar uma beleza segundo todos os principios da programacao, mas por eventualidade aqla funcao pode retornar um valor diferente no Windows em esloveno, ou dar core dump na vers�o 9.2 do Xang� Linux que saiu com uma libc bugada, ou levar 600 segundos para executar tal query quando deveria levar 6 na �ltima revisao daqle banco de dados, etc. Em cada situacao q o programador encontrou, ele foi remendando a funcao segundo os bugs q iam aparecendo, e no final o c�digo virou uma imensa macarronada que talvez vc ache q nao faz o menor sentido e resolve reescrever tudo para seguir as normas do bom codigo. A partir do momento em que vc reescreve o seu c�digo inteiro e joga fora todos aqueles armengos, gambiarras etc, vc tem quatro tarefas: manter o codigo com funcionalidade igual ao anterior, resolver os bugs que apareceram qd vc detonou com a versao anterior, adicionar as features planejadas para a versao n+1 e AINDA manter o codigo segundo a sua ideia de 'correto', q foi o seu principal motivo para reescrever o codigo, isso tudo com a mesma data-limite de antes. Evidente que H� situacoes em que reescrever parte do c�digo � necess�ria. Quais situa��es? - C�digo mal documentado. Principalmente em sistemas internos, tem situacoes em q o programador nao insere UMA linha sequer de comentario e mantem todo o funcionamento do software de cabe�a. Acontece muito tamb�m do c�digo estar saturado de coment�rios que nao esclarecem nada, por exemplo: i++; // incrementa i. Os dois s�o exemplos bastante usados numa t�cnica chamada Job Security (http://www.tuxedo.org/~esr/jargon/html/entry/job-security.html). Tentar entender c�digo q foi deliberadamente escrito para ser confuso s� vai tomar mais tempo. - Design malfeito. A� n�o tem jeito mesmo meu compadre, se o projeto anterior foi desenhado por pessoas q nao tinham a menor nocao de metodologia de desenvolvimento, componentiza��o, engenharia de software em geral, vc pode at� manter aquele design por algum tempo mas s� vai protelar o desastre iminente. Nessas duas situacoes vc pode aplicar XP (http://www.extremeprogramming.org). Refazer o projeto segundo uma metodologia coerente com a sua equipe e a ferramenta/linguagem q vc est� usando, 'quebrar' o c�digo legado em pequenos modulos de funcionalidade, incorporar *como est� escrito* e conforme os problemas forem aparecendo e features forem adicionadas fazer testes de regress�o. Veja q nem assim vc deixou de aproveitar a base de c�digo anterior mesmo q fossem apenas alguns algoritmos, mas reescrever tudo do zero quando tem uma data-limite para apresentar um produto que tem q estar apto a competir ou ser posto em producao � simplesmente suic�dio. > Ele at� tem alguns pontos bons (apesar de �bvios), mas se for para > levar a s�rio tudo o que ele diz... :/ O Joel esclareceu bem no coment�rio que postou no /. qual o objetivo dele na entrevista: dar dicas de como escrever software comercial de sucesso. Se vc discorda da metodologia, pode sempre escrever open source e seguir o exemplo de softwares leves, bem escritos e bug-free como Gnome, Mozilla, KDE, Nautilus... ooops :) -- thiago pimentel | mad scientist | [EMAIL PROTECTED] Assinantes em 07/12/2001: 2379 Mensagens recebidas desde 07/01/1999: 145237 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
