Una domanda breve, per essere sicuri, ma che è così piena di
complessità. Stanno chiedendo delle competenze? Ingegneria? Corsi? Concetti che sono immutabili come le leggi? Cose che nessuno può contestare?
Difficile dirlo.
La mia inclinazione è più naturalmente verso il filosofico che verso il puramente
pragmatico in queste discussioni, attenzione.
*******
Come ci si avvicina a un problema o un'opportunità determina come la soluzione
finirebbe.
Uno degli aspetti chiave dell'ingegneria del software è la capacità di
indagare con curiosità la forma e lo spazio del problema, di
comprendere le sue parti e di essere in grado di assemblarle in qualcosa di
utile e prezioso.
Questo si applica *non solo* al software attuale, ma all'intero
sistema di concezione, invenzione, implementazione, distribuzione e
manutenzione. Si guarda non solo a come questa particolare caratteristica sarà
scomposta in oggetti, funzioni, procedure, o
quello che vuoi, ma come queste parti saranno verificate, convalidate e assemblate, e come le persone che stanno lavorando su queste
varie parti e assemblaggi lavoreranno insieme.
Quindi uno dei fondamenti dell'Ingegneria del Software è:
**Essere in grado di vedere il tutto e le parti,
come
si smontano e si rimontano.**
*******
Si deve imparare a fare questo, naturalmente, poiché la maggior parte delle persone non è nata con questa capacità. Alcuni la acquisiscono prima di altri,
alcuni potrebbero non acquisirla mai, ma è qualcosa che può essere insegnato e
appreso.
Ma come?
L'ingegneria civile è probabilmente il primo tipo di ingegneria che l'uomo
ha sviluppato. Imparare a fare ponti che attraversavano fiumi, abissi e
generalmente facilitavano il commercio ha fatto parte della civiltà umana per
millenni.
Ma come è iniziata? Principalmente, perché i ponti sono caduti. Gettare un paio di tronchi dall'altra parte del fiume alla fine era abbastanza buono, ma se si voleva che qualcosa durasse più a lungo della prossima inondazione, bisognava
trovare il modo di impedire che queste cose si lavassero o cadessero e
uccidessero le persone nel processo.
Così i primi ingegneri impararono a studiare il fallimento, e imparare perché le
cose che costruiamo si rompono e cadono a pezzi. Un ingegnere del software deve fare
la stessa cosa per capire come costruire un
software migliore. Non è abbastanza per studiare *solo* i fallimenti, naturalmente;
uno ha anche bisogno di capire i progetti di successo.
In questo, si studia meglio quando si studia insieme, che è uno dei motivi per cui il movimento open source è stato un vero beneficio per imparare l'ingegneria del software. Anche nello sviluppo proprietario, però, condividere il codice con i colleghi attraverso la revisione tra pari, l'accoppiamento e lo studio è molto vantaggioso.
Quindi un altro fondamentale dell'Ingegneria del Software è:
**Un profondo senso di curiosità per gli interni del software e dei
progetti che funzionano e che falliscono, e capire cosa rende
qualcosa buona e cosa causerà problemi futuri.**
*******
Ho menzionato la nozione di "Leggi", o Concetti Fondamentali di Software
Engineering.
Ci sono alcune che si avvicinano a questo tipo di immutabilità, ma nessuna con
tanta rapidità come la Legge di Gravità.
Mi limiterò a elencarne alcuni, c'è un'informazione più che adeguata
là fuori, e diverse persone hanno i loro
preferiti.
* Don't Repeat Yourself
* Principio del minimo stupore
* Principio della minima conoscenza
* Fallo funzionare, poi fallo bello, poi fallo veloce.
**Conoscere i principi su cosa rende un buon software
architettura.
*******
Cambiando un po', ora parlerò più tecnicamente e
pragmaticamente, e queste saranno un po' più dirette.
* Non imparare una sintassi, impara un linguaggio o un framework's idiomi,
pratiche, gli spazi problematici in cui funziona meglio, quelli in cui non funziona
* Non imparare un singolo linguaggio o framework. In *Pragmatic
Programmer*, ti esortano ad imparare un nuovo linguaggio ogni anno. La
cosa è don't imparare solo un linguaggio dello stesso tipo, impararne uno
che ha diversi modi di risolvere i problemi. Se usi un linguaggio imperativo come il C, impara il Lisp o Smalltalk. Se scrivi principalmente in Perl, impara Ruby e Python. L'apprendimento non è mai
sprecato.
* Lavora sia con esercizi (kata) che con problemi reali. Non c'è
niente di più soddisfacente che risolvere uno dei propri
problemi, e questi sono i veicoli ideali per applicare l'apprendimento.
* Se incontrate qualche pezzo di un progetto che non sapete come
implementare, o un'area in cui avete bisogno di più abilità, fate un
piccolo esempio e fate pratica fino a quando non lo capite.
Un altro principio dell'ingegneria del software è:
**Essere costantemente in pratica e imparare il proprio mestiere.**
*******
Spero che altre persone trovino altri pensieri e idee. Buona
fortuna.