Quais são os conceitos de programação que devo dominar para ter uma compreensão profunda do meu ofício (programação)? [fechadas]


13

Em ordem de importância, se é possível fazê-lo e talvez não, quais são os fundamentos mais importantes de se saber programar. Algoritmos, iteração, recursão, etc?

Note que onde eu coloco etc. é onde está minha pergunta. Recentemente, li um post na Internet que dizia que 9 em cada 10 programadores não podem ofegar de programa!

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Quero ter um conhecimento profundo do que realmente estou tentando realizar ao programar e uma compreensão exaustiva das ferramentas básicas à minha disposição. Basicamente, quero poder pintar com todas as cores do vento.


3
O post de Jeff Atwood não é sobre conhecimento profundo de programação ... É sobre a realidade que muitas pessoas não têm idéias básicas e fundamentais sobre programação e como a falta dessas idéias fundamentais os impede de desenvolver habilidades de programação significativas.
Robert Harvey

2
Não entendo por que essa pergunta foi encerrada. É uma pergunta que foi estrelada 5 vezes e tem muitas respostas úteis. Esse é o tipo de informação que eu quero encontrar - apenas porque não há uma resposta simples, não significa que as informações não são de bom valor, talvez programmers.stackexchange.com precise reavaliar seus critérios para fechar perguntas.
Rocklan

@LachlanB Votei em reabrir ... precisa de mais 4 votos para ter sucesso #
Michael Brown

Acho que é uma boa pergunta, mas qualquer resposta razoável será muito longa para o formato deste site. Qualquer bom currículo universitário abrangerá esses conceitos, e o fato de que esse currículo exige alguns anos de estudo e prática dedicados, seguido de anos adicionais trabalhando em projetos reais, deve deixar claro por que a resposta não se encaixa aqui.
Giorgio

Respostas:


18

Esta lista é um começo ... você está fazendo uma grande pergunta!

  • Como esclarecer e anotar o que os clientes desejam ("requisitos"). Esta é uma arte em si mesma. Se você puder fazer isso, seu trabalho de programação será muito melhor.
  • Como estimar e planejar o projeto. As pessoas vão pedir uma estimativa, esteja preparado.
  • Como revisar construtivamente o código de outras pessoas.
  • Padrões de design. Este é um grande problema. Mas não os use com zelo demais.
  • Aprenda a diferença entre solicitações de bug, problema e recurso
  • Mantenha-se atualizado com estruturas / bibliotecas. Você não precisa usá-los, mas precisa saber o que eles fazem e seus prós / contras. Se algo parece muito difícil, provavelmente existe (espero) uma maneira muito mais fácil de fazer as coisas.
  • Como documentar algoritmos complicados em um fluxograma ou apenas escrevê-los em inglês. Não espere que alguém passe dois dias tentando fazer engenharia reversa do seu código.
  • Como organizar sua estrutura de código para que outras pessoas possam entendê-la
  • Como comentar seu código
  • Como escrever testes de unidade
  • Saiba o que está acontecendo sob o capô. Por exemplo, chamar um serviço da Web - o que ele está realmente fazendo?
  • Como abstrair a lógica em classes.
  • Como refatorar código
  • Aprenda a essência de várias linguagens de programação. Você ficaria surpreso com o que pode aprender com outras áreas
  • Como dizer a outros programadores o que escrever.
  • Como explicar à gerência o que você está fazendo e por quê.
  • Como Peter disse, como depurar. Eu concordo com tudo o que ele diz, programadores reais depuram, não apenas adivinhem.
  • Como trabalhar com maníacos. Existem muitos por aí.
  • Como começar coisas feitas. Toda a teoria do mundo não ajudará se você não conseguir fazer as coisas.

Respondi a outra pergunta em linhas semelhantes (com conteúdo semelhante) aqui:

dicas, diretrizes, pontos a serem lembrados para a renderização de código profissional?


1
+1: OBTENHA MATERIAL! Há alguns anos, publiquei um discurso retórico que dizia que essa era a característica definidora de um engenheiro - eles fazem as coisas. Às vezes não é bonito, e às vezes você terá que voltar e refazê-lo, mas no final do dia eles fazem as coisas!
precisa saber é o seguinte

@PeterRowell: você pode encontrar este uma leitura interessante: brandonsavage.net/when-to-write-bad-code
Marjan Venema

Infelizmente, a pergunta não é realmente a que se encaixa na filosofia de perguntas e respostas e no formato do site, mas que não minimiza o valor da sua resposta. Se você quiser expandi-lo e adicionar um pouco de explicação para cada ponto, será um ótimo post para o blog da comunidade .
precisa saber é

