Google Analytics

domingo, 14 de agosto de 2011

Como documentar um refix no documento de change log de um software

Recentemente um colega me consultou sobre como documentar, no changelog que vai para o usuário, a correção de um bug que foi reaberto. Abaixo eu transcrevo a conversa (com autorização - agradecimentos ao Mateus pela autorização) pois outras pessoas também podem ter a mesma dúvida.

(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 alguém vai lá e reabre o dito cujo.
(13:26:59) Mateus: aí eu corrijo e libero outra versão, 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 usuário.]
(13:27:40) lg.moreira: ok.
(13:27:41) Mateus: o arquivo changelog que vai pro usuário.
(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 [descrição 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 título do bug também na linha.
(13:29:22) lg.moreira: O importante é te colocares no lugar de um usuário que lê o changelog.
(13:29:50) Mateus: pois é
(13:29:55) lg.moreira: Se tu colocas só refix, o cara vai ficar perguntando WTH he means with refix. What was still broken.
(13:30:34) Mateus: acho q não preciso ser tão verboso, já que o usuário é interno e tem acesso ao bugzila
(13:30:51) Mateus: mas acho bom indicar que foi reaberto e essa é uma "re-correção"
(13:31:17) lg.moreira: No caso do usuário ter acesso ao Bugzilla, o melhor mesmo é só 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 é importante também.
(13:32:48) lg.moreira: Agora a cobrança do serviço de consultoria.
(13:33:16) lg.moreira: Eu gostaria de colocar este diálogo no meu blog de programação.
(13:33:29) lg.moreira: Ele exemplifica uma dúvida 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: ;-)

terça-feira, 9 de agosto de 2011

Tornar a vida do usuário mais simples: Nossa meta

Lembre-se sempre de que programas de computador existem para facilitar a execução de um trabalho. Ou seja, para tornar a vida do usuário mais simples.

O que isto significa do ponto de vista de um programador? Significa que, ao tomar decisões de projeto, você deve pautá-las considerando o que vai tornar mais simples a vida do usuário, mesmo que isto implique em tornar a sua vida mais complicada. Resumindo: sempre optar pelo que dá menos trabalho para o usuário, mesmo que isto implique em mais trabalho para o programador.

segunda-feira, 8 de agosto de 2011

Command Line Interfaces

Taí um artigo que eu gostaria de ter escrito. Mas já o fizeram muito bem em http://www.antoarts.com/designing-command-line-interfaces/. Recomendo que leiam.

Alguns excertos:
  • "Ease of automation: Most command-line interfaces can easily be automated using scripts."
  • "Fast startup times: Most command-line interfaces beat their graphical counterparts several times at startup time"
  • "Easier to use remotely: Maybe it’s just me, but I prefer to remotely control computers via SSH over VNC"
  • "Higher efficiency: Being able to do a lot by just typing some characters instead of searching in menus increases the efficiency which you are able to do work at"
  • Try to avoid interactivity 
  • Name the program correctly
  • Follow the CLI conventions on arguments
  • "Provide --version and --help"
  • "If a program has nothing of importance to say, then be quiet"
  • "Every program should do one, and only one thing, and do it well"