L'ingegneria del software è diversa dalla programmazione

Tutti gli ingegneri del software possono programmare, ma non tutti i programmatori possono progettare il software

jsComplete.com/pro-programmer
Aggiornamento: questo articolo fa ora parte del mio libro "The Professional Programmer".
Leggi la versione aggiornata di questo contenuto e ulteriori consigli sulla programmazione su jscomplete.com/pro-programmer.

Ad alcune persone non piace il termine Software Engineer a causa della metafora ingegneristica. Questo articolo non parla di quel termine. Se non ti piace, puoi sostituirlo con l'autore del software, l'artigiano del software o l'artista del software!

Per ingegnere del software, intendo una persona che considera la scrittura di software di qualità come la loro professione. Una persona che applica scienza e statistica a quella professione e non la considera solo un lavoro che guadagna denaro.

Saper programmare non ti rende un ingegnere del software.

Chiunque può imparare a programmare. È facile. Chiunque può creare semplici programmi che funzionano per loro sui propri computer ma che non garantirebbero che gli stessi programmi funzionino per gli altri.

La mia analogia preferita su questo è che tutti possono cantare e divertirsi sotto la doccia, ma quando è il momento della festa non si riproducono registrazioni di se stessi cantando. Vai con i professionisti.

Altre analogie? Sicuro:

  • Abbiamo imparato matematica e scrittura a scuola, ma ciò non ci ha reso matematici e autori.
  • La maggior parte di noi può facilmente imparare a cucinare, ma quando è il momento di dare da mangiare a molte persone assumiamo uno Chef.
  • Non si chiama il tuttofare del quartiere per costruire una casa da zero.

Il messaggio principale che voglio condividere in questo articolo è che i programmi semplici sono molto diversi dai programmi progettati.

L'atto di programmazione, nella sua definizione più semplice, sta dando ai computer le istruzioni per fare qualcosa con qualche input per produrre un output.

L'atto del software di ingegneria riguarda la progettazione, la scrittura, il collaudo e la manutenzione di programmi per computer allo scopo di risolvere problemi per molti utenti. Si tratta di creare soluzioni robuste e sicure che resistano alla prova del tempo e funzioneranno per alcuni dei problemi sconosciuti intorno a quelli ovvi originali.

Gli ingegneri del software comprendono tutto sui problemi che risolvono, le soluzioni che forniscono, i limiti di tali soluzioni, le loro implicazioni sulla privacy e le loro implicazioni sulla sicurezza.

Se qualcuno non capisce il problema, non dovrebbe essere autorizzato a programmare una soluzione per esso.

La soluzione Mentalità

Gli ingegneri del software non pensano alla loro carriera solo come scrivere programmi. Pensano in termini di soddisfare i bisogni e risolvere i problemi. Questo è importante perché non tutti i problemi richiedono un programma. Alcuni problemi possono essere risolti da programmi esistenti o mettendo insieme più programmi. Alcuni problemi possono essere totalmente evitati agendo in anticipo. La progettazione di buoni programmi spesso implica la pianificazione per prevenire problemi futuri.

“Gli intellettuali risolvono i problemi, i geni li prevengono. “
- Albert Einstein

I problemi complicati di solito richiedono la scrittura di più programmi. Alcuni problemi richiedono programmi eseguiti in parallelo, mentre altri richiedono l'esecuzione in sequenza dei programmi. Alcuni problemi possono essere risolti educando gli utenti.

Prima di scrivere un programma, un ingegnere del software pone le domande:

  • Quali problemi sto cercando di risolvere?
  • Cos'altro oltre alla scrittura del codice può essere fatto per risolverli?
  • Cosa posso fare per semplificare la risoluzione di questi problemi con il codice?

Qualità del codice

I grandi programmi sono chiari e leggibili, possono essere facilmente estesi, funzionano benissimo con altri programmi e mantenerli non è un incubo. La qualità del codice non è una cosa negoziabile, usare scorciatoie a causa di una scadenza o emozione non è mai accettabile.

Uno degli aspetti più importanti del software di ingegneria è progettare qualsiasi cosa da zero pronta per l'estensibilità. La modifica del software è un dato di fatto. Gli utenti richiederanno più funzionalità e modi più semplici per utilizzare il software.

