Os humanos só lutam com a arte e a ciência da programação de computadores há cerca de meio século. Comparada com a maioria das artes e ciências, a ciência da computação em muitos aspectos ainda é apenas uma criança, caminhando contra paredes, tropeçando nos próprios pés e, ocasionalmente, jogando comida na mesa.

Como consequência de sua relativa juventude, não acredito que tenhamos um consenso ainda sobre o que é uma definição adequada de 'bom código', pois essa definição continua a evoluir. Alguns dirão que “bom código” é um código com 100% de cobertura de teste. Outros dirão que é super rápido e tem um desempenho matador e será executado de forma aceitável em hardware com 10 anos de idade.

Embora todos esses sejam objetivos louváveis ​​para desenvolvedores de software, arrisco-me a lançar outro alvo na mistura: sustentabilidade. Especificamente, 'bom código' é um código que pode ser mantido de forma fácil e imediata por uma organização (não apenas por seu autor!) E durará mais do que apenas o sprint em que foi escrito. A seguir estão algumas coisas que descobri em meu carreira como engenheiro em grandes e pequenas empresas, nos EUA e no exterior, que parecem se correlacionar com softwares “bons” e sustentáveis.

Nunca se contente com um código que simplesmente 'funciona'. Escreva código superior. Tweet

Mandamento no. 1: Trate seu código da maneira que você deseja que o código de outras pessoas o trate

Estou longe de ser a primeira pessoa a escrever que o público principal do seu código não é o compilador / computador, mas quem quer que seja o próximo a ler, entender, manter e aprimorar o código (o que não será necessariamente você daqui a seis meses ) Qualquer engenheiro que valha a pena pode produzir um código que “funciona”; o que distingue um engenheiro excelente é que ele pode escrever código sustentável com eficiência, que dá suporte a um negócio a longo prazo, e tem a habilidade de resolver problemas de maneira simples e clara e sustentável.

Em qualquer linguagem de programação, é possível escrever código bom ou código ruim. Assumindo que julgamos uma linguagem de programação por quão bem ela facilita a escrita de um bom código (deve ser pelo menos um dos critérios principais, de qualquer maneira), qualquer linguagem de programação pode ser 'boa' ou 'ruim', dependendo de como é usada (ou abusada )

tutorial de design de interface de usuário ios

Um exemplo de linguagem que muitos é considerada “limpa” e legível é o Python. A linguagem em si impõe algum nível de disciplina de espaço em branco e as APIs integradas são abundantes e bastante consistentes. Dito isso, é possível criar monstros indizíveis. Por exemplo, pode-se definir uma classe e definir / redefinir / undefine todo e qualquer método nessa classe durante o tempo de execução (frequentemente referido como patching de macaco). Essa técnica naturalmente leva a, na melhor das hipóteses, uma API inconsistente e, na pior, um monstro impossível de depurar. Alguém pode ingenuamente pensar: 'Claro, mas ninguém faz isso!' Infelizmente sim, e não leva muito tempo para navegar pypi antes de encontrar bibliotecas substanciais (e populares!) que (ab) usam o monkey patching extensivamente como o núcleo de suas APIs. Recentemente, usei uma biblioteca de rede cuja API inteira muda dependendo do estado da rede de um objeto. Imagine, por exemplo, ligar para client.connect() e às vezes obtendo um MethodDoesNotExist erro em vez de HostNotFound ou NetworkUnavailable.

Mandamento # 2: O bom código é facilmente lido e compreendido, em parte e no todo

Um bom código é facilmente lido e entendido, em parte e no todo, por outros (bem como pelo autor no futuro, tentando evitar o “Eu realmente escrevi isso?” síndrome).

Por 'parte' quero dizer que, se eu abrir algum módulo ou função no código, devo ser capaz de entender o que ele faz sem ter que ler também todo o resto da base de código. Deve ser o mais intuitivo e autodocumentado possível.

O código que faz referência constante a detalhes minuciosos que afetam o comportamento de outras partes (aparentemente irrelevantes) da base de código é como ler um livro em que você precisa consultar as notas de rodapé ou um apêndice no final de cada frase. Você nunca passaria da primeira página!

Algumas outras idéias sobre a legibilidade 'local':

• Bem encapsulado o código tende a ser mais legível, separando preocupações em todos os níveis.

  
  
  