@MarjanVenema: Sim, concordo plenamente com ele. Nos anos 80, fui encarregado de escrever uma especificação para um novo editor, a ser aprovado antes de começar a codificar. Eu olhei para aquela maldita tela em branco por mais de uma semana tentando descobrir como descrever algo que eu não entendi. Meu gerente expressou seu descontentamento com a minha falta de progresso. Após um fim de semana de três dias, ele tinha um rascunho em sua mesa. Ele perguntou o que havia acontecido, e eu disse que escrevi o editor no fim de semana e depois simplesmente escrevi uma especificação do que eu estava trabalhando. Reescrevi parte do código, mas era principalmente refatoração / limpeza.
precisa

1
@YannisRizos - eu estaria interessado em escrever um blog sobre isso. Gostaria de me enviar um e-mail com alguma orientação ou devo escrever algo?
Rocklan 30/01

22

Sob o título " etc. " vem algo que pode facilmente levar 50% ou mais do seu tempo.

Aprenda a depurar.

Isso significa aprender o método científico . Quero dizer, realmente aprendendo. E depois aplicá-lo com brutal auto-honestidade . Aprenda a declarar com precisão o que você sabe que é verdade, o que você sabe que não é verdade e as coisas que você não sabe. Toda vez que você atribui um item à categoria errada, você acaba tornando sua vida muito mais difícil.

Aprenda a dizer "eu acho" em vez de "eu sei". Você só diz "eu sei" quando "pensa" que algo é verdadeiro (ou falso), e então o prova!

Muitos erros são triviais, mas podem ser difíceis de ver porque você "sabe" qual deve ser o código ... exceto que não. Encontre um amigo para explicar. Peça que eles sejam um "idiota especialista": alguém que não conhece o seu código, mas que você sabe que não pode deixar de lado o BS. Não se surpreenda se, no meio de uma descrição para eles, você parar de repente e dizer: "e assim você pode ... ver ... ver isso ... sh * t. Obrigado."

Erros não triviais requerem um arsenal de técnicas. Um clássico que pode rapidamente destacar a maioria dos bugs não relacionados ao tempo é o Wolf Fence, no Alasca. Há um lobo em algum lugar do Alasca; construir uma cerca cortando o estado ao meio. De que lado está o lobo? Corte esse lado ao meio. Espuma, enxágüe, repita. Fazer isso 20 vezes em locais bem escolhidos no código reduz a área em que o bug (lobo) pode estar para 1/1048576. Mate aquele lobo.

Dica: procure ondas de mão - físicas, mentais ou qualquer outro tipo. Assim que você (ou seu colega) recuar / desviar / minimizar a atenção dada a uma parte do código, fique totalmente irritado . Como a área onde você conhece o bug não pode ser, mesmo que você tenha passado horas / dias procurando a coisa d * mn e ainda não a encontre ... essa é a localização de maior probabilidade para o bug. Ninguém recebe um 'tchau' , ninguém (incluindo a máquina, o sistema operacional, o compilador ou você ) recebe qualquer tipo de "respeito devido". Há um erro. Período. Fim da frase. Agora vá matar a coisa d * mn.

Não conheço nenhuma escola que ensine a depuração como um assunto em si mesma. Na IMNSHO, essa pode ser a evidência mais flagrante de que eles (universidades / professores) não estão ensinando você a ser um programador, mas sim ensinando você a ser ... como eles? Duro? Possivelmente. Verdade? Tirar suas próprias conclusões. Agora prove.


Você pode estar interessado no Squeeze Saff , uma técnica descrita por Kent Beck que utiliza testes e refatoração para depurar: Hit 'em alta, Hit' em baixo : Teste de Regressão e Squeeze Saff por Kent Beck, Três Instituto Rios (Abstract: Para isole efetivamente um defeito, comece com um teste no nível do sistema e progressivamente alinhado e podado até que você tenha o menor teste possível que demonstre o defeito.) Parece muito com o Wolf Fence, usando os recursos de testes e de refatoração de IDEs.
Jörg W Mittag

1
Ótima resposta - qualquer um pode escrever código, os verdadeiros programadores debugam.
Rocklan 30/01

@ JörgWMittag: Sou um grande fã de testes de regressão automatizados. Eu o usei pela primeira vez em um projeto de mecanismo de busca em meados dos anos 80, e fiquei chocado (chocado!) Com as coisas que caíam depois do que parecia ser uma mudança "menor" em algum código de aparência inocente. (Nota: este era 200.000 SLOC de C, e problemas de gerenciamento de memória foram o bane de nossa existência.)
Peter Rowell

