a eliminação de carga é inevitável

é incontroverso que os novos desenvolvedores não podem deixar de cultivar carga.Eles simplesmente não aprenderam o suficiente da pilha para realmente entender o que está acontecendo sob o capô e por que as coisas devem ser feitas de uma certa maneira.por exemplo, em um dos meus primeiros cursos de programação aprendemos que em Java o ponto de entrada para o programa é:

public static void main(String args)

demorou anos para chegar ao ponto onde eu entendo toda a parte da assinatura do método.Mesmo que me explicassem na altura, não o teria compreendido.Eu teria que entender o método de visibilidade, classe vs. métodos de instância, tipos de retorno, tipos de parâmetro, matrizes (em oposição a lista/vetores), argumentos de linha de comando (e como eles são analisados pelo shell), e vários detalhes sobre o Java da aplicação.e não faz mal.Acontece que você quase não precisa entender nada disso para escrever linha de comando ou até mesmo programas GUI em Java.

não esperamos que os novos desenvolvedores saibam os detalhes de cada decisão que tomam.Eles não estão programando há tempo suficiente para entender todos os detalhes sobre cada parte da pilha.

também não podemos esperar que eles saibam que o git armazena compromete-se em um dirigido acíclico gráfico e cada ramo é um ponteiro para um nó do grafo.É bom o suficiente que eles podem fazer git checkout e git commit e prosseguir com seu trabalho.E é bom o suficiente se eles seguem uma regra como “nunca avançar para a fusão” (ou “sempre avançar para a fusão”).

mas mesmo para os programadores seniores é inevitável.Que senior dev realmente entende todos os comandos git que eles têm para procurar no Stack Overflow?Ou o awkesed porção do one-liner que eles procuraram ontem no GitHub?Ou todos os cabeçalhos na resposta HTTP com os quais a API da aplicação web responde?Ou quando usar o HTTPS vs. o URL SSH do seu repo GitHub?Ou como configurar melhor a sua instância de PostgreSQL local?Ou o teu caso Neo4j?Ou como depurar a sua configuração rvm/rbenv/chruby / virtualenv sem a destruir e reconstruir do zero?

A única maneira de não ser um culto de carga é saber tudo.E ninguém sabe tudo.

a eliminação da carga é boa

a eliminação da carga é boa quando utilizada responsibly.It poupa-nos de termos de saber tudo.Quando usado bem, é o ato de alavancar a experiência duramente conquistada de todos os outros no campo.Sem dúvida, usando qualquer abstração sem entender como ela funciona (que é todo o ponto da abstração!) é a eliminação de carga pela definição de Lippert.além disso, a eliminação da carga é muitas vezes uma boa escolha.”Estas pessoas parecem saber o que estão a fazer, por isso vou segui-las,” é uma estratégia perfeitamente racional.de facto, a comunidade de programação incentiva activamente a eliminação de carga.Quando dizemos às pessoas, “não usem o estado global”, ou, “sigam o PEP8”, estamos a dizer-lhes para o culto de carga.Por exemplo, um desenvolvedor idealmente entenderia as (às vezes não assim) maneiras sutis do estado global pode mordê-lo, mas até que o entendimento esteja lá, é melhor apenas evitá-lo.alguns outros grandes usos da eliminação de carga:

• “Convenção sobre a configuração” como visto nos carris (e seus clones miríades), Django e Ember.js
• guias de Estilo e de suas ferramentas, como Rubocop, JSLint, e Auto PEP8
• Muitas ferramentas de análise estática, como CodeClimate, Fedor, Flay, e Malhar
• O 12factor app diretrizes
• Code smells

Como carga de culto de forma responsável

Obviamente, carga culting tem algumas grandes desvantagens, mas agora nós temos visto algumas lados, também.Gostaríamos de usar ferramentas e técnicas que façam o trabalho agora, sem sempre ter que entender completamente por que eles funcionam.Em vez de evitarmos completamente a eliminação de carga, como é que podemos combater eficazmente o culto da carga?

