Tecnologia

11 regras pelas quais todos os programadores devem viver

Mulher programando

Eu sou uma pessoa que tende a viver de acordo com regras.

Concedido, são principalmente regras que estabeleci para mim – mas ainda são regras.

Acho que criar regras para mim mesmo me ajuda a funcionar melhor, porque pré-decido as coisas com antecedência, em vez de tomar todos os tipos de decisões na hora.

Devo ir para a academia esta manhã?

Bem, minha regra diz que às quartas-feiras eu vou para a academia e hoje é quarta-feira, então eu vou para a academia – está resolvido.

Esta semana, enquanto eu estava pensando sobre alguns dos tipos de regras que me impõe, achei que seria uma boa ideia criar um conjunto de regras que todos os desenvolvedores de software deveriam seguir.

Agora, vou admitir, a maioria dessas regras são mais orientações, mas de qualquer maneira, aqui estão elas:

1: Tecnologia é como você chega à solução, não é A solução

Podemos realmente nos deixar levar pela estrutura JavaScript mais recente, linguagem de programação ou mesmo sistema operacional, mas todas essas coisas não são realmente soluções para os problemas que estamos tentando resolver como programadores, em vez disso, são simplesmente ferramentas que nos ajudam a resolver os problemas.

Temos que ter muito cuidado para não ficarmos muito loucos por uma tecnologia em particular de que gostamos ou que por acaso seja tão popular agora, para que não corramos o risco de pensar em cada problema como um prego, só porque acontece de estar segurando um martelo brilhante que acabamos de aprender.

2: Inteligente é o inimigo do claro

Ao escrever o código, devemos nos esforçar para escrever um código que seja claro e fácil de entender.

Um código que comunica claramente seu propósito é muito mais valioso do que um código obscuro – não importa o quão inteligente ele seja.

Nem sempre é verdade, mas em geral, inteligente é inimigo do claro.

Geralmente é verdade que, quando escrevemos um código “inteligente”, esse código não é particularmente claro.

É importante lembrar essa regra sempre que pensarmos que estamos fazendo algo especialmente inteligente.

Às vezes, escrevemos um código inteligente que também é claro, mas geralmente não é o caso.

Se você estiver interessado em escrever um código limpo, recomendo fortemente que você verifique The Clean Coder: Um Código de Conduta para Programadores Profissionais (Robert C. Martin)

código

3: Escreva código apenas se for absolutamente necessário

Este pode parecer um pouco contraditório, afinal, não é nosso trabalho como programadores escrever código?

Bem, sim e não.

Nossos trabalhos podem envolver escrever código, mas ainda devemos nos esforçar para escrever o menos possível para resolver o problema que estamos tentando resolver.

Isso não significa que devemos tornar nosso código o mais compacto possível e nomear todas as nossas variáveis ​​usando uma única letra do alfabeto. O que isso significa é que devemos tentar escrever apenas o código realmente necessário para implementar a funcionalidade exigida.

Freqüentemente, é tentador adicionar todos os tipos de recursos interessantes ao nosso código ou torná-lo “robusto” e “flexível” para que possa lidar com todos os diferentes tipos de situações. Mas, na maioria das vezes, quando tentamos adivinhar quais recursos seriam úteis ou tentamos pavimentar o caminho para resolver problemas que pensamos que possam existir no futuro, estamos errados.

Esse código extra pode não agregar valor, mas ainda assim pode causar muitos danos. Quanto mais código houver, mais chances de bugs e mais código será necessário manter ao longo do tempo.

Bons engenheiros de software não escrevem código a menos que seja absolutamente necessário.

Grandes engenheiros de software excluem o máximo de código possível.

4: Os comentários são principalmente maldosos

Não sou um grande fã de escrever comentários em código. Estou com Bob Martin, quando ele diz:

“Cada vez que você escreve um comentário, você deve fazer uma careta e sentir o fracasso de sua capacidade de expressão.”

Clean Code: A Handbook of Agile Software Craftmanship

Isso não significa que você nunca deve escrever comentários, mas na maioria das vezes eles podem ser evitados e, em vez disso, você pode se concentrar em fazer um trabalho melhor ao nomear as coisas.

Os comentários devem ser realmente escritos quando não for possível comunicar claramente a intenção de uma variável ou método usando um nome. O comentário serve a um propósito real que não poderia ser facilmente expresso no código.

Por exemplo, um comentário poderia informar que essa ordem estranha em que alguma operação estava ocorrendo no código não foi um erro, mas foi intencional por causa de um bug no sistema operacional subjacente.

Em geral, porém, os comentários não são apenas maus porque em muitos casos são necessários, mas também porque mentem.

Os comentários não tendem a ser atualizados com o resto do código e isso resulta nos comentários realmente se tornando perigosos, porque eles podem muito bem guiá-lo em uma direção completamente errada.

Você verifica cada comentário em relação ao código para ter certeza de que o código está realmente fazendo o que o comentário diz? Em caso afirmativo, qual é o sentido de ter o comentário? Se não, como você pode confiar que o comentário está dizendo a verdade?

É uma cilada Bino, então é melhor evitá-la o máximo possível.

Ok, haters, deixem sua torrente de “comentários” na seção de comentários abaixo, mas não vou mudar minha posição sobre isto.

5: Sempre saiba o que seu código deve fazer antes de começar a escrevê-lo

Parece óbvio, mas não é.

