Il libro Coders at Work contiene interessanti interviste a famosi programmatori.
In questo post voglio scrivere qualche commento all’intervista a Jamie Zawinski:
Cosa condivido:
- Il modo migliore per immergersi in un pezzo di codice e’ prendere un task che si vuole realizzare e provare a farlo.
- Se vuoi che il prodotto sia realmente cross-platform, devi rilasciarlo per tutte le piattaforme simultaneamente. Il risultato di un porting e’ un prodotto schifoso sulla seconda piattaforma.
- La caratteristica che rende il codice piu’ facile da leggere sono i commenti. Scrivere le assunzioni e cosa fa un certo pezzo di codice.
- Non essere spaventato dalla tua ignoranza. Se tu non capisci come qualcosa funziona, chiedi a qualcuno che lo sa. Non conoscere qualcosa non significa che sei stupido, semplicemente significa che tu non la conosci ancora.
- Considera persone laureate che hanno utilizzato Java e mai C/C++ bizzarro e sbagliato.
- Un aspetto chiave di un programmatore deve essere la curiosita’, voler sapere come le cose funzionano “under the hood”
- Una importante capacita’ e’ essere capace di esplorare il codice scritto da qualcun altro e come utilizzarlo/modificarlo.
Cosa non condivido:
- Gli Unit tests non sono critici. Se non ci sono unit test il cliente non si lamenta.
- Il libro “Design Patterns” fa’ schifo. E’ giusto programmazione via taglia e incolla.
Insegnamenti e spunti per il futuro:
Ho meno di un anno di esperienza commerciale nello scrivere software e fino ad allora non avevo mai messo mano a software scritto da altre persone al di fuori di me. La prima grossa difficolta’ che ho provato dal primo giorno di lavoro e’ proprio quella di avere davanti una marea di codice gia’ scritto e doverlo capire e modificare. Credo sia abbastanza facile farsi prendere dal panico e imparare a farlo e’ veramente di una importanza cruciale nei nostri giorni dove e’ praticamente impossibile realizzare software di una certa rilevanza da soli chiusi in camera. Sembra proprio che non ci siano libri che trattino questo aspetto in una maniera sufficientemente chiara. D’altronde e’ un tema estremamente generico e l’esperienza e’ completamente diversa da software a software e da team a team. Una cosa pero’ ho capito dalla mia esperienza. Ho avuto modo di lavorare su codice legacy, senza test e senza una forte struttura e ho avuto modo di lavorare su codice veramente di ottima qualita’, ben commentato, ricco di test e con una struttura e dipendenze chiare. Inutile dirvi quanto l’immersione nel secondo progetto sia stata decisamente piu’ piacevole ed agile. Scrivere sofware di qualita’ ha molti vantaggi e questo e’ senz’altro uno di quelli.
Ho sempre avuto un approccio molto accademico alla programmazione: acquistare un libro, leggere gli esempi di codice, provarli e imparare creando qualche demo. Tuttavia questo approccio e’ particolarmente lento e forse per certi versi anche un po’ noioso. Ho sempre avuto un po’ di paura nel prendere e leggere codice scritto da altri, questo e’ stato il mio principale freno. Mi piace una introduzione sequenziale ad una tecnologia, con esempi di complessita’ crescenti che aiutino a comprenderla a fondo (appunto un approccio accademico). Tuttavia mi rendo conto che la fuori (anche in questa community) ci sono persone che imparano estremamente in fretta e forse uno dei motivi e’ proprio perche’ leggono (e scrivono) molto codice. Grazie a sofware open source abbiamo a disposizione una valanga di codice da cui trarre spunto e riflettere. Si tratta solo di iniziare a farlo sul serio…
Sito web del libro:
http://codersatwork.com/