🚣🏽 💅🏼 👨🏻‍⚖️ Oito hábitos importantes do programador ➿ 👩🏽‍🚒 🚶

“Uma pessoa pode se tornar uma pessoa apenas através da educação. Ele é o que a educação faz dele.
I. Kant

Na minha opinião, esta citação é muito adequada para programadores. De fato, um programador não é apenas um especialista que é bem versado em questões técnicas. Um programador é, antes de tudo, um artesão que cria código todos os dias usando seu conhecimento. Criar código bom é impossível sem o uso disciplinado de certas habilidades. E esse uso regular é o que são os hábitos.

Aconteceu que maus hábitos nos impedem de viver e trabalhar, e bons aumentam a produtividade e, em geral, uma pessoa desfruta mais da vida. Se você se esforçar e começar a adquirir e estimular bons hábitos, muito em breve começará a perceber como se torna um especialista de nível superior. Mas isso não é tudo, seus colegas também notarão rapidamente mudanças para melhor e isso os forçará a aprender e adotar técnicas úteis. Quando você trabalha com código em uma equipe, pode ler a atitude da pessoa em trabalhar em cada confirmação.

Então, vamos examinar os oito hábitos úteis de um programador que o tornarão o melhor profissional.

1. Não repita (SECO - não se repita)

Você provavelmente se deparou com o fato de que, olhando para a próxima seção do código, você pensa: “Hmm, aqui eu já fiz algo semelhante, mas com argumentos diferentes, e em geral havia uma matriz de dados diferente.

Deve ser uma chamada para você que esse código será repetido no futuro, novamente com pequenas alterações nas condições e dados. Mas se você não prestar atenção a esse sinal ou estiver com pressa, provavelmente escreverá o algoritmo novamente do zero quando uma solução semelhante for necessária no futuro. Gradualmente, esses algoritmos se acumularão, o código crescerá e, no final, você perderá completamente a motivação para fazer edições e melhorias nesses macarrões.

Portanto, desenvolva um bom hábito de seguir o princípio DRY (Não Repita). Sempre que você começar a escrever um algoritmo semelhante, reserve um tempo para refletir sobre várias opções possíveis com entidades diferentes. Organize uma pequena função genérica ou mesmo uma classe se o algoritmo for complexo. Isso levará um pouco mais de tempo do que escrever uma solução rápida para uma tarefa específica, mas economizará uma quantidade incrível de horas no futuro para depuração e teste.

Gradualmente, toda uma biblioteca de espaços em branco se acumulará em você e você poderá usá-los facilmente em qualquer projeto.

A programação como um todo consiste em pequenos esforços que são executados no processo. Sinta-se um pouco mais do que o necessário atualmente. Então você começará a crescer.

Existe toda uma lista de princípios semelhantes que são muito úteis para aderir. Mas, na minha opinião, o DRY é fundamental para tudo no trabalho de um programador.

2. Depois de decidir que tudo está feito, refatorar

A maioria dos programadores, especialmente iniciantes, acredita que seu trabalho é feito assim que o código começa a executar a tarefa como pretendido. Somente agora a palavra "feito" inclui um conceito mais amplo do que a escrita trivial do código.

O código funciona corretamente? Sim! Então, qual é o problema?

Sim está certo. Pouco antes de passar para a próxima tarefa, revise o que você escreveu. Do começo ao fim. Provavelmente, você notará que algumas variáveis são declaradas em um local inconveniente e não está claro por que elas são necessárias. Também pode haver uma linha muito longa que não se encaixa na tela, o que significa que aqui você precisa pensar em como torná-la mais bonita. Ou a função acabou sendo muito volumosa e pode ser dividida em duas partes.
Pense nas pessoas que lerão seu código no futuro. Se eles gostam desse código ou não cerveja, não conseguem descobrir.

Tome uma decisão bonita, não apenas uma que funcione. Assim como os bons escritores depois de escrever um rascunho: eles leem seu trabalho várias vezes e jogam fora partes desnecessárias para fazer com que o leitor goste e compreenda o ponto sem ter que entrar em muitos detalhes.

