Número 15
8 de xuño de 2022
|
Como xa vos dixen, hai tres consellos que sempre se dan aos programadores: KISS (“Keep It Simple, Stupid”), YAGNI (“You Ain’t Gonna Need It”) e DRY (“Don’t Repeat Yourself”). Hai xente que pensa que non só son consellos, senón que son principios. Eu non chego a tanto e, como xa vos dixen hai unhas semanas, non estou de acordo con DRY e penso que moitas veces se opón completamente aos outros dous.
Hoxe quero cantarvos as louvanzas de YAGNI. En galego, esa sigla significa “non vas precisar diso”. O que vén a dicir é que, moitas veces, poñémonos a engadir código en previsión das necesidades que pensamos que imos ter no futuro; porén, non deberíamos facelo porque, na maioría dos casos, ese código adicional non o imos utilizar nunca.
Canto máis se acumula, máis fede.
Pensade, por exemplo, nesas veces que engadistes unha abstracción para poder substituír a base de datos se fora necesario (e nunca o foi), ou en cando escribistes ese framework extensible do que só usades tres funcións. Se nos deixamos levar, podemos malgastar moitísimo tempo facendo cousas agora que non imos usar no futuro, e a sigla YAGNI fainos o acordo de que non cometamos ese erro.
Non é esa a única maneira na que podemos perder o noso tempo se escribimos código “en previsión de”. Ás veces, de milagre, chega o día: por fin imos usar ese código que escribimos hai tres meses. Poñémonos a integralo e, despois dunhas horas ou días, resulta que non nos serve! Unha vez incorporeime a un proxecto no que un enxeñeiro investira un par de meses en facer unha implementación de CBOR para almacenar datos de maneira compacta. Cando comezamos a traballar no sistema de almacenamento, resultou que a representación nativa dos datos xa era compacta dabondo e non precisabamos de CBOR para nada. Dous meses de traballo no lixo.
Outro motivo polo que YAGNI é un bo consello é que sempre é preferible ter menos código. Canto máis código haxa, máis sitios haberá nos que se poidan agochar os erros, e o programa será máis complicado, difícil de entender e difícil de manter. Iso é especialmente certo co código que non se usa, que é todo custo sen beneficio ningún. Facendo mantemento nun programa, decateime de que había un campo que non usaba ninguén. Elimineino; despois eliminei o código que facía referencia a el, e despois decateime de que isto abría a posibilidade de facer unha refactorización para simplificar o resto do programa, eliminando en total unhas oito mil liñas.
O día no que elimino oito mil liñas de código sempre é un bo día.
Cada vez que esquezo aplicar YAGNI e escribo código “por se acaso” acabo arrepentíndome, así que procuro seguilo sempre que programo. A maneira de facelo é a obvia: pregúntome se preciso agora do código que vou escribir e, se a resposta é negativa, non o escribo. Escribo hoxe o código que teño que escribir hoxe, que o código que teña que escribir mañá xa o escribirei mañá.
Ollo, que iso non significa que estea mirando só un paso adiante sen pensar no futuro. Sempre teño plans e ideas xerais do que vou facer despois, e procuro escribir o meu código de maneira que sexa doado executar eses plans, pero non escribo “código xeneralizable” ou cousas desas de boas a primeiras. É moi doado caer nesa tentación (e ben que teño caído nela), pero o único que me trae son atrasos: tardo máis en rematar o traballo de hoxe, fai máis difícil e lento traballar co meu código fonte, e moitas veces teño que acabar desfacéndoo.
A ilustración desta Folla está baseada nun gravado de Thomas Rowlandson.
Anterior: “Non acurraledes aos usuarios” | Índice | Seguinte: “O globo dos proxectos” |
Coding Sheet has an English version of this article: “Procrastinate your way to better code”. |
1 comentario