Hai uns anos participei nun proxecto de reescritura dun servizo. O servizo antigo tiña moitos achaques pola idade, non tiña a flexibilidade necesaria para incorporar as funcionalidades que requiría o mundo moderno, e a súa latencia era elevada de máis e non se podía reducir coa arquitectura actual. Os motivos habituais, vaia.
“Quero propoñer que, no canto de lle facer tantas emendas a esta constitución, a reescribamos enteira.”
O proxecto foi un éxito: en menos de tres anos escribimos o novo servizo e probámolo e demostramos que funcionaba mellor que o servizo antigo e axudamos aos usuarios coa mudanza e, cando marchei do proxecto, estabamos a pique de pechar o servizo vello.
No meu último día dei unha charla sobre o novo sistema, as diferenzas co vello, as melloras que tiña e unha sección especial titulada “as cousas que tería feito doutra maneira se daquela soubera o que sei eu agora”, que tiña un só punto:
“Sabendo o que sei agora, non tería reescrito o servizo, senón que o modificaría aos poucos, paseniño pero a eito, para rematar converténdoo no servizo novo”.
De todos os equipos cos que falei desde aquela, creo que só houbo dous ou tres que non tiveran entre os seus obxectivos reescribir o sistema no que traballaban, case sempre polos mesmos motivos polos que a fixemos nós, e despois de entrevistalos sempre lles dei o mesmo consello: non reescribades; refactorizade.
Os proxectos de reescritura sempre levan máis tempo do que un pensa. Sempre nos parece que imos tardar un ano e, tres anos despois, aínda estamos inmersos no Jira. Lembrade que unha reescritura consiste en refacer un proxecto que levou varios anos facer por primeira vez, así que non podedes esperar que leve pouco tempo.
Durante o tempo que dura a reescritura, hai que seguir mantendo o sistema vello: seguen a chegar erros, peticións de novas funcións, etc. Polo tanto é necesario dividir o equipo en dous: un grupo adicado ao sistema novo e outro ao sistema vello. Isto fai que todas as tarefas leven máis tempo que se todo o equipo estivera enfocado nun só proxecto.
Cando chegan peticións de nova funcionalidade xorde a pregunta: engadímolas no sistema vello e no novo, ou só no novo? Sempre hai a tentación de non as engadir no sistema vello (que pronto vai ir para o lixo) e deixalas para o sistema novo, pero daquela os usuarios non van ter acceso ás novas funcións ata que se publique o novo sistema.
Cando, por fin, o sistema reescrito está listo, moitas veces hai unha morea de cousas que funcionan no sistema vello pero non no novo: erros novos (ou que xa foran corrixidos) ou funcionalidades que desapareceron. Isto é moi decepcionante para os usuarios, especialmente cando o equipo di que o deseño do novo sistema non permite corrixir esta omisión.
E, finalmente, despois de todo o tempo e esforzo que se investiu en facer a reescritura, o equipo acaba tendo o que xa tiña antes, pero escrito doutra maneira. Non sería mellor usar todo ese tempo e facer todo ese esforzo para mellorar o sistema que xa existía?
(Non é moi agradable cando é un directivo da empresa o que nos fai esta pregunta).
Por todo iso é que, na maioría dos casos, vos recomendo non reescribir, senón refactorizar o que xa tedes. Dá máis medo que reescribir, pero non é máis difícil e ten moitas avantaxes: o equipo fica unificado porque segue a haber un só proxecto, os erros xa corrixidos fican corrixidos, as novas funcionalidades están dispoñibles para os usuarios inmediatamente, e os usuarios non teñen que agardar a que a “reescritura” estea rematada para percibir os seus beneficios senón que os van notando segundo se fan as melloras.
A ilustración desta Folla procede dun cadro de Howard Chandler Christy.
1 comentario