• Os nomes são importantes. Ativar Pensando rápido e devagar sistema 2 maneira pela qual o cérebro forma pensamentos e coloca algum pensamento real e cuidadoso em nomes de variáveis ​​e métodos. Os poucos segundos extras podem pagar dividendos significativos. Uma variável bem nomeada pode tornar o código muito mais intuitivo, ao passo que uma variável mal nomeada pode levar a headfakes e confusão.

• A inteligência é o inimigo. Ao usar técnicas sofisticadas, paradigmas ou operações (como compreensões de lista ou operadores ternários), tome cuidado para usá-los de uma maneira que torne seu código Mais legível, não apenas mais curto.

  
  
  

• Consistência é uma coisa boa. A consistência no estilo, tanto em termos de como você posiciona os colchetes, mas também em termos de operações, melhora muito a legibilidade.

• Separação de preocupações . Um determinado projeto gerencia um número incontável de suposições localmente importantes em vários pontos da base de código. Exponha cada parte da base de código ao mínimo possível dessas preocupações. Digamos que você tenha um sistema de gerenciamento de pessoas em que um objeto pessoa às vezes pode ter um sobrenome nulo. Para alguém escrevendo código em uma página que exibe objetos pessoais, isso pode ser muito estranho! E a menos que você mantenha um manual de “suposições estranhas e não óbvias que nossa base de código tem” (eu sei que não), o programador da página de exibição não saberá que os sobrenomes podem ser nulos e provavelmente escreverá código com um ponteiro nulo exceção nele quando o caso nulo do último nome aparece. Em vez disso, trate desses casos com APIs e contratos bem elaborados que diferentes partes de sua base de código usam para interagir umas com as outras.

  como aprender c e c ++

Mandamento # 3: Bom código tem um layout e arquitetura bem pensados ​​para tornar o estado de gerenciamento óbvio

O estado é o inimigo. Por quê? Porque é a parte mais complexa de qualquer aplicativo e precisa ser tratada de forma muito deliberada e cuidadosa. Problemas comuns incluem inconsistências de banco de dados, atualizações parciais de IU em que novos dados não são refletidos em todos os lugares, operações fora de ordem ou apenas código complexo com instruções if e ramificações em todos os lugares, tornando o código difícil de ler e ainda mais difícil de manter. Colocar o estado em um pedestal para ser tratado com muito cuidado e ser extremamente consistente e deliberado em relação a como o estado é acessado e modificado simplifica drasticamente sua base de código. Algumas linguagens (Haskell, por exemplo) impõem isso em um nível programático e sintático. Você ficaria surpreso com o quanto a clareza de sua base de código pode melhorar se você tiver bibliotecas de puro funções que não acessam nenhum estado externo e, em seguida, uma pequena área de superfície de código com estado que faz referência à funcionalidade pura externa.

Mandamento # 4: O bom código não reinventa a roda, ele se sustenta nos ombros de gigantes

Antes de potencialmente reinventar uma roda, pense em quão comum é o problema que você está tentando resolver ou a função que está tentando desempenhar. Alguém pode já ter implementado uma solução que você pode aproveitar. Reserve um tempo para pensar e pesquisar essas opções, se apropriado e disponível.

o que é o windows escrito em

Dito isso, um contra-argumento completamente razoável é que as dependências não vêm de 'graça' sem qualquer desvantagem. Ao usar uma biblioteca de terceiros ou de código aberto que adiciona algumas funcionalidades interessantes, você está assumindo o compromisso e se tornando dependente dessa biblioteca. Esse é um grande compromisso; se for uma biblioteca gigante e você só precisar de um pouco de funcionalidade, você realmente quer o fardo de atualizar toda a biblioteca se você atualizar, por exemplo, para Python 3.x? E, além disso, se você encontrar um bug ou quiser melhorar a funcionalidade, ou você depende do autor (ou fornecedor) para fornecer a correção ou melhoria ou, se for de código aberto, encontre-se na posição de explorar um ( potencialmente substancial) com a qual você não está completamente familiarizado ao tentar corrigir ou modificar uma parte obscura de funcionalidade.

Certamente, quanto mais bem utilizado for o código do qual você depende, menos provável será que você tenha que investir tempo na manutenção. O resultado final é que vale a pena você fazer sua própria pesquisa e fazer sua própria avaliação sobre se deve ou não incluir tecnologia externa e quanta manutenção essa tecnologia específica adicionará à sua pilha.

Abaixo estão alguns dos exemplos mais comuns de coisas que você provavelmente não deveria reinventar na era moderna em seu projeto (a menos que SEJA seus projetos).

Bancos de dados