Eu recomendo a leitura de Robert Martin sobre este tópico . Um livro esclarecedor que deve estar na biblioteca de todos os programadores.

3. Concentre-se nas tarefas de negócios

Muitos programadores tendem a se concentrar em estudar o lado técnico do seu trabalho e acreditam que os negócios não têm nada a ver com eles. O principal é fornecer boas especificações técnicas e, então, farei tudo da melhor maneira possível. Somente para se tornar verdadeiramente um mestre de sua arte, você deve entender por que o que está fazendo tomou conta do negócio.

Se é muito rude imaginar um programador que trabalhe puramente em TK sem entender a essência, um exemplo pode ser dado. O motorista do ônibus, ao lado do qual os passageiros se sentam, diz a ele: "Vire à esquerda, vire à direita, agora à direita". E assim os passageiros “dirigem” o ônibus. Mas se o motorista tomar a iniciativa e perguntar: “Para onde preciso ir?”, O passageiro pode simplesmente dizer: “Estamos indo para a cidade N”, e tudo se torna muito mais fácil. O motorista conhece o destino final e pode, usando sua experiência, construir uma rota de forma independente e dizer a si mesmo onde e como virar.

Curiosamente, mas muitos programadores não se preocupam em entender o objetivo do projeto. E, por um lado, você pode entender esse ponto de vista, porque a programação é um trabalho mental muito difícil. Às vezes, o conhecimento do seu instrumento ocupa uma parte tão grande da mente que simplesmente não há recursos suficientes para todo o resto. Acontece que programadores, como motoristas em um tanque sem uma janela de visualização, só podem girar os botões quando o comandante da tripulação os martelar.

Além disso, entender o problema de negócios não permitirá que você mergulhe no desenvolvimento de algo completamente desnecessário em um determinado momento. Por exemplo, se a tarefa é criar uma função que ajude a compilar estatísticas ao passar nos testes, sabendo que essa não é uma tarefa crítica para o desempenho, você não precisa mais gastar tempo com otimizações desnecessárias e acelerar o algoritmo. Mesmo assim, isso não afetará o resultado final. Os testes serão executados apenas pelos desenvolvedores e apenas uma vez por semana.

Outro exemplo, se o programa tiver uma função que todos os usuários executam várias vezes ao dia, faz sentido dedicar mais esforço à elaboração da versão ideal dessa função e de sua acessibilidade ideal na interface. Aqui você já não pode poupar tempo.

Mas, do ponto de vista de um programador que não esteja familiarizado com tarefas de negócios, essas duas tarefas parecerão equivalentes.

Para uma melhor compreensão, recomendo que você leia o livro "Comece com o porquê", de Simon Sinek .

4. Pequenas confirmações

O fato de um programador precisar usar um sistema de rastreamento de versão é óbvio, eu acho. Eu quero falar sobre outro hábito muito útil - isso é fazer commits o mais rápido possível e em pequenas porções possíveis. Ao mesmo tempo, adicione comentários significativos e úteis a cada confirmação.

Freqüentemente, programadores iniciantes e ainda mais experientes, no final do dia, fazem um empurrão com todos os arquivos alterados e algum tipo de comentário inútil, como “corrigir problema29”. Ou "corrigiu um erro na solicitação". Ninguém dessa descrição entenderá o que foi feito especificamente. E quando chega a hora de mesclar um commit tão grande em um ramo comum, o proprietário do repositório, em primeiro lugar, obscurece mentalmente o desenvolvedor preguiçoso. Em segundo lugar, se ocorrer um conflito durante a fusão, é provável que o proprietário simplesmente reverta esse commit e não o aceite. Quem quer receber uma porção de bugs do fato de entender mal qual condição acabou por ser supérflua ao resolver conflitos manualmente.

