A Arte de Programar

by Guillermo Schwarz

  

1.    Tudo pode ser feito com hashmaps.

2.    O gerentes sempre mentem. Esse sistema importante que precisa estar pronto para ontem, não será analisado até dois meses após a entrega.

3.    É muito melhor escrever algo "certo" do que fazer-o rápido e com bugs. Sempre que sinta que tem que se apressar, não o faça. Faça como se tivesse todo o tempo do mundo. Sempre faça a coisa certa. Levará muito menos tempo para terminar e você se sentirá muito melhor respeito ao código.

4.    Se eles disserem: "Não temos mais dinheiro, termine". Então reduza o alcance, remova funcionalidades, faça menos, use metodologias topo agile, mas nunca se apresse.

5.    O efeito GIGO (do inglês:Garbage in, garbage out): Se entra lixo sairá lixo. Certifique-se de que os requisitos são os corretos.

6.    Não há funcionalidades sem documentação. Ou as documenta, ou ninguém saberá que eles existem.

7.    RTFM( Do ingles: Read the Fucking Manual, ou Lê a porcaria do manual) é má educação. A usabilidade do corredor (Hallway usability) é muito melhor. Você pode achar que isto contradiz o número 5, quizas sim ou quizas não. [[ De fato este é o principal motivo pelo qual o Windows venceu o Unix na área de trabalho. Unix e Linux estavam mais preocupados com os manuais e com a educação dos seus usuários enquanto o Windows se preocupou com a reação imediata deles. Ou seja, eles preferiram se livrar dos manuais e permitiram que as pessoas se focassem no que realmente queriam fazer. Eu nunca vi um manual para o iPhone ou para um dispositivos Android, até uma criança de 3 anos pode usá-lo. Existe uma lição para aprender aqui, mas duvido que internamente Microsoft, Apple e Google não documentem a funcionalidade e o "como as coisas são feitas", trabalhei para a Microsoft e tudo sempre foi documentado, o estilo sempre foi "meia página", o mais direto e claro possível. Os gerentes de programa eram responsáveis ​​pela análise comparativa com outros produtos e concorrentes, e os documentos eram sempre grandes, mas o estilo era o mesmo. ]]

8.    Você aprende muito mais quando observa as pessoas usando o seu sistema. Monitore o uso e corrija-o conforme seja necessário. [Deixa ei contar uma breve história. Vinte anos atrás eu desenvolvi um sistema para alguns jovens, vamos chamá-los de secretários, que eta para armazenar e pesquisar informações sobre os pacientes. Acontece que algumas das informações foram alteradas, algumas foram excluídas e eles não estavam usando suas respectivas contas, pelo que se culpavam mutuamente. Eu troquei todas as suas senhas e gravei todas as ações numa tabela de banco de dados usada para isso. O problema aconteceu de novo e eu voltei para a minha mesa e antes de a discussão terminar apontei para uma das meninas e disse: você fez isso, neste dia, neste momento. Nunca tivemos esse problema novamente. ]

9.    O teste de unidade é muito mais eficaz que o QA tradicional. Use ambos no começo. Testes unitários são PRIMEIRO (Unit Tests Are FIRST) [ O objetivo de fazer testes unitários automatizados é que você nunca mais precisará usar o debugger (uma vez ao ano, tudo bem, especialmente se você precisar depurar seus testes). Escrevendo Grandes Testes Unitários: Melhores e Piores Práticas (Writing Great Unit Tests: Best and Worst Practices), mas ao contrário da crença popular, você deve atacar de coisas internas no sistema, esta bem testar o banco de dados para atacar sistemas externos, mas não internos, então de certo modo um teste unitário é também um teste de integração interna. Mas você também deve usar seus mesmos testes de unidade como testes de integração, invertendo um switch. A regra geral para testes unitários é "testar tudo o que pode falhar". As 12 melhores práticas de teste de unidades selecionadas - Doces de engenharia de software (SW Engineering Candies - Top 12 Selected Unit Testing Best Practices) E como algumas pessoas recomendam usar uma *assert* por método de teste, isso significa que se 10 coisas falharem, você precisará escrever 10 métodos de teste, e todos terão a mesma aparência, o próximo terá apenas mais uma linha do que a anterior. Qual é o propósito disso? Você vê um teste falhar e você não precisa depurá-lo, você não precisa olhar para o código de teste, você vê o nome do teste e sabe exatamente o que falhou. Isso aumenta a produtividade 10x.]

10. A programação funcional é a onda do futuro. Aprenda Haskell.

11. Para estimativa, use estimativas de projetos anteriores corrigidas por dados reais. Você precisa de dados concretos para isso: use o número de telas, tabelas de banco de dados, casos de uso, etc.

12. O controle de versão é seu amigo.

