5 citações de programação famosas, explicadas

ser um programador é inscrever-se para uma vida de aprendizagem constante. A fonte de novos recursos, novas línguas, novas ferramentas, novas estruturas—nunca pára de jorrar. Mas a Ciência da computação também é um campo surpreendentemente tradicional baseado em princípios testados no tempo. Adicionamos programação orientada a objetos, hardware moderno e inteligência artificial. Mas, apesar destas mudanças, muitas das percepções que foram Articuladas pela primeira vez há uma geração ainda são verdadeiras hoje.Neste artigo, dissequei algumas das minhas citações favoritas sobre ciência da computação. A única condição que estabeleci é que cada citação tenha pelo menos vinte anos. Porque enquanto a velha tecnologia rapidamente se torna inútil, os antigos mandamentos dos nossos antepassados programadores têm muito mais poder de permanência.

“todos os problemas na ciência da computação podem ser resolvidos por outro nível de indireção.”- David Wheeler

aqui está uma citação compsci muitas vezes repetida que poucos desenvolvedores querem explicar. Mas é uma das minhas verdades de programação favoritas, porque atinge o coração do que é codificar.

a maneira mais fácil de começar a pensar sobre indireção é imaginar camadas. Por exemplo, digamos que você tem um pequeno projeto que precisa caber componente A componente B:

Ambos os componentes são padronizados, de modo que você não pode quebrá-los abrir e alterar a sua forma de trabalhar. Você poderia construir um componente totalmente novo (PlugTwoProngVariant), mas isso é muito trabalho e duplicação desnecessária. Uma melhor abordagem é adicionar uma camada entre as duas peças – um adaptador que se encaixa em ambos os componentes e se traduz entre eles.

now, if indirection was just about adding a new layer to FITT incompatible pieces together, it would be nice but narrow useful. Mas a ideia de resolver problemas construindo em torno deles é um conceito que se estende de baixo para o topo da computação. Você vê isso quando você está tentando encaixar um novo modelo de dados a uma antiga interface de usuário. Você vê isso quando você está tentando encaixar um aplicativo legado para uma nova infra-estrutura de serviços web. Você vê isso quando você precisa amarrar em características de nível superior, como o registro e caching, ou coordenar serviços de nível superior, como mensagens e transações. E no topo da pirâmide, você vai chegar a tópicos rarefeitos como a aprendizagem de máquinas (quando você não pode codificar o comportamento que você precisa, escrever outra camada de código que irá descobri-lo para você).

muitas pessoas lhe dirão que a codificação é sobre escrever instruções explícitas em uma linguagem que até mesmo computadores idiotas podem entender. Mas a citação de David Wheeler revela uma melhor percepção. Boa programação é sobre subir a escada da abstração para chegar às soluções mais gerais.

citação relacionada com bónus:

a indirecta é poderosa, mas há um custo para a complexidade. As pessoas raramente citam o comentário imediato de Wheeler sobre a indirecta.:

” mas isso normalmente vai criar outro problema.”- David Wheeler

That truth has kept programmers in business ever since.

sobre simplicidade

“a simplicidade é um pré-requisito para a confiabilidade.”- Edsger Dijkstra

não há escassez de programadores sábios avisando-nos para não complicar o nosso código. Mas poucos colocam o custo da complexidade mais claro do que o pioneiro da ciência da computação Holandês Edsger Dijkstra.

aqui está o insight: você não escolhe a simplicidade como um presente para o futuro. Você não faz isso porque você está antecipando a chance de reutilizar seu código, ou porque você quer que ele olhe mais limpo em uma revisão de código, ou porque você quer torná-lo mais fácil de modificar. (Embora todos estes benefícios são valiosos!) Você faz isso porque a simplicidade é um pré-requisito. Sem simplicidade, você nunca pode ter um código confiável que você pode confiar para gerir um negócio ou lidar com seus dados.