Por outro lado, se você enviar regularmente suas alterações uma vez por hora e fornecer a cada confirmação uma descrição mais detalhada, para que no futuro seja fácil, sem olhar o código, entender o que você mudou e quais considerações teve sobre elas. mudanças, você alcançará um novo nível de entendimento da filosofia geral de escrever código. Agora você não apenas “reparará o primus”, agora se tornará parte da equipe criativa e se comunicará com seus colegas através de seus commits, como em um bate-papo. Este será um diálogo significativo.

Como literatura, recomendo a leitura de pelo menos o primeiro capítulo do livro "Git for a Professional Programmer" de Scott Chacon e Straub Ben. Quando você descobre quais funções maravilhosas existem no Git e do que ele é capaz, resta apenas se comprometer com mais frequência, e o restante pode ser resolvido com as ferramentas necessárias.

5. Conte o tempo

Qualquer trabalho tem um começo e um fim. A eficácia de um programador é medida no número de horas necessárias para ele resolver determinados problemas. Quanto mais rápidas as tarefas forem resolvidas, melhor. Isso é bastante óbvio e não requer nenhuma explicação.

Mas há outro lado dessa evidência, que muitas vezes ilude os programadores - você precisa calcular com precisão o tempo gasto na solução. Não é o que você sente quando se senta no trabalho das nove às cinco, intercalado com selos e reuniões. E o presente é o seu trabalho.
No começo, desenvolvi o hábito de contar o tempo simplesmente escrevendo relatórios sobre o que fiz durante o dia e calculando um horário aproximado. Mesmo assim, calculei aproximadamente que só tenho 4 horas de 8 para trabalhar com eficiência.

E então ele instalou programas especiais que contavam o tempo automaticamente. No começo eu usei www.rescuetime.com . Graças a esse programa, vi que as redes sociais, embora parecessem um pequeno desperdício para mim, realmente estragaram minha imagem de desempenho. No final, decidi desativar o acesso a alguns sites completamente durante o horário de trabalho. Para isso, também existem plugins especiais no navegador.

A próxima etapa no rastreamento de tempo foi necessária quando decidi fixar o horário exato do trabalho com o código do programa. Para isso, tentei primeiro o hubstaff.com . Como se viu, uma solução bastante cara se você a usar quando estiver trabalhando em equipe.

Então tentei wakatime.com. E acabou por ser aquela bala de prata. Este serviço tem a capacidade de integrar todos os IDEs populares, bem como a integração com o github. Como resultado, você pode determinar com precisão até um minuto quantos minutos úteis você gastou em programação. Além disso, há uma ligação para confirmações. É maravilhoso quando você pode ver não apenas os commits, mas também descobrir o tempo gasto nesse commit.
Uma incrível coleção de receitas para a organização correta do tempo e do trabalho em projetos está no livro "Jedi Techniques", de Maxim Dorofeev .

6. Estabilidade é um sinal de domínio.

Como você provavelmente já entendeu, você pode desenvolver infinitamente suas habilidades e habilidades. O que você fez um ano atrás pode parecer ridículo e despretensioso em termos de sua nova experiência. É claro que você terá maneiras aprimoradas de escrever expressões complexas.
Mas entre tudo isso, você deve desenvolver o hábito de seguir certas regras. Mesmo que eles não pareçam completamente elaborados, use esses métodos de trabalho em qualquer lugar.

Usando o exemplo de código: se você decidir usar um esquema específico para nomear variáveis ou usar espaços em vez de tabulações, siga este princípio constantemente. Você não precisa experimentar um novo estilo toda semana e aplicar novas práticas avançadas. Então você perde o foco.

O problema da inconstância é que o tempo destrói qualquer produto de software. Quanto mais algumas pessoas trabalham no programa, mais mudanças são feitas no processo, o que acaba criando o caos. Se cada um dos membros da equipe não aderir a um contrato específico.

Então, o que precisa ser feito para respeitar o princípio da constância?

A primeira coisa que você precisa adotar é aderir a um estilo definitivamente no código. Nos editores do JetBrains , gosto muito da ferramenta que indica a qualidade do seu código. Eu costumava ter medo de tantos avisos, mas quando você começa a seguir o conselho de um linter de maneira disciplinada, então o código se torna claro e esteticamente agradável.

