Sobre Software, Sobre Código

Software quando surgiu foi primeiramente comparado à engenharia.

Engenharia era a ciência/técnica/profissão em que software mais se assemelhava.

Faziamos softwares como faziamos projetos de engenharia.

Faziamos TODO o planejamento antes de começar e depois implementava.

Maioria dos desenvolvimentos de softwares fracassaram.

Software é uma coisa nova.

Software significa SOFT = Maleável.

Programar é difícil, tem um lado artístico, tem um lado subjetivo.

Software é uma coisa diferente, única.

"Fazer software não é como constriur prédios mas sim como jardinagem."

O ponto é que a gente ainda não sabe como as coisas funcionam da maneira correta. A gente não sabe como caminhar 100% corretamente.

Mas mesmo assim, cada vez mais em nossas vidas temos mais softwares.

Se continuarmos fracassando do jeito que acontece, cedo ou tarde software pode causar danos igual os da engenharia mal feita.

Precisamos tomar cuidado pra que isso não aconteça, p/ que não tenhamos que ter um orgão seguro e competente p/ aprovar todos códigos de programação, como acontece com medicamentos.

Scrum, DDD, XP, IOC, DI, AOP, BDD, TDD, Desing Patterns, Integração Contínua, Refactoring, o que vier é lucro, precisamos tentar e ver os efeitos com o objetivo de diminuir falhas.

O médico é responsável por erros que ele comente, o programador AINDA não é responsável por seus erros.

Talvez seu software não coloque vidas em risco, talvez ele trabalhe com dinheiro, muito dinheiro!

Você precisa manter o código limpo para que sempre possa trabalhar.

Teoria das Janelas Partidas (http://pt.wikipedia.org/wiki/Teoria_das_Janelas_Partidas).

Código tem que ser legível, para que outra pessoa pegue e entenda.

Manter o software que é difícil.

É preciso deixar as coisas preparadas para mudanças.

You Aren't Gonna Need It: Sempre implemente as coisas quando você realmente precisar delas, nunca quando você acabou de prever que vai precisar. (http://c2.com/xp/YouArentGonnaNeedIt.html)

Baby Steps: Faça aos poucos, a cada passo dado, porque desta forma o trabalho sempre será muito menor e não irá onerar o projeto.

Se tiver algo "fedeno" no código, troque-o.

Deixe as coisas menores, que você vai ter mais facilidade/legibilidade(http://en.wikipedia.org/wiki/Single_responsibility_principle).

Nomes bem feitos. Os nomes do método tem que explicar o que o método faz.

Código também é documentação.

Formatação bem feita. Indentação bem feita (formatação horizontal) e formatação vertical bem feita.

Testes automatizados.

Tratamento de erros.

Padronização de códigos dentro da equipe.

Desenvolver software não tem a ver com construção de prédios, o termo "Engenharia de Software" não é um termo adequado, pois ajuda à misturar que desenvolver software tem a ver com engenharia cívil.

"Por que nunca comparamos desenvolvimento de software com desenvolvimento de software mesmo? Sempre temos que inventar nossas analogias..."

"Com o que será que eles comparavam engenharia no seu surgimento?"

Fontes:

Cuidando Para que o Software Não Apodreça - http://gc.blog.br/2008/07/20/cuidando-para-que-o-software-nao-apodreca/

Código Limpo com Hugo Corbucci - http://blip.tv/file/4024593