Tudo velho um dia se torna novo novamente. Chega um momento em que até programadores experientes entram no mesmo rake. Não é possível listar todas as “regras não escritas” de qualquer disciplina, em parte porque muitas delas nem são regras . Geralmente, é uma maneira de reformular verdades abstratas e eternas.

Marie Kondo fez uma carreira aplicando os princípios universais de eficiência, limpeza e beleza à tarefa doméstica de limpeza. Acontece que muitas pessoas só precisam de um tradutor entre a sabedoria eterna e sua vida cotidiana para realmente “entender” o significado do que está acontecendo ao redor (veja também “Zen e a arte da manutenção de motocicletas” ). Esperamos sinceramente que você aproveite nossa tentativa de fazer o mesmo na programação.

1. Nenhum depósito de sexta-feira

Mesmo se você tiver um sistema de implantação contínua. Sexta-feira é o dia mais inapropriado para iniciar o mestre, pelo motivo óbvio: resta apenas meio dia para corrigir possíveis batentes. Geralmente, após as atualizações, surtos de tíquetes de suporte técnico são observados, principalmente após o lançamento de novas funções e, inevitavelmente, de novos erros. As pessoas às sextas-feiras estão com sono, desatentas, tendem a adiar tudo até mais tarde ... você sabe como isso acontece.

Ninguém está imune a forças sobrenaturais que sempre escolhem sexta-feira por insetos! Portanto, observe as melhores práticas e, se você não tiver certeza, preste atenção aos líderes do setor. Por exemplo, a Apple supostamente faz lançamentos às terças-feiras , deixando tempo suficiente em ambos os lados de um evento crítico como o Deploy: segunda-feira para testar e detectar os bugs mais recentes, e de quarta a sexta-feira para fazer alterações urgentes. E com os ganhos da Apple, você percebe que o modelo de implantação deles é lavado com sangue e suor.

2. Backups regulares

É difícil superestimar a importância de backups regulares. Todo o nosso setor é construído em um sistema abstrato de backup progressivo. Claro que estou falando do Git, mas isso não é suficiente. Seu banco de dados, chaves criptográficas, arquivos de configuração, imagens de VM, imagens / vídeos ... até os pacotes importados devem ser armazenados com segurança onde sempre estarão disponíveis em caso de emergência. Se você não possui um sistema automatizado, deixe pelo menos alguns funcionários arquivar regularmente a pasta de trabalho e copiá-la para uma unidade externa. Sim, apenas um par - a redundância não é supérflua.

Provavelmente você nunca precisará de 9 em cada 10 backups. Mas um dia, como eu sou hoje, você vai querer voltar ao passado e descobrir exatamente quando cometemos esse erro imperceptível, mas completamente mortal, que ninguém jamais notou ?! Então você ficará feliz por ter demorado um pouco para fazer o backup. Ou, quando um novo funcionário exclui acidentalmente 100.000 linhas de código. Isso acontece Não guardamos rancor contra as pessoas, mas aprendemos com os erros. Faça backups, mesmo que seja difícil!

3. Obtenha a especificação completa antes de iniciar o desenvolvimento

Eu freqüentemente sofro da síndrome "comecei muito cedo". Mais de uma vez, tive que reescrever grandes fragmentos de código, porque não fiz perguntas suficientes nas primeiras reuniões com o cliente, onde ele descreveu os contornos da tarefa. Nosso cérebro é realmente minúsculo e odeia precisão, especialmente quando a precisão é complexa e cara (leia-se: necessário para o cliente). Ele encontra semelhanças em que nem chega perto. Isso é especialmente verdadeiro no design do programa - em um aplicativo bastante complexo, dez botões semelhantes executam uma dúzia de tarefas completamente diferentes. Antes de começar a codificar, você deve capturar essas sutilezas se quiser aproveitar ao máximo o tempo e o tempo dos clientes. Não seja como eu ou meu cérebro. Desenhe tudo no papel, verifique se tudo está claro e, se necessário, você pode redesenhar o sistema do zero (levando em consideração o tempo de preparação suficiente - somos todos humanos).

Ninguém jamais alcançará a perfeição neste processo. Eu ainda confio demais em suposições. Mas desde que percebi o problema, suposições infundadas se tornaram menos. Deve ser pensado como um computador: inequivocamente e sem pensar em sua lógica. No conceito de design de sistema, estude situações de fronteira, seja um "advogado do testador" - e você provavelmente encontrará um design que elimina imediatamente classes inteiras de erros permitidos em um design menos cuidadoso.

4. Se você perceber bobagens sem importância, diga

Tente parar suavemente ou impedir discussões improdutivas antes que elas saiam do controle. Nosso tempo no escritório é quase tão valioso quanto as 3-8 horas que passamos inconscientes todas as noites - ou seja, é muito importante! Do ponto de vista comercial, quanto mais pessoas houver, mais eficaz será a reunião, porque o pagamento por hora é multiplicado por 20 a 500 desenvolvedores em uma sala / sala de conferência / etc. Isso é dinheiro louco, especialmente na ensolarada Califórnia com seus salários. Tempo é dinheiro! E estamos trabalhando nesse dinheiro inventando truques intelectuais em torno de monstros com tentáculos que estão escondidos atrás de cada base de código e apenas esperamos para quebrar as expectativas inocentes com bugs e falhas cruéis.

Mas nem sempre vagamos por catacumbas de código esquecidas com uma tocha trêmula e uma testa suada. Às vezes, sentamos em reuniões ou discutimos algo tenso fora das reuniões formais. O Slack é famoso por aumentar a coesão da equipe, mas a que custo (além de uma taxa mensal)? Na minha experiência, o Slack aumenta drasticamente o "tempo sem sentido" do seu cérebro - o tempo necessário para filtrar outro fluxo constante de alertas sonoros (geralmente inapropriados) quando você tenta fazer o que a empresa lhe paga; isto é, desenvolva e repare código útil. E as pessoas caem facilmente em disputas desnecessárias.

Não há problema em pedir para encerrar a discussão, se levar muito tempo. Atualmente, as crianças gostam de dizer que “o presente vê o presente”: pessoas que realmente trabalham de verdade, ajudam clientes, usuários e o mundo - elas ficarão gratas por pedir que você encerre a discussão sobre se a nova geladeira deve ser preta ou cromado. "Sim, você joga uma moeda, qual a diferença ... temos problemas mais sérios." E muitas das pessoas que prestam atenção em você serão da liderança.

Obrigado por se juntar a mim nesta jornada. Que você veja a mesma sabedoria daqueles que escreveram essas dicas antes de nós. E, por favor, se em sua experiência você aprendeu outras regras não ditas, escreva-as e informe-nos!