Un software di solito non è molto utile da solo. Utili funzionalità software iniziano quando più parti di software comunicano tra loro, scambiano i loro dati e collaborano al compito di presentare dati e interfacce agli utenti.

I programmi devono essere progettati tenendo conto di ciò. Quali messaggi accettano? Quali eventi sono monitorati? Quali messaggi vengono emessi? Come possiamo autenticare e autorizzare le comunicazioni?

Un altro aspetto importante di grandi programmi è la chiarezza del codice, non quanti test ci sono o il numero nel rapporto di copertura dei test. È la semplice domanda di questo codice è leggibile da qualcun altro? O meglio, lo scrittore di codice di oggi, capirei questo codice tra qualche settimana?

"Ci sono solo due cose difficili in Informatica: invalidare la cache e denominare le cose."
- Phil Karlton

La leggibilità del codice è molto più importante di quanto si pensi. Sfortunatamente, non ci sono buone metriche per la chiarezza del codice. Memorizzare buone prassi e schemi software potrebbe essere utile, ma spesso non è sufficiente. I bravi ingegneri del software sviluppano solo un occhio per la chiarezza del codice con esperienza e intuizione. La metafora della scrittura qui è perfetta: solo conoscere un grande elenco di parole non ti aiuterà a scrivere contenuti concisi e chiari.

"Non ho avuto il tempo di scrivere una lettera breve, quindi ho scritto una lettera lunga".
- Mark Twain

Le cose andranno male con i programmi. Essere in grado di risolverli facilmente quando lo fanno è un attributo chiave di un buon software. Gli errori che si verificano nei programmi dovrebbero avere messaggi chiari ed essere registrati centralmente da qualche parte per essere monitorati. Quando viene segnalato un nuovo errore, la persona che deve correggerlo dovrebbe essere in grado di eseguire il debug di tale errore. Dovrebbero essere in grado di agganciarsi al sistema e leggere le informazioni sul contesto di esecuzione in qualsiasi momento. Dovrebbero essere in grado di verificare facilmente le aspettative su qualsiasi parte del sistema.

Ambienti e test

Quando gli ingegneri del software scrivono programmi, si assicurano che i loro programmi funzionino in molti ambienti diversi, su macchine con risorse diverse e in diversi fusi orari. Il software deve funzionare su diverse dimensioni e orientamenti dello schermo. Deve inoltre gestire il fatto di essere costretto a utilizzare memoria o potenza di elaborazione limitate.

Quando si crea un software per un browser Web, ad esempio, deve funzionare in tutti i diversi browser principali. Quando si crea un software desktop, nella maggior parte dei casi deve funzionare per utenti Mac e Windows. Quando si creano applicazioni che dipendono dai dati, il software deve funzionare nel caso in cui la connessione per recuperare quei dati sia lenta o completamente spenta per un po '.

Per scrivere un software, gli ingegneri del software cercano di pensare a ogni possibile scenario che possono immaginare e hanno in programma di testare questi scenari. Questo inizia con quello che chiamano il percorso felice in cui non accade nulla di inaspettato, ma soprattutto documentano ogni problema che potrebbe accadere e pianificano un test per questo. Alcuni ingegneri del software iniziano scrivendo codice, che chiamano casi di test, che simula questi scenari. Quindi scrivono il codice desiderato che supera tutti questi casi di test.

Gli ingegneri del software comprendono i requisiti del software che di solito sono ambigui e incompleti. L'abilità unica di un talentuoso ingegnere informatico non riguarda il modo di scrivere la soluzione, ma piuttosto l'identificazione di ciò che dovrebbe andare nella soluzione.

Costo ed efficienza

Gli ingegneri del software possono risolvere rapidamente i problemi nella maggior parte dei casi. Se pensi che assumere programmatori esperti significhi costi più elevati, ripensaci. Più esperto è il programmatore che assumi, più velocemente possono fornire soluzioni robuste, accurate, affidabili e mantenibili. Ciò significa costi inferiori a lungo termine.

È inoltre necessario considerare il costo di esecuzione del programma. Ogni programma utilizzerà le risorse del computer e quelle non sono gratuite. Gli ingegneri del software scriveranno programmi efficienti che non utilizzano inutilmente le risorse del computer. Ad esempio, la memorizzazione nella cache dei dati utilizzati di frequente è una strategia che si applica qui, ma è solo una delle migliaia di strumenti e varianti che possono rendere un programma più veloce ed efficiente.

