Número 37
14 de decembro de 2022

Moita listeza

Un comentario que fago moitas veces cando reviso código é “non me sexas tan enxeñoso”. Con isto quero dicir que o código que escribiron é complicado de máis e deberían empregar unha alternativa máis simple.

Cando comezamos a aprender a programar, sempre escribimos programas moi simples. Ao practicarmos e adquirirmos coñecemento e experiencia, as nosas ambicións medran e éntrannos ganas de trabar bocados máis grandes e —sobre todo— de aplicar todo o que sabemos. E, cando o noso problema non é complexo dabondo para lucírmonos, é cando comezamos a inventar a nosa propia complexidade.

Un home vestido coma no século XIX traballa nunha máquina semellante a un ordenador.“Esta máquina é marabillosa! Con ela podo desenvolver as miñas teorías sobre o éter luminífero moito máis rápido!”

É ben coñecido o síndrome do programador que, despois de aprender que existen os patróns de deseño, pasa uns meses ou un par de anos tratando de poñer decoradores e visitantes e factorías e todo iso que aprendeu en todos os programas que escribe, incluso se eses patróns non son necesarios.

No mundo do software, a complexidade é o noso inimigo mortal. Canto máis complicado é un programa ou biblioteca, máis probable é que teña erros e que sexan difíciles de atopar; polo tanto, deberiamos escribir o noso código o máis simple que poidamos e procurar non usar demasiada listeza.

Ás veces estamos tan afeitos a tratar con problemas complicados que o noso primeiro instinto é botar man dunha solución complexa malia non ser necesario. Iso é o que me pasou no traballo con Cris.

Un dos nosos clientes internos queixábase de que o noso programa lle ía lento. Ese programa tiña unha opción para extraer información de depuración, pero o cliente usaba o programa de certa maneira que non lle permitía activar esa opción. Para podermos investigar o problema, Cris e mais eu decidimos engadir algún código para modificar as opcións por defecto dependendo do usuario.

Cando Cris me mandou o cambio para revisar, este cambio contiña un ficheiro de configuración coa lista de usuarios e opcións para activar, unha función para ler e interpretar ese ficheiro de configuración e outra función para activar as distintas opcións segundo o usuario que estea a executar o programa. En total: 150 liñas de código. A miña resposta foi:

—Só precisamos de facer isto para un só usuario e podemos publicar unha versión nova do noso programa en cinco minutos. Borra todo isto e cámbiao por un “if”.

Eu son un fan absoluto de facer o programa máis simple posible para as necesidades actuais. Xa teremos tempo de complicar o programa se os requirimentos tamén se tornan máis complicados. Esa é unha actitude que adoptei co paso do tempo, segundo vía que os programas complicados que eu escribía case nunca funcionaban ben de todo, mentres que os programas simples case sempre funcionaban á primeira. Recoméndovos que fagades o mesmo.

E, se non me facedes caso a min, facédello a Brian Kernighan, un dos inventores de Unix e da linguaxe C. Brian dixo que procurar erros é o dobre de difícil que escribir un programa; polo tanto, se escribes o código máis enxeñoso do que es capaz, por definición non es intelixente dabondo para corrixilo. Penso eu que algo saberá.

A ilustración desta Folla foi producida mediante intelixencia artificial.