Também estude a literatura sobre como nomear classes, métodos e variáveis. Eu recomendo o livro "Perfect Code", de Steve McConnell.

Certa vez, li este livro por meia hora à noite, quando todo mundo já estava saindo de casa. O livro estava na biblioteca do escritório. Apenas alguns meses depois, eu vi todo o horror que havia codificado antes daquela época. Eu tive que introduzir gradualmente novas técnicas e conduzir a refatoração.

7. Faça uma vez

"Eu vou consertar um pouco mais tarde." Cada um de nós pronunciou isso para nós mesmos quando encontramos um bug em nosso código ou uma condição insuficientemente correta para processar em um loop. E cada um de nós sabe que essa "correção mais tarde" e permanece no código na forma de comentáriosfaçam. E quando você vê comentários de código no estilofaçam, significa apenas que alguém não segue o princípio de "faça aqui e agora". No momento em que esse comentário foi escrito, o programador provavelmente entende muito bem qual é o problema e como corrigi-lo. Porque está no contexto da tarefa atual. Mas se você voltar a esta seção do código posteriormente, será mais difícil entender por que essa reserva foi necessária.
Portanto, crie um hábito muito importante para você - elaborar a solução do zero até que a tarefa seja concluída na íntegra. O mais completo - porque é realmente irrealista cobrir todas as opções com cem por cento. Mas pelo menos não deixe espaço para estesfaçam-comentários. Afinal, se você sugeriu e teve tempo para comentar, significa que, para a próxima etapa - implementação -, resta muito pouco.

Uma boa maneira de entender que você realmente concluiu esse trecho de código é criar um teste para verificar várias condições de entrada.

8. Nunca pare de aprender

Parece, isso é uma habilidade óbvia necessária para qualquer especialista, não apenas um programador. Mas, infelizmente, muitos esquecem dele. Às vezes, pergunto aos meus amigos que estão envolvidos na programação, quais livros eles leram recentemente. Muitas vezes, muitos começam a lembrar com dificuldade o que lêem há um ou dois anos. Ao mesmo tempo, eles dominavam alguns truques na universidade ou em alguns cursos e o usavam o tempo todo.

No entanto, se em uma esfera em rápido desenvolvimento, você parar pelo menos uma vez por mês para se familiarizar com uma nova ferramenta, tecnologia ou um conceito interessante, depois de um tempo poderá descobrir que literalmente não entende o que está acontecendo no presente.

Isso aconteceu comigo uma vez. Eu desenvolvi um produto de sucesso e o vendi por um tempo. Obviamente, ouvi histórias sobre novas estruturas, mas não prestei muita atenção a elas. Ele estava profundamente imerso no desenvolvimento e suporte de sua solução.

Somente quando o fluxo de clientes diminuiu é que percebi que meu produto precisava ser modernizado. E então me deparei com uma enorme barreira. Eu costumava usar apenas PHP e muito raramente funções AJAX. E para entender as estruturas modernas React, Angular e Vue JS, eu precisava gastar urgentemente cerca de um ano para estudá-las através de livros. O mais interessante é que, se eu tivesse dedicado tempo suficiente ao treinamento antes, meu produto não perderia competitividade. Apenas que, em vez de apoiar funções antigas, era necessário aprender novas e introduzir tecnologias gradualmente, e não em um modo de emergência.

Conclusão

Mesmo se você estiver cem por cento confiante em suas habilidades, lembre-se de que não há limite para a perfeição. Não pare de fazer perguntas provocativas. Admita a si mesmo que em algumas áreas você tem treinamento insuficiente ou não conhece os pontos sutis nas estruturas familiares, mas gostaria de conhecê-los. Passar algumas horas e executar a versão de teste diretamente do github no servidor local agora é muito fácil.

Em pequenas experiências, você treinará suas habilidades e desenvolverá todos os hábitos importantes.

Oito hábitos importantes do programador