3

Receio que essa seja uma pergunta bastante grande para qualquer pessoa responder conclusiva ou autoritariamente, principalmente porque você deseja uma lista priorizada. Existem muitos programadores por aí, e eles trabalham em coisas muito diferentes - com certeza, os fundamentos permanecem os mesmos, mas o que você precisa para se manter ativo em sua memória pode ser realmente diferente, e, de fato, existem muitas tarefas nas quais você pode ficar bonito alto nível sem ir mais fundo.

Parece, no entanto, que você está realmente preocupado com como ser um desenvolvedor melhor, e não apenas com uma troca de dinheiro. Acho isso admirável e posso compartilhar algumas das coisas que me ajudaram a aprender a programar.

Praticamente toda a programação se resume a algoritmos e estruturas de dados. Eles, por sua vez, são exemplos da questão maior - como modelamos coisas e processos do mundo real em uma representação que um computador possa entender. Se você está apenas começando, pode ser útil usar uma linguagem de programação de nível superior (como Java, Python, qualquer que seja) para se familiarizar com a implementação de estruturas e algoritmos de dados.

Em um determinado momento, tendo brincado com estruturas e algoritmos de dados, você pode começar a fazer essa pergunta difícil "mas como passamos de dizer ao computador o que fazer, para o computador realmente fazer isso?" Depois, você pode ver como um computador realmente calcula - como a memória e a CPU trabalham juntas para executar instruções, como os sistemas operacionais abstraem o hardware para que você possa escrever um programa que, digamos, abre um arquivo, sem codificar para um determinado nível inferior interface do disco rígido.

Este é provavelmente um bom ponto de partida - como algoritmos e estruturas de dados modelam problemas do mundo real e como um computador realmente executa a computação. Conhecer o último é muito útil para dominar linguagens de nível inferior, como C, que utilizam muito menos fumaça e espelhos do que OO e linguagens de script :)


2

YAGNI : "Sempre implemente as coisas quando você realmente precisa delas, nunca quando você apenas prevê que precisa delas."

Na minha experiência, é comum que "programadores" prevejam muitos casos no futuro e tentem "melhorar" o código adicionando códigos para antecipá-los! Na maioria dos casos, o código adicionado apenas incha o código e adiciona complexidade ao código.


1

A coisa mais importante a saber sobre ser um programador é que escrever código é uma tarefa árdua, e uma atitude profissional de produzir o que você está sendo pago para produzir o levará mais longe do que qualquer aprendizado esotérico.

Aprenda a entrar na zona. Por isso, quero dizer o estado mental quando você está focado apenas em sua tarefa e pode começar a manter muitas coisas na cabeça e como elas interoperam de uma só vez. Quando você tiver o hábito de entrar na zona à vontade, comece a se preocupar com o resto. Até que você possa digitar código como algum tipo de código, o resto é praticamente inútil.

EDITAR:

Se você não acredita nisso e me rebaixou, acredito que não saiba se tem a determinação de fazê-lo por 20 anos. Eu sei que sim porque aceito isso. ;)


0

Uma pergunta recente, relacionada de alguma forma a esta, e a resposta tinham um link para este blog que discute o mesmo problema de um ângulo diferente.

Provavelmente o conceito mais importante para qualquer desenvolvedor é "humildade" .... Depois de aceitar que não sabe tudo, você está aberto para explorar soluções. A maioria das pessoas que escreve blogs sobre programação está no percentil mais alto, e o problema é que muitos ainda precisam controlar suas tendências narcísicas ... e é por isso que eles escrevem no blog ... Você precisa aprender a identificar esses blogueiros e ignorar há reclamações

O blog vinculado nada mais é do que um discurso retórico - em todos os setores, as reclamações de que os recém-formados são inúteis são comuns, que leva anos para serem úteis e produtivas. Talvez o problema seja que esses auto-proclamados gurus realmente esperam demais e tenham esquecido que, uma vez que não seriam capazes de resolver o FizzBuzz. Nem todos podem estar no top 10 do percentil, por definição, metade dos programadores está abaixo da média ......


Eu concordo que as pessoas discordam muito, mas acho que o ponto das postagens que você vinculou acima é que as pessoas que não sabiam como resolver o FizzBuzz estavam se candidatando a trabalhos de programação , o que é diferente de ser apenas um iniciante e precisar encerrar sua cabeça em torno de idiomas de programação. No entanto, concordo com você sobre a humildade, e muitas pessoas parecem não saber o que é isso.
precisa saber é o seguinte
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.