logo
Contato | Sobre...        
rebarba rebarba

Artigos

Blog

Open Source


Google






















Rodrigo Strauss :: Blog


Programando direito com o Slashdot

No Ask Slashdot de ontem, um slashdotter perguntou sobre como montar um padrão de desenvolvimento para um recém criado departamento de desenvolvimento de software. Como sempre, as respostas foram muito boas, recomendo a leitura. O que eu acho mais interessante é que ninguém recomenda RUP... :-)

E isso me faz lembrar de como muitas das coisas que foram respondidas lá são óbivias para todo mundo mas muita gente não faz. E esse muita gente inclui "eu mesmo" em alguns pontos...

Coisas obviamente necessárias para fazer um software que presta:

  • Especificação. Simples. Alguns DOCs, nada muito complicado, mas que diga o que deve ser feito, como deve ser feito e porque deve ser feito assim.
  • Comentário no código. Na minha opinião MAIS IMPORTANTE DO QUE A ESPECIFICAÇÃO, pelo fato de ser mais simples de escrever e estar mais ligado ao processo de desenvolvimento. Se você não comenta seu código, está errado, isso é essencial. Essencial. Essencial. for(;;) cout << "Essencial" << endl.
  • Software de controle de bugs. Essencial também. Pode ser uma planilha Excel ou algo como o Bugzilla (que usamos aqui onde eu trabalho).
  • Controle de versão. Eu espero mesmo que ninguém questione esse. O básico do básico. Pode ser um Source Safe (que funciona bem para projetos pequenos), CVS, SVN ou até um Preforce (dizem que é o melhor, US$ 800,00 por usuário).
  • Testes. Uma equipe de testes ou testes unitários. Eu tenho o segundo. Como faço só software server-side e nem tudo está 100% orientado a objetos do jeito que deveria ser, faço softwares que agem como clientes e testam todas as possibilidades e fazem testes de stress. Isso é importante e reduz muito o stress de ter um cliente dizendo que seu software é uma porcaria porque você não testou uma situação de uso que, para ele, é básica.
  • Build automático. É importante, mas muita gente não faz. Eu não fazia, até que compilar 10 dependências na mão começou a atrapalhar o meu trabalho. Alguns arquivos BAT resolvem o problema. Tenho feito meus últimos em Python. Se você usa .NET, estude o MSBuild.

Acho que esses são os básicos do básico. Não são muito difíceis de implementar e trazem um imenso retorno em curto prazo.


Em 17/11/2005 14:51, por Rodrigo Strauss


  
 
 
Comentários
Leo D'Ippolito | website | em 17/11/2005 | #
Muito bom, principalmente quanto a não-recomendação do RUP e o incentivo a especificações simples :)
Leo D'Ippolito | website | em 17/11/2005 | #
Meu nome com apóstrofe! Yeeeahhh!! :)
Rodrigo Strauss | website | em 17/11/2005 | #
RUP é muito bom quando você trabalha no esquema de fábrica de software: um monte de codificadores que seguem uma especificação e não sabem direito em que software estão mexendo e onde isso se encaixa no todo.

Quando você tem um trabalho tecnicamente complicado (como C++) que requer um grande conhecimento e o programador é realmente um engenheiro de sistemas, RUP não resolve. O que resolve é Agile. :-)
Rodrigo Strauss | website | em 17/11/2005 | #
Eu tardo mas não falho :-)
Renato | em 17/11/2005 | #
Aqui na empresa onde eu trabalho usamos sistemas automatizados, controle de versao, Unit Tests e estamos começando a implantar Integração Contínua. Acho que isso tambem é muito importante quando temos muitos desenvolvedores em apenas um projeto e acredito que dependendo do tamanho do projeto equipes pequenas tambem se beneficiam.

Na integração continua temos um script responsável por compilar todos os nossos módulos, fazer testes, gerar instalações simples (isso ajuda a detectar erros caso algo arquivo esteja faltando) e faz checagens de integridade nestes arquivos (tem alguem com versao de debug ? Vazamento de memória ? Algum arquivo corrompido ?).

Em pouco tempo já tivemos bons resultados, principalmente por não deixar nossos "pequenos problemas" se tornarem monstros que sempre aparecem 1 dia antes de entregar o sistema para o cliente, isso quando não aparece na máquina do cliente.
Fabricio Ferreira | em 24/11/2005 | #
"Real Programmers don't need comments -- the code is obvious."

from: http://www.codeproject.com/scrapbook/realprog.asp
Rodrigo Strauss | website | em 24/11/2005 | #
Claro, claro, claro. Afinal, todos os programadores deveriam ser parentes da Mãe Dinah.

Quero ver esse Leo entender isso:

http://www0.us.ioccc.org/1994/imc.c

Afinal, "the code is obvious" :-)
Bruno | em 24/11/2005 | #

Sobre os comentários ... é algo polemico... Rolou uma discussão interessante sobre isso na lista xp-brasil (yahoogroups) e se não me engano no livro de XP do Vinicius tambem tem algo sobre o asssunto.
Resumindo muitissimo do que foi falado o que acaba acontecendo é que os comentarios acabam nao sendo atualizados junto com o codigo e isso acaba gerando problemas nas manutencoes futuras... pessoalmente já vi muito isso acontecer, ser 'traido' por comentarios que nao valiam mais... de qualquer forma ainda continuo adepto aos comentarios pois nos meus códigos eles sempre acabam me ajudando... mas nao vejo problema em ver codigos bons sem tambem... o problema é que quando o codigo é ruim nao tem comentario que ajude.

cheers
Fabricio Ferreira | em 25/11/2005 | #
IOCCC é covardia... =]

Aí não vale!
Wanderley Caloni Junior | website | em 25/11/2005 | #
Quanto aos comentários acho de ouro a regrinha "comente o não óbvio". É muito útil encontrar alguma pista das intenções do sujeito que codou algo não trivial e por isso mesmo fez questão de comentar. E isso não foge às regras do "Real Programmer" ;)
rebarba rebarba
  ::::