O que todo programador deve saber sobre programação?

Por favor, mantenha-se em questões técnicas , evite problemas de comportamento, culturais, de carreira ou políticos.

1. O bug está no seu código, não no compilador ou nas bibliotecas de tempo de execução.

2. Se você vir um erro que não pode acontecer, verifique se você criou e implantou corretamente o seu programa. (Especialmente se você estiver usando um IDE complicado ou uma estrutura de compilação que tente ocultar os detalhes confusos de você ... ou se sua compilação envolver várias etapas manuais.)

3. Programas simultâneos / multiencadeados são difíceis de escrever e de testar adequadamente. É melhor delegar o máximo possível para bibliotecas e estruturas de simultaneidade.

4. Escrever a documentação faz parte do seu trabalho como programador. Não deixe para "outra pessoa" fazer.

EDITAR

Sim, meu ponto 1 é exagerado. Até as melhores plataformas de aplicativos de engenharia têm sua parcela de bugs, e algumas das menos bem projetadas estão repletas delas. Mas, mesmo assim, você deve sempre suspeitar do seu código primeiro e só começar a culpar os erros do compilador / biblioteca quando tiver evidências claras de que seu código não tem culpa.

Na época em que desenvolvi o C / C ++, lembro-me de casos em que supostos "bugs" do otimizador se deviam a mim / algum outro programador ter feito coisas que as especificações da linguagem dizem ter resultados indefinidos. Isso se aplica mesmo a linguagens supostamente seguras como Java; por exemplo, dê uma olhada longa no modelo de memória Java (JLS, capítulo 17).

• Como ler o código de outras pessoas.
• O código não existe se não estiver marcado no Version Control System.

Os cálculos de ponto flutuante não são precisos.

Não pare de aprender.

Que a primeira coisa que você pode fazer para aumentar a qualidade e a manutenção do seu código é REDUZIR DUPLICAÇÃO.

Habilidades para solução de problemas e depuração

Eles dificilmente dedicam algum tempo a esse tópico em qualquer um dos cursos de programação que participei e, na minha experiência, é um dos maiores determinantes da produtividade de um programador. Goste ou não, você passa muito mais tempo na fase de manutenção do seu aplicativo do que na nova fase de desenvolvimento.

Eu trabalhei com muuuuito muitos programadores que depuram mudando aleatoriamente as coisas sem nenhuma estratégia para encontrar o problema. Eu tive essa conversa dezenas de vezes.

Outro programador: acho que devemos tentar ver se isso corrige.
Eu: Ok, supondo que isso seja corrigido. O que isso diz sobre onde está a fonte do problema?
Outro programador: Não sei, mas temos que tentar alguma coisa .

1. Não seja esperto; seja claro.
2. Use antes da reutilização.
3. Nomes importam.
4. Uma função faz 1 coisa e faz bem.
5. Pequeno é melhor que grande.

O básico. Atualmente, os programadores aprendem tecnologias, não conceitos. Está errado.

Todo programador deve saber que está colocando suposições no código o tempo todo, por exemplo, "esse número será positivo e finito", "esse código poderá se conectar ao servidor o tempo todo em um piscar de olhos".

E ele deveria saber que deveria se preparar para quando essas suposições quebrassem.

Todo programador deve saber sobre o teste.

Aprenda conceitos . Você pode pesquisar no Google a sintaxe.

Pensamento crítico e lógico. você não pode fazer nada de bom sem ele.

Teste de Unidade. Essa é uma ótima maneira de codificar suas suposições sobre como o código deve ser usado.

O mínimo absoluto que todo desenvolvedor de software deve saber absolutamente, positivamente sobre Unicode e conjuntos de caracteres (sem desculpas!) .

É mais difícil do que você pensa.

Embora seja fácil (ish) montar algo que funcione quando usado normalmente, lidar com entradas erradas, todos os casos de borda e canto, possíveis modos de falha etc. é demorado e provavelmente será a parte mais difícil do trabalho.

Então você deve fazer com que o aplicativo pareça bom também.

Conhecimento de domínio. A especificação nunca é 100%; conhecer o domínio real com o qual você está desenvolvendo SEMPRE aumentará a qualidade do produto.

Notação Big O e suas implicações.

Algumas referências úteis

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Ponteiros, obviamente. :)

Código Completo 2 - capa a capa

Os dados são mais importantes que o código.

Se seus dados forem inteligentes, o código pode ser estúpido.

Código idiota é fácil de entender. O mesmo acontece com dados inteligentes.

Quase todo sofrimento algorítmico que eu já tive foi devido a dados estarem no lugar errado ou abusar de seu verdadeiro significado. Se seus dados tiverem significado, coloque esse significado no sistema de tipos .

Qual idioma e ambiente é mais adequado para o trabalho. E nem sempre é o seu favorito.

Dividir e conquistar. Geralmente, é a melhor maneira de resolver qualquer tipo de problema prático, do agendamento à depuração.

A verdadeira habilidade se reflete na capacidade de executar bem um design simples, não na capacidade de fazer um design complicado funcionar.

Essa habilidade vem do domínio maior dos fundamentos, não do domínio do arcano. Um programador de alto calibre não é definido por sua capacidade de codificar o que os outros não podem (usando funções de nível superior, programação funcional avançada, o que você tem), mas sim por sua capacidade de refinar a codificação perfeitamente mundana. Escolhendo a decomposição apropriada da funcionalidade entre as classes; construção em robustez; usando técnicas de programação defensiva; e usando padrões e nomes que levam a uma maior autodocumentação, estes são o pão e a manteiga da programação de alto calibre.

Escrever um código bom para o qual você ou outra pessoa possa voltar em uma semana por mês ou ano e entender como usar, modificar, aprimorar ou estender esse código é crucial. Isso economiza tempo e esforço mental. Lubrifica as rodas da produtividade removendo obstáculos que você tropeçaria antes (talvez interrompendo sua linha de raciocínio, ou talvez tirando horas ou dias de esforço de outros trabalhos, etc.) Isso facilita a concentração nos problemas difíceis , e às vezes faz com que os problemas difíceis desapareçam.

Em uma palavra: elegância. Toda classe, todo método, toda condição, todo bloco, todo nome de variável: busca pela elegância.

Nunca culpe o usuário pelo que poderia ser corrigido com uma experiência mais limpa ou com uma documentação melhor. Frequentemente, os programadores assumem automaticamente que o usuário é um idiota que não pode fazer nada direito, quando o problema é uma experiência geral ruim ou falta de comunicação. Os programas devem ser usados, e tratar o usuário com desprezo é perder o ponto de programação em primeiro lugar.

Todo programador deve saber como usar o depurador e saber usá-lo bem .

Estruturas de dados

Como usar o Google

Avaliação de curto-circuito, embora seja uma das primeiras coisas que eles ensinam sobre operadores booleanos.

Como estimar com precisão quanto tempo um recurso levará para implementar. Mais importante, como transmitir que você não está mentindo quando envia essa estimativa.

O estilo de codificação é importante:

• indentação consistente é importante,
• o uso consistente do espaço em branco (por exemplo, ao redor dos operadores) é importante,
• posicionamento consistente de {} s assuntos,
• identificadores bem escolhidos são importantes,
• etc.

... e um bom design é importante.

Idealmente, o programador aprende essas coisas antes (ou durante) de sua primeira revisão de código. Na pior das hipóteses, o programador as aprende quando o chefe diz para fazer algumas alterações não triviais em algum código horrível às pressas.