Perché è indispensabile fare refactoring?

in Agile

In questo periodo mi sto interessando alle metologie agili, Scrum e XP in particolare. Leggendo il blog di Ron Jeffries, uno dei fondatori di XP, ho letto un articolo interessante sul refactoring. Ho tradotto le parti salienti qui di seguito.

Traduzione in italiano da: Why is refactoring a must? di Ron Jeffries.

“Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.”

  1. Scrum richiede che alla fine di ogni Sprint sia consegnato software “completato”. Sta al team decidere cosa vuole dire “completato”, ma generalmente significa eseguito, testato, integrato e pronto a funzionare.
  2. Gli Sprint durano un mese nella definizione Scrum classica, di meno nelle moderne implementazioni. Il team, quindi deve consegnare software “completato” nelle prime due settimane o nel primo mese dalla partenza del progetto.
  3. Il software in questione deve essere sviluppato a partire dal backlog del Product Owner. Il backlog deve contenere funzionalità. Per seguire Scrum correttamente, non si può consegnare elementi infrastrutturali, bisogna consegnare funzionalità.
  4. Nelle prime iterazioni non ci sarà tempo per costruire la robusta infrastruttura di cui il prodotto finale avrà necessità. Si svilupperà solo una parte di infrastruttura.
  5. Il prodotto finale, ad ogni modo, avrà bisogno di una infrastruttura completa, potente e robusta.
  6. L’infrastruttura del software, quindi, deve cambiare perché all’inizio non è possibile averla, ma alla conclusione del progetto è indispensabile.
  7. Ci sono pochi modi per cambiare l’infrastruttura. È possibile riscriverla ad ogni Sprint, oppure si può farla evolvere. Riscriverla di continuo è inefficiente, quindi farla evolvere gradualmente diventa necessario. L’evoluzione del software è refactoring. Il refactoring non è che questo.

Si deve far evolvere l’infrastruttura. Non è una regola, è una legge naturale. Fin quando non si impara a far evolvere il design, Scrum potrà portare vantaggi, ma sicuramente non funzionerà al meglio delle possibilità, portando rallentamenti man mano che il tempo passa.

3 Comments

PHP4 riposa in pace

in PHP

Il 7 agosto è stata rilasciata l’ultima versione php4, la 4.4.9. È ufficialmente l’ultima versione di php4, dopodiché non ce ne saranno più, nemmeno per correggere problemi di sicurezza.

La versione 4.0.0 di php è stata rilasciata nel lontano maggio del 2000, oggi dopo 8 anni e dopo 3 anni dal rilascio di PHP5, credo che sia arrivata finalmente l’ora di aggiornare.

Chi non l’ha ancora fatto installi PHP 5.2 e tenga d’occhio gli ultimi aggiornamenti sul fronte PHP 5.3 ricco di interessanti funzionalità e ormai prossimo alla release.

2 Comments

PHP6 e supporto unicode al 50%

in PHP

In una nota sul suo blog, Andrei Zmievski, coordinatore del progetto di implementazione dello standard unicode in php6, ha annunciato che il supporto ad unicode è stato implementato nel 50% delle 3084 funzioni incluse in php6. Sembra una notizia incoraggiante, considerando che solo pochi mesi fa si era solo al 10%.

0 Comments

Stefan Esser esce da security@php.net

in PHP

Negli ultimi giorni si è fatto un gran parlare della decisione di Stefan Esser di voler uscire dal team che si occupa di curare l’aspetto sicurezza di PHP da egli stesso fondato. La sua motivazione è molto semplice, è arrivato a pensare che rendere PHP più sicuro dall’interno sia inutile. Lasciando perdere le beghe interne tra sviluppatori del core, credo che PHP abbia sempre maggiormente bisogno di persone che sappiano portare avanti progetti come hardened-php e Suhosin.

Per chi volesse approfondire la bega :-) ecco alcuni link:

0 Comments

Novità intelligenti

in PHP

Due novità interessanti dal sito di Smarty, uno dei motori di template più diffusi per PHP:

Il libro, disponibile da aprile, sembra piuttosto completo ed è indirizzato sia agli sviluppatori che ai designer.

0 Comments