uma grande ressalva: o risco inerente de carga culting é que você não será capaz de prever o que vai dar errado, ou até mesmo a classe de problemas que você pode encontrar, porque, fundamentalmente, não entendem as decisões que estão tomando.Dito isto, aqui estão algumas dicas.

Write tests

você pode escrever testes automatizados para garantir que seu código funciona como esperado, mesmo que você não entenda por que o código funciona.Um exemplo simples seria se você copiar e colar um algoritmo de ordenação a partir de Stack Overflow, você pode escrever um teste para ele para se certificar de que está funcionando.

tenha cuidado, no entanto, porque o teste não é tão bom em provar que não há efeitos secundários inesperados ou borda cases.In o exemplo do algoritmo de ordenação, você não vai saber com que casos de borda você precisa se preocupar.

Refactor impiedosamente

quanto mais limpo mantiver o código, mais fácil será raciocinar sobre quando uma decisão de eliminação de carga precisa de ser alterada.E lembre-se, você não pode refutar eficazmente sem testes.isolar o código de carga abatida

, quando possível, isolar o código de carga abatida numa classe ou módulo.Quanto mais você pode isolá-lo, mais você limita seus danos potenciais.Além disso, quanto mais isolado for, mais fácil será substituir ou reescrever uma vez que você entenda mais sobre ele.

não carga culto em partes críticas de seu aplicativo

Por exemplo, se a alta concorrência é uma necessidade absoluta para o seu aplicativo, você provavelmente não pode sair com a cópia de alguns threading código de Estouro de Pilha.Mesmo escolhendo uma linguagem que inerentemente lida bem com a concorrência (como Elixir, Go, ou Clojure) não vai magicamente resolver o seu problema.Infelizmente (ou felizmente), você realmente terá que cavar e aprender algo.

não se cult de carga se o fracasso levar a coisas ruins acontecendo

Se segurança das pessoas, Privacidade, dinheiro, etc. estão em risco, não carreguem cult.Como um exemplo óbvio, se o pace-maker de alguém corre um certo c one-liner que você copiou de Stack Overflow, você maldito-bem melhor saber por que seu pequeno truque funciona e quais os casos de falha e efeitos colaterais são.

evite a eliminação da carga ao lidar com diferentes input

por exemplo, se você não conhece awk super bem e a entrada para o seu awk one-liner virá da entrada do utilizador, é provável que se quebre.Se você pode prever as diferentes formas que sua entrada pode tomar, isso vai ajudar, mas você deve ter em mente que é provável que quebre os casos de entrada que você não foi capaz de prever.

Monitor na produção

apenas porque funciona na sua máquina, não assuma que irá funcionar na produção onde o ambiente difere e os UTILIZADORES fazem coisas que nunca considerou.Monitorar erros, exceções, falhas de asserção, e desempenho pode deixá-lo saber se algo está errado antes de seus usuários, clientes ou chefe percebê-lo.

revisão de código, programação de pares, ferramentas de análise estática, etc.

obtenha outros olhos, virtuais ou não, para olhar para o seu código.A programação de pares e a revisão de códigos são exemplos óbvios, mas Ferramentas de análise estática (por exemplo, CodeClimate) também podem ser úteis.Além de pegar erros óbvios, eles são especialmente úteis para apontar o código que pode nem sempre funcionar como esperado.

Mova-se para uma compreensão mais profunda

começando com a eliminação de carga, quando você decidir mergulhar profundamente no assunto você já terá algum contexto.O caminho para uma compreensão mais profunda pode ser auto-estudo, orientação, par de programação, ou apenas fazê-lo você mesmo para o bem de aprender.

esta é uma notícia antiga

as dicas acima enumeradas são provavelmente todas as coisas que você já ouviu antes.Isso é porque estamos todos a trabalhar com conhecimento limitado.Todos nós cult de carga o tempo todo e desenvolvemos intuição, técnicas e diretrizes para que possamos avançar com conhecimento parcial e limitar os danos que podemos fazer.Em vez de nunca ser um culto de carga, os bons desenvolvedores aprendem a ser um culto de carga de forma eficaz.