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


52

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



Esse tipo de pergunta realmente me irrita. Só pode surgir da mente de alguém que vê o mundo em termos de preto e branco. Nem todo programador tem o mesmo trabalho e, se é o menor denominador comum que você está procurando, as respostas abaixo mostram que você acaba com uma lista de irritações de animais.
Capitão Sensible

Respostas:


92
  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).


17
Prefiro dizer "O bug provavelmente está no seu código", já que encontrei bugs nas bibliotecas de tempo de execução algumas vezes. Ainda estou para encontrar um bug do compilador. +1 de qualquer maneira.
Chinmay Kanchi

29
Se você nunca encontrou um bug de boa-fé no compilador, não é aventureiro o suficiente com sua codificação. ;)
Mason Wheeler

8
@Chinmay, @ spudd86, @Mason - sim ... e também encontrei minha parte de erros de compilador e de biblioteca em meus 30 anos de programação. Mas, na minha experiência, mais de 99% dos erros são (pelo menos em parte) a falha do meu código. Minha resposta deliberadamente exagera isso para mostrar que você deve sempre suspeitar do seu código primeiro.
Stephen C

5
Não sinto o medo irracional que as pessoas têm com a programação multithread. Eu suspeito que as pessoas que perpetuam essa visão não programam muito código multiencadeado. Não é tão difícil assim. +1 para todo o resto.
Steven Evers

4
Se você está trabalhando sobre o compilador, em seguida, o erro é provavelmente tanto em seu código eo compilador;)
Legooolas

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

8
+10000 se eu pudesse pelo comentário do controle de versão. O histórico e o registro de alterações são absolutamente indispensáveis ​​e são a razão pela qual você deve colocar tudo no controle de versão desde o início.
Legooolas 16/09/10

2
... e o repositório foi sincronizado com pelo menos um outro local. Importante no DVCS, mas também no VCS centralizado.

Nesse caso, o código não existe a menos que exista um item de trabalho que autorize o desenvolvedor a escrevê-lo.
Jesse C. Slicer

2
Vou acrescentar um para aprender a ler o código de outras pessoas. É mais difícil que muitos de nós percebemos, mas uma parte essencial da programação bem-sucedida.
bogeymin

mais um para aprender a ler o código de outras pessoas.
itsaboutcode

76

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



Se alguém não souber do que estou falando, leia o link de @ Adam. É um excelente resumo das armadilhas da computação em ponto flutuante.
Chinmay Kanchi

11
E se eles não sabem, podem estar entre o conjunto de pessoas que solicitam diariamente o stackoverflow.
Brian R. Bondy

11
@Brian: Tão verdadeiro. Eu gostaria que houvesse uma maneira de identificar perguntas explicadas pela aritmética de ponto flutuante. Você pode criar um aplicativo de pilha que exibe uma pergunta de ponto flutuante diferente todos os dias!
precisa saber é o seguinte

63

Não pare de aprender.


11
Relacionado: Não pare de acreditar.
Fishtoaster 21/09/10

3
Relacionados: Não pare de pensar no amanhã.
ocodo

7
Relacionado: Não pare a música.
Adamk

11
Relacionados: Não pare de se mexer! É a sua vida, continue andando, faça o que é certo, você tem que fazer o que é certo!
ocodo

44

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


4
SECA, sim! Como eu posso esquecer? ;-)
Maniero

Isso é tão importante que respondi novamente .

Prefiro dizer: REDUZIR CONDICIONAIS. Cada momento / if / for é um bug em potencial.
Zvrba

11
Você sabe, o engraçado do DRY é que ele se repete em todos os lugares. :) +1
Billy ONeal

39

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 .


2
Eu estava prestes a postar isso. Grande parte do trabalho de um programador é corrigir bugs, e muitas pessoas tendem a ser incapazes de fazê-lo (especialmente no código de outras pessoas).
Dov

+1 Eu fui de javascript / php para C # e me apaixonei por percorrer o código. Eu gostaria que as linguagens dinamicamente digitadas pudessem fazer um trabalho muito melhor nisso.
Evan Plaice

Outro comportamento estranho é o programador insistir em que todas as partes do programa estejam corretas enquanto o resultado estiver com defeito. "-Você não precisa imprimir a matriz no console para verificar se está classificada, porque a linha acima é array.sort ()." "-Bem ... você sabe, não está funcionando. Deve haver algo errado em algum lugar. Você não pode simplesmente defender seu código neste momento!"
gawi 27/09/10

