Cando fun á universidade aprendéronme moitas cousas: álxebra e física, por suposto; programación en Pascal, programación orientada a obxectos, programación funcional; algoritmos, redes neuronais, bases de datos; xestión de proxectos, seguridade, protección de datos. Porén, hai algo importantísimo que fago todos os días e do que non había ningunha materia: ninguén me ensinou a buscar erros de programación.
Parece unha parvada, pero hai moitísima xente que non sabe procurar un erro. Reciben un tícket no Jira e comezan a fozar aleatoriamente polo código fonte, a ver que pasa. Ás veces ese movemento browniano polas funcións que compoñen o programa acaba por levalos ao erro; o máis das veces acaban por desistir e o tícket queda aberto per saecula saeculorum.
Moitas veces teño eu sentado canda un compañeiro que está a facer o seu random walk e eu estou rabiando por arrebatarlle o teclado e facelo eu mesmo; porén, como son sénior teño que dar bo exemplo e ensinarlle como ser un mellor profesional. E como quero que vós tamén sexades bos profesionais, vouvos dicir a maneira de procurar erros.
É imprescindible reproducir o erro no voso ambiente de desenvolvemento. Se non o facedes, non ides ser quen de atopalo ou de saber se o puidestes arranxar. Non debería ter que dicilo, pero ás veces é moi difícil resistir a tentación de tirar para adiante cando un non é quen de reproducilo. Nese caso, o que hai que facer é mirar as diferencias entre o voso ambiente e o ambiente no que ocorre o erro e probalas unha a unha para descartalas. Con sorte, cando deades con ela, tamén vai ser a causa do erro.
Agora que podedes reproducir o erro, tedes que buscar a súa causa. Como aquí estamos a facer enxeñería do software, imos usar o método científico, que funciona moito mellor que o método supersticioso.
“Outro trasno?! Maldita a hora na que programei o ordenador para invocar demos!”
O primeiro é formular unha hipótese; é dicir, unha explicación provisional da causa do erro. O programa está a ler o ficheiro que non é, dúas persoas tentaron actualizar o mesmo rexistro a un mesmo tempo, … A hipótese debe ser unha explicación plausible do erro: se vos entrou un bicho no galiñeiro, a vosa hipótese debe involucrar unha raposa, non unha xirafa.
O seguinte paso é poñer a hipótese a proba. Moita xente pensa en confirmala buscando exemplos ao seu favor, pero iso non serve: case sempre se poden atopar moitos exemplos a favor dunha hipótese falsa. Por exemplo, se pensades que todos os números pares son maiores que 10, tedes infinitos exemplos que a “confirman”. O que tedes que buscar son exemplos na súa contra, xa que vos abonda con atopar un para refutar a hipótese.
Polo tanto, pensade nas consecuencias inevitables que tería a hipótese se fora certa e mirade se algunha delas non se está a cumprir. Por exemplo, imaxinade que vos marchou a luz da casa e pensades que é cousa da Fenosa (a hipótese). Se iso é certo, os vosos veciños tampouco van ter luz (unha consecuencia). Polo tanto, tedes que ir ver se algún deles a ten (un exemplo que a refuta).
Unha vez falsificada a hipótese, buscade outra e repetide o procedemento ata que teñades unha que non poidades refutar. Cando cheguedes a ese punto, seguide formulando novas hipóteses para afinar os vosos coñecementos ata que entendades perfectamente a causa do erro e saibades como arranxalo sen que sexa un deses “arranxos” que introducen dous erros novos.
Describíndoo así, este método semella máis complexo e lento que ir buscando ao chou, pero asegúrovos de que non o é; se o practicades, co tempo vaise facer automático e tan rápido que a xente vai pensar que facedes milagres.
A ilustración desta Folla está baseada nun gravado publicado en 1867 no Dictionnaire Infernal.
1 comentario