Descobrir qual de BONÉ que você precisa para o seu projeto e escolha o banco de dados com as propriedades corretas. Banco de dados não significa mais apenas MySQL, você pode escolher entre:

• SQL com esquema “tradicional”: Postgres / MySQL / MariaDB / MemSQL / Amazon RDS, etc.
• Armazenamentos de valores-chave: Redis / Memcache / Ripples
• NoSQL: MongoDB / Cassandra
• Bancos de dados hospedados: AWS RDS / DynamoDB / AppEngine Datastore
• Levantamento pesado: Amazon MR / Hadoop (Hive / Pig) / Cloudera / Google Big Query
• Coisas doidas: Erlang’s Mnesia, iOS’s Core Data

Camadas de abstração de dados

Você deve, na maioria das circunstâncias, não gravar consultas brutas em qualquer banco de dados que escolheu usar. Muito provavelmente, existe uma biblioteca para sentar-se entre o banco de dados e o código do seu aplicativo, separando as preocupações de gerenciar sessões de banco de dados simultâneas e detalhes do esquema de seu código principal. No mínimo, você nunca deve ter consultas brutas ou SQL embutido no meio do código do seu aplicativo. Em vez disso, envolva-o em uma função e centralize todas as funções em um arquivo chamado algo realmente óbvio (por exemplo, “queries.py”). Uma linha como users = load_users() , por exemplo, é infinitamente mais fácil de ler do que users = db.query(“SELECT username, foo, bar from users LIMIT 10 ORDER BY ID”). Esse tipo de centralização também torna muito mais fácil ter um estilo consistente em suas consultas e limita o número de lugares para ir para alterar as consultas, caso o esquema seja alterado.

Outras bibliotecas e ferramentas comuns a serem consideradas

• Serviços de enfileiramento ou Pub / Sub. Escolha os provedores AMQP, ZeroMQ, RabbitMQ, Amazon SQS
• Armazenamento. Amazon S3, Google Cloud Storage
• Monitoramento: Grafite/ Grafite Hospedado , AWS Cloud Watch, New Relic
• Coleta / agregação de logs. Loggly , Splunk

Auto Scaling

• Escala automática. Heroku, AWS Beanstalk, AppEngine, AWS Opsworks, Oceano digital

Mandamento # 5: Não cruze os riachos!

Existem muitos modelos bons para design de programação, pub / sub , atores , MVC etc. Escolha o que você mais gosta e cumpra-o. Diferentes tipos de lógica que lidam com diferentes tipos de dados devem ser fisicamente isolados na base de código (novamente, essa separação do conceito de preocupações e redução da carga cognitiva no futuro leitor). O código que atualiza sua IU deve ser fisicamente diferente do código que calcula o que vai para a IU, por exemplo.

Mandamento # 6: quando possível, deixe o computador fazer o trabalho

Se o compilador puder detectar erros lógicos em seu código e evitar mau comportamento, bugs ou falhas totais, devemos tirar proveito disso. Claro, algumas linguagens têm compiladores que tornam isso mais fácil do que outras. Haskell, por exemplo, tem uma notoriamente rígida compilador isso faz com que os programadores gastem a maior parte de seus esforços apenas para compilar o código. Depois de compilar, “simplesmente funciona”. Para aqueles de vocês que nunca escreveram em uma linguagem funcional fortemente tipada, isso pode parecer ridículo ou impossível, mas não levar meu palavra para isso. Sério, clique em alguns desses links, é absolutamente possível viver em um mundo sem erros de execução. E é realmente tão mágico.

Reconhecidamente, nem toda linguagem tem um compilador ou uma sintaxe que se presta a muita (ou em alguns casos!) Verificação em tempo de compilação. Para aqueles que não têm, reserve alguns minutos para pesquisar quais verificações opcionais de rigidez você pode ativar em seu projeto e avaliar se elas fazem sentido para você. Uma lista curta e não abrangente de alguns dos mais comuns que usei recentemente para linguagens com tempos de execução tolerantes inclui:

• Pitão: pilar , flocos de neve , advertências , avisos no emacs
• Rubi: advertências
• JavaScript: jslint

Conclusão

Esta não é de forma alguma uma lista exaustiva ou perfeita de mandamentos para a produção de um código 'bom' (ou seja, de fácil manutenção). Dito isso, se cada base de código que eu tive que pegar no futuro seguir até mesmo metade dos conceitos nesta lista, terei muito menos cabelos brancos e posso até ser capaz de adicionar cinco anos extras no final da minha vida. E certamente vou achar o trabalho mais agradável e menos estressante.