Leggo un’interessante lista di indizi dal blog di Reinhold Weber che secondo lui bastano a definire davvero scarso (schifoso sarebbe la traduzione esatta) un programmatore PHP. Si tratta di 40 “regole” di buona programmazione e progettazione che ci invitano a riflettere sul proprio modo di agire e sperano di scatenare qualche buon proposito per migliorarsi.
Su alcuni concordo più che su altri:
- non commenti il codice con qualcosa tipo phpDoc, io aggiungo non commenti il codice e basta
- non esegui l’escaping e la validazione di input e delle query sql (di cui abbiamo parlato)
- non pianifichi, progetti la tua applicazione in modo dettagliato prima di cominciare a scrivere codice
- non tieni separati i diversi layer utilizzando qualcosa basato su MVC (model-view-control)
- non ha mai sentito parlare di sql injection or cross-site scripting (Xss)
- non usi un abstraction layer per interagire con i database
- …
E voi cosa ne pensate? Lasciate pure la vostra opinione nei commenti qui sotto.
Sono Daniel Londero un web developer che lavora ogni giorno con PHP ormai da 4 anni.
Da 2 anni a questa parte mi sono molto interessato a 
Grazie per l’avviso, facciamo che ogni post in bozze te lo faccio revisionare prima della...
40 indizi per definirti uno scarso programmatore PHP…
Leggo un’interessante lista di indizi dal blog di Reinhold Weber che secondo lui bastano a definire davvero scarso (schifoso sarebbe la traduzione esatta) un programmatore PHP. Si tratta di 40 “regole” di buona programmazione e progettazione che …
40 indizi per definirti uno scarso programmatore PHP…
Leggo un’interessante lista di indizi dal blog di Reinhold Weber che secondo lui bastano a definire davvero scarso (schifoso sarebbe la traduzione esatta) un programmatore PHP. Si tratta di 40 “regole” di buona programmazione e progettazione che …
Diciamo che al giorno d’oggi ci sono troppi ragazzi saputelli che si credono dei grandi programmatori.
Con il fatto di Ajax e web 2.0, il n° di queste minchiette è aumentato a livello esponenziale.
Il problema è che queste checche con i loro progetti ,strampalati a livello di programmazione, fanno soldini, magari non a palate, a flusso continuo.
Ora bisogna capire questo: tutte le raccomandazioni su come programmare valgono sempre in qualsiasi contesto, oppure ogni tanto è meglio chiudere un occhio e partire con un progetto alla “branca leone”?
Posso concordare in parte con te: in fase di prototipizzazione e startup di un servizio credo che in molti partano alla “branca leone” come dici tu. E’ chiaro che questo può andare bene per capire se la cosa può andare o meno a livello di appetibilità da parte del pubblico. E’ anche vero che se il servizio dovesse prendere piede e si dovesse cominciare a scalare l’architettura per rispondere alle richieste sarebbe davvero un bagno di sangue richiedendo la totale riscrittura del codice.
Ok piccolo sfogo di un programmatore… IO non dico di essere un programmatore OO ma ancora attaccato alla cara e vecchia programmazione strutturata.
Cmq vorrei aggiungere questo (so che è OT ma è sempre bene ricordarlo):
prima di fare il progetto vero e proprio, sarebbe ideale preparare un prototipo funzionante e redigerlo, magari, con il cliente. Come? Mettendolo in corso d’opera e cercare di capire i feedback del cliente, sistemarli nel prototipo e vedere che effetto produce.
In questa fase tralasciare tutte le tematiche di programmazione..
Poi, dopo aver un prototipo completo, si costruisce il programma completo, applicando tutte le tematiche di programmazione.
Riassumendo:
- progetto su carta con tutti i flussi dell’occorenza;
- costruzione di un prototipo, verifica delle funzionalità del prototipo e modifiche richieste dal cliente
- sviluppo architetturale in base al prototipo funzionante.
- progettazione OOP o Strutturata in base al tipo di progetto ed in base al target
- sviluppo e feedback continui sullo stato del progetto.
Questa è una mia piccola considerazione che estende un po’ la fase di programmazione vera e propria.
Sono dell’idea il tipo di programmazione da adottare è fortemente influenzata dalla progettazione su carta del progetto.
Su questo siamo d’accordo, dopo la raccolta dei requisiti e la stesura delle specifiche è bene realizzare un prototipo pensando unicamente alle funzionalità tralasciando la qualità. Facendolo vedere al cliente questo sarà in grado di toccare con mano le cose che ha richiesto (specie le vaccate) e correggere il tiro.
Solo dopo si passa a creare il prodotto che andrà in produzione.