para aceitar o ponto de Dijkstra, precisamos redefinir o que “bom Código” significa. Não é o código mais curto. Não é necessariamente o código mais rápido. Definitivamente não é o código mais inteligente. É um código de confiança.

citação relacionada com bónus:

uma das melhores maneiras de manter o código simples é lembrar que menos é mais. Dijkstra oferece uma métrica para nos ajudar a ter isso em mente:

“se queremos contar linhas de código, não devemos considerá-las como linhas produzidas, mas como linhas gastas.'”- Edsger Dijkstra

On Readability and Rewrites

“é mais difícil ler o código do que escrevê-lo.”- Joel Spolsky

At first glance, this quote by software legend and StackOverflow co-creator Joel Spolsky seems true but engantively shallow. Sim, o código pode ser denso, terse, e terrivelmente longo. E não é apenas o código dos outros. Se você olhar para o seu próprio trabalho de um ano atrás, você provavelmente vai precisar de algum tempo para resolver a lógica que uma vez conheceu intimamente.Mas a visão de Spolsky vem com uma reviravolta. O perigo do código que você não pode ler não é apenas o óbvio (é difícil mudá-lo e melhorá-lo). Em vez disso, o maior perigo é que o código complexo pareça ser pior do que realmente é. Na verdade, o fardo de tentar entender o código já escrito de outra pessoa é tão grande que você pode ser tentado a fazer o que Spolsky chama o pior erro possível—decidir reescrever esse código do zero.Não é que reescritas não possam melhorar a arquitetura de um sistema. Podem mesmo. Mas estas melhorias vêm com grandes despesas. Eles reiniciam o relógio no teste e correção de bugs, duas atividades que levam muito mais tempo do que mera codificação. Reescritas são tentadoras porque elas jogam em um dos preconceitos mais comuns no desenvolvimento de software: nós subestimamos o esforço para fazer coisas que são conceptualmente simples. É por isso que os últimos 5% de um projeto leva 50% do tempo. As coisas fáceis podem ser surpreendentemente demoradas! E nada parece mais fácil do que resolver um problema que já resolveste.Então, se você não deve reescrever tudo para torná-lo perfeito, Qual é a melhor solução? A resposta é envolver todos os desenvolvedores em refactoring de tamanho de mordida constante. Isso lhe dá uma pequena melhoria contínua do Código-recompensas reais com riscos mínimos. Você pode melhorar a legibilidade no caminho.

Bônus relacionados citação:

Se você ainda está em dúvida sobre a importância da legibilidade, Martin Fowler ajuda a colocar em perspectiva:

“Qualquer idiota pode escrever código que um computador possa entender. Bons programadores escrevem códigos que os humanos podem entender.”- Martin Fowler

em outras palavras, o trabalho de um programador não é apenas fazer as coisas funcionarem, mas fazer as coisas fazerem sentido.

sobre repetição

“não se repita. Cada pedaço de conhecimento deve ter uma representação única, inequívoca e autorizada dentro de um sistema.”- Andy Hunt e Dave Thomas

cada programador que se preze sabe que a repetição é o coração de muito mal. Se você está escrevendo a mesma coisa em lugares diferentes, você está fazendo trabalho extra escrevendo, testando e debugging. Pior ainda, você está introduzindo a possibilidade de inconsistências — por exemplo, se uma parte do código é atualizada, mas outras rotinas similares não são trazidas de acordo. Um programa inconsistente é um programa em que não se pode confiar, e um programa em que não se pode confiar já não é uma solução viável.

no Entanto, o código não é o único lugar onde a repetição causa estragos. Esta versão da famosa regra” don’t repeat yourself ” (DRY) expande o princípio de não duplicação para cobrir os outros lugares onde inconsistências podem se esconder. Já não estamos a falar de duplicação de código. Também estamos falando de repetição em um sistema – e um sistema tem muitas maneiras diferentes de codificar conhecimento. Eles incluem::