Un programmatore principiante potrebbe offrirti una soluzione economica, ma l'esecuzione di tale soluzione potrebbe costare molto di più a te e ai tuoi clienti che se tu avessi un programmatore esperto creare una soluzione efficiente in primo luogo.

usabilità

I buoni programmi sono progettati tenendo presente l'esperienza utente (UX). L'interazione uomo-computer è un argomento importante con innumerevoli studi e risultati di ricerca. Più questi risultati vengono accolti, migliore sarà il software.

Vorrei fare alcuni esempi qui solo per avere un assaggio di questo grande dominio:

  • Quando si progettano moduli di input in cui gli utenti devono immettere dati, ad esempio il loro indirizzo e-mail, un buon programma di ricezione ignorerebbe il maiuscolo / minuscolo utilizzato per l'indirizzo e-mail. Tagliava anche eventuali spazi extra attorno ad esso. Non dare problemi all'utente perché la sua chiave CAPSLOCK è attiva, l'e-mail è unica nel suo formato minuscolo. Se il programma accetta nuovi indirizzi e-mail, convalidalo presto per dare all'utente un messaggio chiaro che probabilmente hanno usato l'indirizzo sbagliato. Ciò include ovvi problemi di convalida come non avere un segno @ ma dovrebbe anche includere i problemi di convalida non così ovvi come l'uso di un "gmail.ocm" errato.
  • Quando reindirizza un utente a fare qualcosa, un buon programma ricorderebbe la loro posizione originale e li reindirizzerebbe a quella posizione quando hanno finito. Un buon programma ricorderebbe anche tutti i dati e le interazioni già definiti che devono essere associati ai passaggi futuri che l'utente deve fare. Ad esempio, supponiamo che tu stia cercando voli come ospite su Expedia. Hai quindi deciso di creare un account. Tutta la tua ricerca precedente verrebbe salvata nel nuovo account e potresti accedervi da macchine completamente diverse.
  • Un buon programma è progettato pensando agli scenari dell'utente. Mettiti nei panni dei tuoi utenti. Non aggiungere solo funzionalità! L'altro giorno ho prenotato un volo United dimenticando di includere il mio numero frequent flyer. Dopo aver ottenuto la conferma, sono andato sul sito Web United per aggiungere il mio FF # al volo e mi ci sono voluti dieci minuti buoni per capirlo. Non c'era un percorso ovvio, quindi ho dovuto esplorare tutti i collegamenti che potrebbero portare a quella funzione. Ho visitato la pagina in cui la funzione era disponibile e non riuscivo a vederla la prima volta perché era sepolta in profondità in una forma grande. Si è scoperto che dovevo modificare le informazioni del viaggiatore, scorrere oltre 20 elementi di input in quel modulo, selezionare il tipo di FF # che volevo usare e inserire anche il numero di telefono richiesto per inviare l'intero modulo. Questo è un esempio di un programma che non è stato progettato pensando dal punto di vista dell'utente.

Affidabilità, sicurezza e sicurezza

Questi sono probabilmente i punti più importanti che distinguono i professionisti del software dai dilettanti. Sanno che sono responsabili della scrittura di soluzioni sicure e protette.

Un software deve essere resistente a input errati, cattivi stati e interazioni errate. Questo è MOLTO difficile da realizzare ed è il motivo principale per cui sentiamo storie di persone che muoiono a causa di errori del software.

Gli utenti useranno il software con input errati o errati. Alcuni lo faranno intenzionalmente per cercare di rompere il software e hackerare le risorse rappresentate da quel software. La persona che era presumibilmente responsabile del recente fiasco di Equifax è stata accusata di non fare il proprio lavoro, che è di ingegnerizzare la resilienza a input dannosi e dannosi in tutto il software esposto pubblicamente.

La storia della sicurezza non riguarda solo input cattivi e dannosi, ma a volte anche input normali. Se gli utenti dimenticano le loro password, quante volte possono provare? Li rinchiudi dopo? Cosa succede se qualcun altro sta cercando di bloccarli? Consenti ai tuoi utenti di inviare la password tramite una connessione non crittografata? Cosa succede se un tentativo di accedere a un account proviene da un luogo insolito? Cosa fai se il login sembra automatizzato?