2
Eu acho que o ponto de depuração para validar suas suposições em todo o seu programa. Às vezes, você precisa pescar algumas pistas. Isso tem que ser feito sistematicamente. É perfeitamente válido tentar algo que possa lhe dizer algo novo. Eu faço isso frequentemente.
gawi 27/09/10

37
  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.

2
Você pode esclarecer "Usar antes de reutilizar". Eu nunca ouvi isso antes.
Tjaart 12/05

34

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


Sim e não. Você parece com todos os professores que eu já tive na universidade ... todos eles nunca fizeram uma lambida de software em toda a sua vida. Conhecimento, sem habilidades, é inútil em nossa profissão.
Steven Evers

4
+1, é verdade. Sim, isso é algo que os tipos de torre de marfim gostam de dizer, mas não a torna menos verdadeira para o resto de nós nas trincheiras.
MAK

2
Noções básicas como ortografia? Its wrongdeve ser it's wrong, por exemplo.
Konerak

2
Não, conceitos básicos não se importam com erros de digitação, mas se preocupam com problemas de programação.
Clrod 18/09/10

5
É fácil aprender as etapas para fazer algo e geralmente difícil de descobrir quando você deve usá-lo e, mais importante, quando você pode usá-lo, mas não deve. Os livros didáticos são particularmente ruins em mostrar o como, mas não o porquê (e por que não).
HLGEM

27

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.


6
especifique especificamente aqueles com assert()- em toda parte. assert()irá ajudá-lo a documentar suas suposições e salvá-lo quando estiver errado.
Dustin

@Dustin +1 Não há como você se lembrar de todas as suas suposições - documente-as de forma programática e você será informado exatamente quando elas se tornarem suposições erradas.
Skilldrick 23/09/10

11
... a menos que compilado com NDEBUG.


17

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


Em teoria, é bom, exceto que o Google é péssimo para encontrar sintaxe específica : pesquisar termos como "referência a objetos" ou "isso", com um bilhão de resultados, e pesquisar idiomas como "$?" não dê nenhum resultado.
L0b0


14

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



13

É 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.


3
Eu acho que essa é a fonte do velho ditado: 90% do trabalho leva 90% do tempo. os últimos 10% levam os outros 90% do tempo '
GSto

Eu acho que muitas pessoas tendem a subestimar constantemente a complexidade. "Quão difícil pode ser X?" - últimas palavras famosas: /
Roman Starkov

@GSto Eu não quero trabalhar 180% do tempo, 100% é ótimo para mim!
Adamk

13

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.



11

Ponteiros, obviamente. :)


3
Os ponteiros são realmente necessários apenas em um subconjunto de idiomas para um pequeno subconjunto de tarefas. Para a maioria das tarefas, você pode (e deve ser capaz de) programar como se o conceito de ponteiro não existisse.
Chinmay Kanchi

14
@Chinay Kanchi Não. Os indicadores devem ser entendidos por todos.
alternativa

5
Isso realmente depende do que você quer dizer com ponteiro. Se você quer dizer ponteiros no estilo C que você pode manipular (o que eu assumi), eu argumentaria que um programador Java / C # / Python não precisa saber nada sobre eles. Se você quer dizer ponteiro, como nas "referências" de Java, ou seja, um ponteiro que não pode ser mexido, sim, é necessário algum conhecimento deles, apenas para impedir que você escorregue.
Chinmay Kanchi

@mathepic Você ficará muito abalado se souber quantos alunos de CS se formam todos os anos que não entendem a primeira coisa sobre indicadores. Se eu não tivesse saído da minha maneira de levar colocações a cada verão eu não teria sequer sido ensinado sobre ponteiros em C ou referências em Java ...
Mike B

5
@Chinmay: Um programador Python / Java / C # que não entende o conceito de ponteiros está perdido. L = [[]] * 2; L[0].append(42) Idiomas diferentes usam nomes diferentes, mas a indireção é essencial em qualquer lugar.

11

Código Completo 2 - capa a capa


você realmente deve saber isso antes de aceitar dinheiro para programar. Se você encontrar algo que não sabia, considere uma mudança de carreira ou um período intenso de estudo autodirigido para entender tudo. E depois peça desculpas aos seus colegas de trabalho. E cobre apenas os conceitos básicos de programação.
Tim Williscroft 7/10/10

11

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 .


2
Você me teve todo o caminho até dizer "sistema de tipos".

10

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


10

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


8

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.


8

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.






4

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.


2
ou aprender a guestimate bem e transmitir você não está guestimating ...;)
Billy Coover

4

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.