13. O código deve ser DRY em vez de WET. [[DRY significa Don't Repeat Yourself, isso significa remover código duplicado, porque o código repetido é um pesadelo de manutenção, quando você precisa corrigir bugs, você precisa procurar por todo o código repetido, e se você trabalha com mais pessoas, eles irão copiar e colar mais rápido do que você pode resolver os bugs. WET significa Write Everything Twice e seu primo feio Write Every Time, significando exatamente o oposto de DRY: muitos e muitos códigos repetidos.]]

14. Cache de algoritmos alheios.

15. Os riscos técnicos são controlados usando protótipos.

16. Como todos os problemas técnicos podem ser resolvidos, todos os problemas do projeto reduzem-se a problemas organizacionais. É por isso que todas as metodologias agiles existem: para lidar com problemas organizacionais. A chave para o sucesso é "falhar rápido".

17. 16. Anote a retrospectiva da iteração e aja de acordo com ela.

18. Anote e numere todos os requisitos. Use a depuração de requisitos do DSDM. Anote e numere todas as decisões de projeto usadas para resolver conceitualmente todos os requisitos. Crie protótipos para cada decisão de projeto.

19. Entre em uma academia e vá todos os dias. Até 10 minutos de exercícios leves farão você se sentir melhor.

20. Certifique-se de que seu código seja executado em sistemas operacionais diferentes e em bancos de dados diferentes. Use integração contínua para isso.

21. Você não está sendo pago para escrever código, você é pago para escrever funcionalidade. Código é apenas custo. Há custo para criá-lo, custo para depuração, custo para auditoria, custo de armazenamento, custo para manutenção etc.

PS: Uma vez que isto tem tantas boas críticas, uma lista de bónus para os verdadeiros gurus:

1.    1. Escreva pequenas funções. No máximo 10 linhas de código por função. (caso contrário, os testes de unidade não são tão bons). O tio Bob diz apenas 5 linhas por função.

2.    A programação assíncrona é muito mais rápida que a programação síncrona. Consulte o vert.x

3.    Gerencie as exceções apropriadamente, propague ou manipule. Não coma exceções.

4.    Não use threads diretamente. Use frameworks para lidar com as threads, como o gerenciador de trabalho. Uma maneira de fazer isso usando o Java EE: WorkManager (SDK do Java EE 5) , mas isso é um exagero para a maioria dos aplicativos. Existe um mais simples que este? Um mais simples: como usar java.util.concurrent.CountDownLatch , mas o problema é que não quero que a biblioteca mostre que está usando threads (deve funcionar corretamente com ou sem threads).

5.    Aprenda sobre multimetodos e protocolos.

6.    Aprenda sobre o AOP.

7.    Aprenda sobre as melhores práticas do XP.

8.    Olhe para o tio Bob explicar OOP:

PS2: Essa resposta é muito longa e você pode fingir tudo que eu escrevi. Mas a única coisa que não pode ser falsificada são os testes unitários. Eu tenho estado em empresas que parecem fazer tudo certo. Você faz uma inspeção mais próxima e tudo é falso. A integração contínua é feita sobre os projetos que eles sabem que compila e, em seguida, o resultado é jogado fora. Existem inúmeros projetos que dependem deste projeto e não são compilados, nem sequer são vistos. As revisões de código são feitas por três pessoas diferentes com idéias diferentes de como o código deve ficar: não há convenções de código. Eles usam todas as bibliotecas que você pode imaginar, e todos os clientes recebem os mesmos produtos, mas com bibliotecas diferentes, é como refazer todo o seu produto toda vez para usar diferentes frameworks e bibliotecas apenas por causa disso. E não há convenções de código por um motivo. Quando você aponta isso: Aqui estão as convenções de codificação da Sun. As convenções de código devem ser um documento ativo, no qual, quando você encontra algum código bizarro, documenta no documento, tanto o problema quanto a solução. Você deve explicar as coisas bem no documento e as pessoas devem concordar, caso contrário, o desenvolvedor mais sênior toma a decisão. Tudo pode ser falsificado, mas eles nunca podem fingir testes de unidade. Essa é a verdadeira separação dos desenvolvedores que estão apenas se passando por desenvolvedores e desenvolvedores que são verdadeiros desenvolvedores. Você deve explicar as coisas bem no documento e as pessoas devem concordar, caso contrário, o desenvolvedor mais sênior toma a decisão. Tudo pode ser falsificado, mas eles nunca podem fingir testes de unidade. Essa é a verdadeira separação dos desenvolvedores que estão apenas se passando por desenvolvedores e desenvolvedores que são verdadeiros desenvolvedores. Você deve explicar as coisas bem no documento e as pessoas devem concordar, caso contrário, o desenvolvedor mais sênior toma a decisão. Tudo pode ser falsificado, mas eles nunca podem fingir testes de unidade. Essa é a verdadeira separação dos desenvolvedores que estão apenas se passando por desenvolvedores e desenvolvedores que são verdadeiros desenvolvedores.