Recentemente um colega me consultou sobre como documentar, no changelog que vai para o usuario, a correcao de um bug que foi reaberto. Abaixo eu transcrevo a conversa (com autorizacao - agradecimentos ao Mateus pela autorizacao) pois outras pessoas tambem podem ter a mesma duvida.(13:26:31) Mateus: se eu corrigo um bug e coloco no changelog:(13:26:39) Mateus: fix bug XXX....(13:26:47) Mateus: mas alguem vai la e reabre o dito cujo.(13:26:59) Mateus: ai eu corrijo e libero outra versao, com o novo fix.(13:27:04) Mateus: como coloco no changelog?(13:27:07) Mateus: Fix bug xxx(13:27:12) Mateus: ou Refix bug xxx ?(13:27:25) lg.moreira: changelog do source control ou do bug tracking?(13:27:33) Mateus: do pacote. [N.R. - Quer dizer: no documento que vai para o usuario.](13:27:40) lg.moreira: ok.(13:27:41) Mateus: o arquivo changelog que vai pro usuario.(13:28:06) lg.moreira: Fix of bug xxxx after its reopening by Fulano.(13:28:50) lg.moreira: Ou, se quiseres mais curto: Refix of bug xxxx: Now I yyyyyyy [descricao do que foi feito] and it should really fix the problem.(13:29:00) Mateus: hmmm(13:29:09) Mateus: esse segundo me agrada mais porque to colocando o titulo do bug tambem na linha.(13:29:22) lg.moreira: O importante e te colocares no lugar de um usuario que le o changelog.(13:29:50) Mateus: pois e(13:29:55) lg.moreira: Se tu colocas so refix, o cara vai ficar perguntando WTH he means with refix. What was still broken.(13:30:34) Mateus: acho q nao preciso ser tao verboso, ja que o usuario e interno e tem acesso ao bugzila(13:30:51) Mateus: mas acho bom indicar que foi reaberto e essa e uma "re-correcao"(13:31:17) lg.moreira: No caso do usuario ter acesso ao Bugzilla, o melhor mesmo e so refix of XXXX: Now I yyyyyy.(13:31:27) Mateus: blz.(13:31:29) Mateus: valeu.(13:31:41) lg.moreira: Tu colocas no bugzilla o que foi feito para corrigir?(13:32:23) Mateus: sim(13:32:37) lg.moreira: ok. Isto e importante tambem.(13:32:48) lg.moreira: Agora a cobranca do servico de consultoria.(13:33:16) lg.moreira: Eu gostaria de colocar este dialogo no meu blog de programacao.(13:33:29) lg.moreira: Ele exemplifica uma duvida muito comum.(13:33:54) lg.moreira: Estou autorizado?(13:33:57) Mateus: sim(13:33:59) lg.moreira: ok.(13:34:00) lg.moreira: ;-) Seguidamente me pedem algumas recomendacoes de livros. Entao, montei esta lista aqui. Ela esta dividida em um grupo de livros genericos, que se aplicam a qualquer linguagem de programacao, e outro especifico de C++. Recomendo ler os livros mais ou menos na ordem em que aparecem listados. Sobretudo recomendo que todo mundo comece lendo o "The Pragmatic Programmer, From Journeyman to Master."Vamos as listas: Desenvolvimento de software em geral, independente de linguagem: The Pragmatic Programmer, From Journeyman to Master. David Thomas e Andrew Hunt. Este livro e um divisor de aguas na carreira de um programador. Depois de le-lo, voce nunca mais sera o mesmo. Extreme Programming Explained. Kent Beck. E fundamental conhecer os conceitos apresentados neste livro, mesmo que nao se va aplicar tudo o tempo todo (BTW, o proprio Beck diz que nem todo o tipo de projeto deve ser feito em eXtreme Programming). Refactoring: Improving the Design of Existing Code. Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. Bastante indicado para quem trabalha com codigo herdado ou com equipes muito heterogeneas. The Agile Manifesto. Kent Beck