Quali sono i fondamenti dell’ingegneria del software?

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.