Rich Skrenta escreve que o código é nosso inimigo.
O código é ruim. Ele apodrece. Requer manutenção periódica. Tem bugs que precisam ser encontrados. Novos recursos significam que o código antigo precisa ser adaptado. Quanto mais código o senhor tiver, mais lugares haverá para os bugs se esconderem. Quanto mais demoradas forem as verificações ou compilações. Quanto mais tempo um novo funcionário leva para entender o sistema. Se o senhor tiver que refatorar, haverá mais coisas para mover.
O código é produzido por engenheiros. Para produzir mais código, são necessários mais engenheiros. Os engenheiros têm n^2 custos de comunicação, e todo o código que eles adicionam ao sistema, ao mesmo tempo em que expande sua capacidade, também aumenta toda uma cesta de custos. O senhor deve fazer todo o possível para aumentar a produtividade dos programadores individuais em termos do poder expressivo do código que escrevem. Menos código para fazer a mesma coisa (e possivelmente melhor). Menos programadores para contratar. Menos custos de comunicação organizacional.
Rich dá a entender isso aqui, mas o verdadeiro problema não é o código. O código, como um bebê recém-nascido, é irrepreensível e inocente no momento em que é escrito no mundo. O código não é nosso inimigo. O senhor quer ver o verdadeiro inimigo? Vá se olhar no espelho. Aí está o problema do senhor, bem ali.
Como desenvolvedor de software, o senhor é seu pior inimigo. Quanto mais cedo perceber isso, melhor será para o senhor.
Sei que o senhor tem a melhor das intenções. Todos nós temos. Somos desenvolvedores de software; adoramos escrever código. É o que fazemos. Nunca encontramos um problema que não pudéssemos resolver com um pouco de fita adesiva, um cabide improvisado e uma pitada de código. Mas Wil Shipley argumenta que devemos controlar nossas tendências naturais de escrever muito código:
A natureza fundamental da codificação é que nossa tarefa, como programadores, é reconhecer que toda decisão que tomamos é uma troca. Ser um programador mestre é entender a natureza dessas compensações e estar consciente delas em tudo o que escrevemos.
Na codificação, há muitas dimensões nas quais o senhor pode classificar o código:
- Brevidade do código
- Funcionalidade
- Velocidade de execução
- Tempo gasto na codificação
- Robustez
- Flexibilidade
Agora, lembre-se de que essas dimensões estão todas em oposição umas às outras. O senhor pode passar três dias escrevendo uma rotina que seja realmente bonita e rápido, então o senhor conseguiu aumentar duas de suas dimensões, mas gastou três diasportanto, a dimensão “tempo gasto na codificação” é maneira abaixo.
Então, quando isso vale a pena? Como tomamos essas decisões? A resposta acaba sendo muito sensata, muito simples e também a que ninguém, jamais, ouve: Comece com a brevidade. Aumente as outras dimensões conforme exigido pelos testes.
Não poderia estar mais de acordo. Já dei conselhos semelhantes quando exortei os desenvolvedores a codificar menos. E não estou falando de um reductio ad absurdum concurso em que usamos todos os truques inteligentes de nossos livros para fazer com que o código caiba em menos espaço físico. Estou falando de estratégias práticas e sensatas para reduzir o volume de código que um programador individual precisa ler para entender como um programa funciona. Aqui está um pequeno exemplo trivial do que estou falando:
if (s == String.Empty) if (s == "")
Parece óbvio para mim que o último caso é melhor porque é simplesmente menor. E, no entanto, é praticamente certo que encontrarei desenvolvedores que lutarão contra mim, quase literalmente até a morte, porque estão absolutamente convencidos de que a verbosidade do String.Empty é, de alguma forma, mais amigável para o compilador. Como se eu me importasse com isso. Como se o alguém se importou com isso!
É doloroso para a maioria dos desenvolvedores de software reconhecer isso, porque eles gostam muito de código, mas o melhor código não é código algum. Cada nova linha de código que o senhor voluntariamente traz ao mundo é um código que precisa ser depurado, um código que precisa ser lido e compreendido, um código que precisa ser suportado. Toda vez que o senhor escreve um novo código, deve fazê-lo com relutância, sob coação, porque esgotou completamente todas as outras opções. O código só é nosso inimigo porque há muitos de nós, programadores, escrevendo uma quantidade enorme dele. Se o senhor não consegue não conseguir se safar sem código, a próxima melhor opção é começar com brevidade.
Se o senhor adora escrever código – realmente, realmente adora escrever código – o senhor gostará o suficiente para escrever o mínimo possível.