• instruções de Código
• comentários de Código
• Desenvolvedor ou a documentação do cliente
• esquemas de Dados (por exemplo, tabelas de banco de dados)
• Outras especificações, como planos de teste, documentos de fluxo de trabalho, e as regras de compilação

Todas essas camadas podem sobrepor-se uns com os outros. E quando o fazem, arriscam-se a introduzir diferentes versões da mesma realidade. Por exemplo, o que acontece se a documentação descreve uma maneira de trabalhar, mas a aplicação segue outra? Quem tem a posse da verdade? O que acontece se as tabelas de banco de dados não coincidirem com o modelo de dados no código? Ou os comentários descrevem a operação de um algoritmo que não corresponde à sua implementação real? Todos os sistemas precisam de uma representação única e autorizada da qual tudo o resto deriva.Incidentalmente, versões concorrentes da verdade não são apenas um problema em projetos de pequena escala ou código mal projetado. Um dos melhores exemplos irrompeu no público com a batalha entre XHTML e HTML5. Um campo argumentou que a especificação era a verdade oficial, e os navegadores precisavam ser corrigidos para segui-la. A outra facção alegou que o comportamento do navegador era o padrão de facto, porque era isso que os designers tinham em mente quando escreveram páginas web. No final, a versão do navegador da verdade ganhou. A partir desse ponto, o HTML5 foi o que os navegadores fizeram — incluindo os atalhos que permitiram e os erros que aceitaram.Citação relacionada com bónus:

a possibilidade de o código e os comentários se contradizerem abriu um debate acalorado sobre se os comentários fazem mais mal do que bem. Os proponentes da programação extrema tratam-nos com desconfiança.:

” o código nunca mente; os comentários às vezes mentem.”- Ron Jeffries

em problemas difíceis

“há apenas duas coisas difíceis na ciência da computação: invalidação de cache e nomear coisas.”- Phil Karlton

à primeira vista, esta citação parece uma piada divertida, mas comum de programação. O contraste entre algo que soa difícil (invalidação de cache) e algo que soa indolor (nomear coisas) é instantaneamente relacionável. Cada programador tem investido horas de trabalho corrigindo uma questão ridiculamente trivial, como um par de parâmetros passados na ordem errada ou uma variável inconsistentemente capitalizada (obrigado JavaScript). Enquanto os humanos precisarem de fazer parceria com máquinas para fazer as coisas, a programação vai ser um mashup de planejamento de Sistema de alto nível e erros triviais.Mas se der uma segunda olhada na citação de Phil Karlton, há mais para desempacotar. Nomear as coisas não é difícil só porque a vida de um programador é regularmente arruinada por pequenas dores de cabeça. É também porque a questão de nomear é na verdade a borda do trabalho mais importante de cada programador: design de software. Por outras palavras, como se escreve um código claro, limpo e consistente?

existem muitas maneiras de começar a dar nomes errados. Nós todos vimos as variáveis chamado depois de tipos de dados (myString, obj), abreviaturas (pc para o catálogo de produtos), trivial, detalhe de implementação (swappable_name, formUserInput), ou mesmo nada (ret_value, tempArray). É fácil cair na armadilha de nomear uma variável baseada no que você está fazendo com ela naquele momento, em vez do que ela contém. E os valores booleanos são particularmente complicados – o progress define quando o progresso começa, indica que você precisa exibir informações de progresso na UI, ou marcar algo completamente diferente?

Mas os nomes de variáveis são apenas o começo. Nomear classes levanta a questão de como você divide o código em partes independentes. Nomear membros públicos forma como você apresenta a interface que permite que uma parte de sua aplicação interaja com outra. Bloquear estes nomes não descreve apenas o que um pedaço de código pode fazer, determina o que ele vai fazer.Citação relacionada com bónus:

“existem duas coisas difíceis na ciência da computação: invalidação de cache, nomear coisas, e erros off-by-one.”- Leon Bambrick