Como observou o lendário escritor Jules Verne: "Um mínimo bem utilizado é suficiente". Em nossa época, o conceito de um mínimo bem utilizado se aplica ao código. É triste, mas é verdade: no mundo moderno do código há muito. Para ser mais preciso, há muito código desnecessário, entre os quais o código útil é simplesmente sufocante.
Dado o exposto acima, o código desnecessário é ruim por padrão. Deteriora com o tempo. Requer suporte contínuo. Ele contém bugs que você precisa procurar. Quando novas funções aparecem, o código antigo precisa ser adaptado a elas. Quanto mais código você tiver, mais erros você poderá ter. Quanto mais tempo a verificação ou compilação demorar, mais tempo o novo funcionário entenderá seu sistema.
E, além de tudo isso, o código é escrito por programadores. Quanto mais, mais programadores são necessários. À medida que o número de programadores aumenta, também aumenta o custo de comunicação entre eles, o que contribui ainda mais para o custo de desenvolvimento e manutenção do código.
Para todos esses problemas, existe uma solução: escreva menos código. Essa abordagem tem muitas vantagens:
- Menos código a desenvolver = menos custos de desenvolvimento
- Menos código em desenvolvimento = menos custos de manutenção
- Menos código em desenvolvimento = menos bugs
- Menos código a desenvolver = teste mais eficiente
E o mais importante: quanto menos código você força as pessoas a ler, maior a probabilidade de alguém o ler.
Aqui estão algumas maneiras de reduzir o código.
O princípio de YAGNI (“você não precisa dele”)
O princípio "Você não precisa" (geralmente chamado YAGNI - Você não precisa disso) significa a seguinte regra de programação extrema: "Realize essa ou aquela oportunidade apenas quando for realmente necessário, e não quando você assumir que ela será necessária em breve. " Mesmo se você tiver cem por cento de certeza de que essa função não poderá ser executada no futuro, não comece a implementá-la agora.
Há duas razões para essa prática:
- Você economiza tempo recusando-se a escrever código que não é necessário no momento.
- A qualidade do código melhora - você não o polui com fragmentos baseados em suposições mais ou menos corretas e permanece na base de código, mesmo que essas suposições não sejam confirmadas.
O conceito de YAGNI é bastante razoável, independentemente da metodologia de gerenciamento de projetos que você aderir. Uma boa arquitetura requer um equilíbrio equilibrado de possibilidades. A arquitetura incorreta é composta de várias funções esboçadas que geram uma base de código que você é atormentado por oferecer suporte.
A regra básica aqui é: concentre-se no que é claramente necessário e não pense no que provavelmente acontecerá.
Não escreva código invulnerável
Um código invulnerável é um código ideal, um código que funcionará sob quaisquer dados de entrada e quaisquer condições. A idéia de criar algo semelhante tem seu próprio apelo, especialmente para desenvolvedores ambiciosos que percebem a falha em alguns cenários como um insulto pessoal. No entanto, escrever (ou tentar escrever) código invulnerável é uma ideia vazia, porque tudo no mundo tem seu próprio limite e o código não é exceção.
Tentando implementar o módulo ideal, você prescreverá condições adicionais, adicionando complexidade à base de código, o que contraria a própria finalidade do código. O módulo se tornará cada vez mais extenso ao longo do tempo, consumirá mais recursos e se tornará candidato a manutenção descuidada.
É por isso que, se você deseja escrever menos código, deve se esforçar pela implementação mais simples possível, da categoria "se ao menos funcionasse".
O Extreme Programming Guide menciona duas regras de ouro para escrever código simples:
- Primeiro, implemente a nova funcionalidade da maneira mais primitiva que só pode funcionar. Não construa superestruturas de tirar o fôlego, não se refine - apenas certifique-se de que tudo comece. Verifique se o código passa nos testes de unidade para novas funcionalidades (e para antigas também, como sempre).
- Então - e essa é uma parte crítica da regra - refatorar o sistema e simplificar o código o máximo possível para todas as funções que estão atualmente contidas no produto. Siga o princípio DRY e outros princípios que ajudam a tornar o sistema mais organizado.
Não se esqueça: não nos esforçamos pelo caminho mais curto, mas pelo resultado mais simples.
Assim, começamos dividindo o método existente em várias partes. Nesse caso, as opções de teste funcionarão sem falhas. Em seguida, alteramos (na direção da simplificação) um dos pequenos métodos resultantes, observando a próxima opção de teste e assim por diante.
Lembre-se de que a simplicidade está no coração da elegância. A capacidade de controlar e eliminar a complexidade desnecessária é uma programação magistral.
Não torne o código pior
Esta regra pode ser considerada o juramento de Hipócrates para desenvolvedores. Os envolvidos na programação ouvem constantemente dicas para não cortar custos e não procurar soluções alternativas que possam danificar o código e levar à sua degradação.
Os procedimentos de desenvolvimento de software, como os procedimentos médicos, geralmente envolvem grandes interferências e ações destrutivas. Além disso, as ferramentas e técnicas que usamos são frequentemente novas e não verificadas (ou insuficientemente verificadas). Além disso, não temos um análogo do Conselho de Licenciamento Médico ou do Escritório de Controle de Produtos que governaria as práticas e ferramentas de desenvolvimento que escolhermos. Assim, às vezes expomos nosso paciente, isto é, software, a procedimentos associados a riscos desnecessários, e nem sequer entendemos completamente quais são esses riscos.
Às vezes, no processo de correção de um problema, fazemos mais mal do que bem. Em seu livro "Perfect Code", que faz parte da literatura de ouro para programadores, Steve McConnell escreve que, se você não está trabalhando na raiz do problema, mas em seus sintomas, você só piora a situação - está se enganando, criando a ilusão de que o problema está resolvido. .
Mas, às vezes, observar essa regra pode ser muito difícil. Às vezes, o código desatualizado está em tal estado que é praticamente impossível implementar adequadamente uma nova funcionalidade sem prejudicá-la. Portanto, para ser mais realista, você precisa reformular um pouco a regra: de "Não torne o código pior" a "Se você degradar a qualidade do código, deverá estar ciente do que está fazendo".
Isso mesmo. Se você não encontrar uma maneira de implementar os recursos necessários e não estragar o código, avise os outros membros da equipe antes de fazer alterações. A conclusão é que, nesse caso, você diminui a qualidade do código intencionalmente.
Obviamente, isso não tornará o código ruim melhor, mas dessa forma você terá tempo para pensar sobre a situação. A experiência mostra que as pessoas geralmente não alcançam a solução ideal simplesmente porque estão prontas para aceitar a primeira idéia que vem à sua mente. Observe que não exigimos que você peça permissão ou ajude a encontrar a melhor solução.
Outra vantagem desse método é que ele reduz a probabilidade de surpresas desagradáveis em momentos ruins - toda a equipe sabe quais problemas devem ser esperados. Graças a isso, você pode trabalhar em equipe no sentido pleno da palavra e lidar com essa situação em tempo hábil.
Evite simultaneidade excessiva
A simultaneidade é uma faca de dois gumes. Só deve ser utilizado se você não puder ficar sem ele.
Quando o código é executado sequencialmente, é mais fácil entender e procurar erros. Ao usar a simultaneidade, as operações são executadas simultaneamente ou em uma ordem distorcida. Essa implementação específica cria muitos problemas na identificação e correção de erros. Obviamente, isso complica a arquitetura e a implementação de funções ao mesmo tempo em vários níveis. Aqui estão alguns problemas que a concorrência mal implementada pode causar:
- Condição de corrida: as operações começam a ocorrer imprevisivelmente
- Bloqueio mútuo: objetos envolvidos se cruzam enquanto aguardam a conclusão de operações simultâneas
- Falta de recursos: a operação de maneira estável não obtém acesso ao recurso necessário que espera
Um dos desastres mais destacados associados ao desenvolvimento de software foi causado precisamente por condições interdependentes prescritas incorretamente. Um erro de programação com o Therac-25, um aparelho de radioterapia, levou à morte de quatro pessoas.
Deve-se notar que a maioria das linguagens e estruturas de programação modernas fornece ferramentas especiais para a simultaneidade de depuração. Mas, no final das contas, tudo depende do desenvolvedor - é ele quem decide quando, onde e como aplicá-los, a fim de obter o melhor resultado.
Não colidir com acumulação
A acumulação patológica é um tipo de comportamento caracterizado pela coleta de um grande número de coisas desnecessárias e pela falta de vontade de se livrar delas; no entanto, as coisas podem ocupar a maior parte do espaço, o que pode levar a lesões e estresse.
Quando os sintomas de acumulação aparecem entre os desenvolvedores, eles começam a se apegar a qualquer parte do código, mesmo que já esteja desatualizada ou cheia de bugs. Esses desenvolvedores nunca excluem o código eles mesmos e geralmente se opõem a essa prática. Se você lhes contar isso diretamente, obtenha respostas no espírito: “Um dia ele pode ser necessário” ou “Sem isso, não posso executar a operação X” e assim por diante.
A síndrome de Plyushkin já te atacou? Talvez você tenha abandonado a idéia de arrumar as coisas porque entende que simplesmente não tem tempo suficiente para descobrir toda essa bagunça? Se assim for, então você ainda sofre de acumulação e reinos de caos completos em sua vida profissional.
Poupar é irracional. Se lhe parecer que a presença de algum trecho de código é justificada, mas você não tiver certeza absoluta, marque-o de acordo para que você possa retornar mais tarde. Portanto, isso não ficará fora da sua memória. Quanto ao código, que não cumpre uma finalidade específica e não é vital, deve ser excluído e o ponto.
Um bom programador está trabalhando para melhorar o código dia a dia e, com o tempo, a qualidade do código aumenta constantemente. O código desatualizado escrito por um bom programador sempre se destaca por sua precisão - os profissionais não deixam uma bagunça para si mesmos; Afinal, o código é nossa reputação e serão eles que nos julgarão por ele. Como Robert Martin disse corretamente: "A verdade só pode ser encontrada no código".