…ma perseverare...arghhh

E dire che mi ero anche riletto questa interessante discussione pochi mesi fa :(

Giusto così poi magari me lo ricordo, riporto qui, velocemente, la cronaca dei fatti.

  1. mi viene richiesto di modificare un componente di un grosso sistema
  2. implemento la modifica (correttamente) e mi stupisco di aver fatto anche abbastanza in fretta
  3. chiacchiero con un collega e gli dico:
    1. sai, ho già finito quella modifica…pensavo peggio
    2. funziona a dovere, ma voglio testarla sotto carico, perché potrebbe rivelarsi un bottleneck
    3. se l’avessi implementata in quest’altro modo blah blah, sicuramente non avremmo potenziali problemi di performance
  4. lui mi risponde: “mmm, magari potremmo implementarla subito in quest’altro modo blah blah…così siamo sicuri”
  5. e visto che “perseverare è diabolico” io cosa faccio? cambio l’implementazione
  6. la testo e tutto sembra ok
  7. la usano per 10 giorni in system test e tutto sembra ok
  8. oggi ci ripenso e NON tutto sembra ok

C’è una subdola maledetta race condition alla quale non ho pensato, che non è ancora stata trovata dai testers, che non si è ancora manifestata in 10 giorni di utilizzo, ma C’E’!!!

Quindi oggi chiamo il PM, chino il capo, e umilmente gli dico: “…sono un coglione…c'è un bug, non possiamo mettere quel codice in produzione…” lui (gentiluomo) deglutisce, ferma la release e mi da il tempo di risolverlo.

Risolto. Come? Togliendo l’ottimizzazione che non ero sicuro fosse necessaria. 

 

Morale (più di una):

  • non fare commenti come quelli al punto 3.3 – falli solo quando sei sicuro
  • la colpa non è del mio collega. E’ solo mia. Io stavo scrivendo il codice e me lo sentivo che non stavo facendo al cosa giusta. Dovevo prendermi il tempo per analizzare meglio il problema e convincerlo che non era il caso, visto che non eravamo sicuri ci servisse
  • NON OTTIMIZZARE CODICE SE NON SEI SICURO CHE TI SERVA OTTIMIZZARLO!!!