Cosa fai per proteggere i tuoi utenti da scripting cross-site e richiedere falsificazioni, attacchi man in the middle e semplici phishing sui social? Hai una strategia di backup se ricevi un attacco DDoS sui tuoi server? Queste domande sono solo per citare alcune delle molte preoccupazioni da pianificare.

I programmi sicuri non memorizzano le informazioni sensibili come testo in chiaro ma piuttosto come dati crittografati unidirezionali con algoritmi molto difficili da interrompere. Questa è una strategia di backup nel caso in cui il programma e i dati vengano compromessi. Gli hacker troverebbero dati crittografati per la maggior parte inutili.

Il software andrà in cattivi stati e dovrà essere corretto. Al meglio dei programmi si verificheranno problemi imprevisti. Se non sei a conoscenza di ciò e non lo stai pianificando, non sei un professionista del software, sei solo uno scrittore di programmi non sicuri.

I difetti del software sono invisibili. La nostra capacità intellettuale di prevedere e prevenire difetti noti è limitata. Questo è il motivo per cui gli ingegneri del software comprendono il valore di buoni strumenti che possono aiutarli a scrivere software corretto e sicuro.

Abbracciare gli strumenti

Non c'è dubbio che abbiamo bisogno di strumenti più e migliori. Gli strumenti fanno una grande differenza e sono spesso sottovalutati.

Immagina se abbiamo ancora bisogno di file FTP per la distribuzione! Immagina di eseguire il debug di problemi di rete e prestazioni senza Chrome DevTools! Immagina quanto sarebbe inefficiente oggi scrivere JavaScript senza ESLint e Prettier!

Se sei uno sviluppatore JavaScript e, per qualche motivo, sei costretto a scegliere un solo plugin per il tuo editor di codice, dovresti scegliere ESLint.

Qualsiasi strumento che accorcia il ciclo di feedback durante la scrittura del codice dovrebbe essere un'aggiunta gradita. L'argomento di Bret Victor sull'invenzione di rappresentazioni visive immediate a ciò che creiamo mi ha aperto gli occhi. Abbracciare e migliorare gli strumenti è un modo per portarci in quel futuro luminoso. Vai a guardare il discorso di Bret in questo momento se non l'hai mai visto prima.

Quando trovo un nuovo fantastico strumento, il mio unico rimpianto non è stato quello di utilizzare lo strumento prima. Strumenti migliori ti aiuteranno a essere un programmatore migliore. Trovali, usali, apprezzali e, se puoi, migliorali.

La scelta della lingua è importante. La sicurezza del tipo è importante. La cosa migliore che è successo a JavaScript è TypeScript (e Flow). L'analisi statica del codice è un affare più grande di quanto si pensi. Se non lo fai, ti stai praticamente rendendo vulnerabile a incognite future. Non codificare senza un sistema di battitura statico. Se la tua lingua preferita non ha una digitazione statica, cambia lingua o trova un transpiler. Oggi i Transpiler sono abbastanza intelligenti da funzionare semplicemente leggendo i commenti in codice, che penso sia il futuro del controllo del tipo per le lingue che non lo supportano in modo nativo.

L'evoluzione dell'ingegneria del software

Nessuno può imparare l'ingegneria del software in due mesi, sei o addirittura un anno. Non impari ad essere un ingegnere del software in un bootcamp. Ho imparato negli ultimi 20 anni e sto ancora imparando oggi. Sono diventato abbastanza sicuro di potermi definire un programmatore esperto solo dopo circa un decennio di apprendimento e dopo aver progettato, realizzato e gestito applicazioni utilizzate da migliaia di utenti.

L'ingegneria del software non è per tutti, ma tutti dovrebbero imparare a risolvere i propri problemi con i computer. Se puoi imparare a scrivere programmi semplici, dovresti. Se puoi imparare ad usare servizi software generici, dovresti. Se riesci a imparare a usare il software open source avrai molta potenza.

I problemi si evolvono e così dovrebbe l'ingegneria del software. Il futuro di questa professione è consentire agli utenti di computer regolari di utilizzare i propri computer senza dover studiare cinque anni per farlo. Consentire agli utenti di risolvere da soli i semplici problemi con strumenti di facile utilizzo. Gli ingegneri del software passerebbero quindi a creare strumenti migliori, a risolvere problemi noti più grandi e fare del loro meglio per prevenire quelli sconosciuti.

Grazie per aver letto.