Quantas vezes você sentou para escrever código sem entender totalmente o que o código que você estava escrevendo deveria realmente fazer?

Já fiz isso mais vezes do que gostaria de admitir, então essa é uma regra que preciso ler com frequência.

Praticar o desenvolvimento dirigido por teste (TDD) pode ajudar aqui, porque você literalmente tem que saber o que o código vai fazer antes de escrevê-lo, mas ainda não o impede de criar a coisa errada, então ainda é importante ter certeza você absolutamente, 100% entende os requisitos do recurso ou funcionalidade que está construindo antes de construí-lo.

6: Teste seu sh — código antes de enviá-lo

Não jogue seu código por cima da parede e tenha controle de qualidade nele apenas para enviá-lo de volta para você, de modo que você possa desperdiçar o tempo de todos com relatórios e resoluções de bugs desnecessários.

Em vez disso, gaste alguns minutos para executar você mesmo os cenários de teste, antes de chamar seu código de concluído.

Claro, você não detectará todos os bugs antes de passar seu trabalho para o controle de qualidade, mas pelo menos detectará alguns dos erros estúpidos e embaraçosos que cometemos de vez em quando.

Muitos desenvolvedores de software pensam que é função do controle de qualidade testar seu material. Simplesmente não é verdade. A qualidade é responsabilidade de todos.

Pilha de livros abertos

7: Aprenda algo novo todos os dias

Se você não aprendeu algo novo hoje, você apenas retrocedeu, porque posso garantir que esqueceu algo.

Não leva muito tempo para aprender algo novo todos os dias.

Tente gastar apenas 15 minutos ou mais lendo um livro – eu li muitos livros no ano passado, apenas lendo cerca de 45 minutos por dia, em média.

Os pequenos avanços que você faz a cada dia se somam ao longo do tempo e irão moldar muito o seu futuro. Mas, você precisa começar a investir agora se quiser colher os frutos mais tarde.

Além disso, hoje a tecnologia está mudando tão rapidamente que, se você não estiver continuamente aprimorando suas habilidades e aprendendo novas, será deixado para trás muito rapidamente.

8: Escrever código é divertido

Está certo. Você provavelmente não entrou nessa profissão só porque paga bem.

Quer dizer, não há nada de errado em escolher um emprego que pague bem, mas médico ou advogado provavelmente seria uma escolha melhor.

Provavelmente você se tornou um desenvolvedor de software porque adora escrever códigos . Portanto, não se esqueça de que você está fazendo o que ama.

Escrever código é muito divertido. Eu gostaria de poder escrever mais código.

Normalmente estou muito ocupado mantendo esse negócio funcionando para gastar muito tempo escrevendo código atualmente, que é uma das razões pelas quais me lembro tão claramente de como isso é divertido.

Talvez você tenha esquecido que escrever código é divertido. Talvez seja hora de lembrar o quanto é divertido novamente, começando um projeto paralelo ou apenas mudando sua mentalidade e percebendo que você começa a escrever código e ainda é pago por isso. (Esperançosamente)

9: Você não pode saber tudo

Por mais que você aprenda, ainda haverá muito que você não sabe.

É importante perceber isso porque você pode enlouquecer tentando saber tudo.

Tudo bem não ter todas as respostas.

É normal pedir ajuda ou falar quando você não entende algo.

Em muitos casos, você pode aprender o que precisa saber bem perto de quando precisa saber – acredite em mim, eu faço isso o tempo todo.

O que quero dizer é que não se prenda a tentar aprender tudo, quando essa é uma tarefa impossível. Em vez disso, concentre-se em aprender o que você precisa saber e desenvolver as habilidades que permitem que você aprenda as coisas rapidamente .

10: As melhores práticas dependem do contexto

O desenvolvimento orientado a testes é a melhor maneira de escrever código?

Devemos sempre programar em pares?

Você é um canalha se não usa recipientes IoC?

A resposta a todas essas perguntas é “depende”.

Depende do contexto.

As pessoas tentarão enfiar as melhores práticas em sua garganta e tentarão dizer que elas sempre se aplicam – que você deve sempre fazer isso ou aquilo – mas simplesmente não é verdade.

Eu sigo muitas das melhores práticas quando estou escrevendo código, mas também não as sigo condicionalmente.

Os princípios são atemporais, as melhores práticas serão sempre situacionais .

11: Sempre se esforce para simplificar

Todos os problemas podem ser eliminados.

As soluções mais elegantes costumam ser as mais simples.

Mas, a simplicidade não é fácil. Dá trabalho tornar as coisas simples.

O objetivo deste blog é pegar algumas das complexidades do desenvolvimento de software e da vida em geral e torná-las simples.

Acredite, não é uma tarefa fácil.

Qualquer tolo pode criar uma solução complexa para um problema. É preciso esforço e cuidado extras para refinar uma solução para torná-la simples, mas ainda correta.

Aproveite o tempo. Faça o esforço. Esforce-se pela simplicidade.

Que regras você segue?

Então, essas são minhas regras, mas e as suas?

Que regras você segue pessoalmente?

O que você acha que é importante lembrar todos os dias?

Deixe um comentário abaixo e, também, reserve um segundo para se juntar a outros desenvolvedores de software que fazem parte da comunidade Fábrica de Programadores.

Basta clicar aqui e você pode se inscrever gratuitamente você receberá alguns dos meus melhores conteúdos e outras informações todas as semanas.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *