Chi è un ingegnere del software? Ingegneria del software VS “semplice” programmazione

Portiamo alla vostra attenzione un adattamento di un articolo di Samer Buna sulle differenze tra ingegneria del software e programmazione, o su come lo sviluppo di un concetto di software differisce dalla "semplice codifica". Tutti gli ingegneri del software sanno programmare, ma non tutti i programmatori possono sviluppare concetti software. Ad alcune persone non piace il termine "Ingegnere del software" (noto anche come Ingegnere del software) perché molto spesso usiamo la parola "ingegnere" quando parliamo di qualcosa di più fisico, ad esempio la costruzione. Il nostro articolo, ovviamente, non riguarda il termine stesso. Se improvvisamente ti provoca un rifiuto, può essere facilmente sostituito con qualcosa legato alla creatività. "Creatore di software", "Autore di software"... o anche "Creatore di software"! La capacità di programmare non rende automaticamente una persona un ingegnere del software. Chiunque può imparare a programmare ed è molto più semplice di quanto sembri. Chiunque può creare un semplice programma per uso personale, ma ciò non garantisce che lo stesso programma funzionerà per altri. Il mio esempio preferito è questo: molti di noi cantano sotto la doccia, ma, ahimè, questa esibizione non è sempre degna di un palcoscenico professionale. Naturalmente, per un'esperienza musicale di alta qualità, molto probabilmente ti rivolgerai a un professionista. Hai bisogno di altri esempi?

• Tutti impariamo la matematica e la scrittura a scuola, ma questo non ci rende matematici e scrittori.
• La maggior parte di noi è in grado di preparare un piatto passabile e talvolta molto gustoso, ma non tutti oserebbero cucinare una tavola per 100 persone per una cena in ambasciata. In questo caso assumiamo un cuoco.
• Sei pronto adesso per affidare completamente la costruzione della tua nuova casa al figlio del vicino che crea impressionanti capolavori con i Lego?

Il punto principale che cerco di trasmettere in questo articolo è che i programmi semplici sono molto diversi dai programmi progettati dagli ingegneri. La definizione più semplice del processo di programmazione: elaborare una sequenza ordinata di azioni per un computer al fine di ottenere qualcosa di specifico come output, dati determinati parametri di input. Il processo di ingegneria del software è la progettazione, scrittura, test e cura di un programma per computer per risolvere problemi per molti utenti. Si tratta di creare soluzioni affidabili e sicure che resisteranno alla prova del tempo e funzioneranno per alcune sfide forse sconosciute oltre l'ovvio. Gli ingegneri del software sanno tutto sui problemi che risolvono, sulle soluzioni che propongono, sui limiti di tali soluzioni, sulla loro privacy e sicurezza. Secondo me, se una persona non capisce l'essenza del problema, non dovrebbe nemmeno iniziare a programmarne la soluzione.

Mentalità ingegneristica: ricerca di soluzioni applicate

Gli ingegneri del software non considerano la scrittura di software di per sé il loro obiettivo principale. Pensano in termini di soddisfazione dei bisogni e risoluzione dei problemi . Questo è importante perché non tutti i problemi richiedono una soluzione software. Alcuni di essi possono essere gestiti utilizzando i programmi esistenti. Talvolta il verificarsi di alcuni problemi può essere previsto in anticipo e, con l'aiuto di una progettazione competente del programma, è possibile evitarli in futuro. I problemi complessi spesso richiedono la scrittura di molti programmi. Esistono attività che richiedono applicazioni in esecuzione parallela, mentre altre richiedono l'esecuzione sequenziale di diversi programmi. Molti problemi possono essere risolti semplicemente formando gli utenti. Prima di iniziare a creare un programma, un ingegnere del software si pone una serie di domande:

• Quali problemi dovrei risolvere?
• Cos'altro puoi fare oltre a scrivere codice per risolverli?
• Cosa posso fare per semplificare queste attività con l'app?

Qualità del programma e qualità del codice

I buoni programmi sono chiari e leggibili. Sono facili da estendere, funzionano bene con altri programmi e non sarà un incubo lavorarci. La qualità del codice non è negoziabile. Dovrebbe essere alto, tutto qui. A questo proposito, scuse come il cattivo umore del programmatore o le scadenze troppo strette (oh, quelle scadenze!) sono inaccettabili. Uno degli aspetti più importanti dello sviluppo del software è progettare il programma in modo tale che sia facile da mantenere e modificare in futuro (ciao, OOP!). Oggi quasi tutti i software sono modificabili, spesso questo processo avviene anche senza la partecipazione dell’utente o non richiede nulla da parte dell’utente se non “il tuo programma è stato aggiornato, clicca su OK o Posticipa”. Naturalmente, gli utenti hanno il diritto di richiedere nuove funzionalità alle applicazioni (soprattutto se parliamo di software aziendale di lunga durata scritto in Java o di giochi online che possono essere giocati per anni). Un pezzo di codice di per sé difficilmente può essere definito utile. La funzionalità utile del software inizia quando pezzi disparati di applicazioni comunicano tra loro, scambiano dati e lavorano insieme per svolgere il compito di presentare dati e interfacce agli utenti. I programmi dovrebbero essere progettati tenendo presente questi punti! Quali messaggi ricevono? Quali eventi vengono monitorati? Come avviene l'autenticazione e l'autorizzazione? Un altro segno altrettanto importante di un buon programma è la chiarezza del codice, non il numero di test che l'applicazione ha superato o anche una buona copertura dei test. Domande apparentemente semplici: “Qualcuno diverso da me può capire il mio codice?”, “Sarò in grado di scrivere questo codice oggi e di capirlo tra qualche settimana?” Una citazione popolare sulle due cose più difficili nella programmazione dice: La leggibilità del codice è molto più importante di quanto comunemente si creda. Sfortunatamente, non è possibile definire metriche o parametri precisi per la chiarezza del codice. Memorizzare le norme linguistiche generalmente accettate, i buoni modelli software e i metodi di sviluppo aiuterà in parte. Ma solitamente questo non basta. Con il tempo e l’esperienza, i veri professionisti sviluppano, per così dire, un “senso di chiarezza”, qualcosa di simile all’intuizione. Una metafora della scrittura funziona bene qui: conoscere molte parole non ti aiuterà a scrivere qualcosa che sia conciso e chiaro nel significato. La capacità di correggere i bug in modo rapido e semplice è una caratteristica fondamentale di un buon software. Gli errori nel programma dovrebbero inviare messaggi chiari ed essere registrati centralmente per il monitoraggio. Quando viene segnalato un nuovo errore, la persona che lo risolverà deve avere la capacità di eseguirne il debug. Deve connettersi facilmente al sistema, accedere alle informazioni sull'esecuzione in qualsiasi momento ed essere anche in grado di controllare facilmente la funzionalità di qualsiasi parte del sistema.

Ambienti e test

Quando gli ingegneri del software sviluppano applicazioni, fanno del loro meglio per garantire che funzionino su computer con architetture diverse e con sistemi operativi diversi. È importante che il software funzioni con risoluzioni e orientamenti dello schermo diversi e che non “consumi” più memoria e potenza di elaborazione del necessario. Quando si tratta di applicazioni web, devono funzionare in tutti i principali browser. Quando crei un'applicazione desktop, devi assicurarti che venga avviata e funzioni correttamente su Mac, Windows e Linux. Bene, il programma dipende dai dati, quindi l'applicazione dovrebbe funzionare anche in caso di connessione dati lenta o sua assenza. Per scrivere un software, gli ingegneri pensano a tutti i tipi di opzioni di scenario e pianificano di testarli. Tutto inizia con la scelta dell'opzione ideale, in cui tutto funziona senza errori. Quindi documentano eventuali problemi potenziali e li inseriscono nel piano di test. Alcuni ingegneri iniziano scrivendo codice, che chiamano test case, che simula scenari per tutti i probabili problemi ed errori. E poi viene scritto un programma che può funzionare con qualsiasi opzione considerata. L'abilità unica di un ingegnere del software di talento non è sapere come scrivere codice, ma capire cosa dovrebbe fare esattamente l'applicazione come output e come ottenerlo. Quando i requisiti software del cliente sono incompleti e possibilmente ambigui, l'ingegnere deve valutarli e “comprenderli” correttamente.

Costo ed efficienza

Un ingegnere del software può risolvere rapidamente il problema nella maggior parte dei casi. Se pensi che assumere un programmatore esperto "costoso" aumenterà i tuoi costi, ripensaci. Quanto più esperto è il programmatore assunto, tanto più velocemente sarà in grado di fornire una soluzione semplice, accurata, affidabile e facile da usare. A lungo termine, ciò ridurrà sicuramente i costi di sviluppo del software. È inoltre necessario considerare i costi di esecuzione del programma. Qualsiasi programma utilizza risorse informatiche e non sono gratuite. Ad esempio, la memorizzazione nella cache dei dati a cui si accede frequentemente è una delle possibili strategie utilizzate per ottenere il risultato desiderato. Ma questo è solo uno delle centinaia di strumenti e soluzioni che possono rendere un programma più veloce ed efficiente. Un programmatore alle prime armi può fornirti una soluzione economica, ma l'utilizzo di tale soluzione alla fine costerà a te e ai tuoi clienti molto di più che se lavorassi con uno sviluppatore esperto che ha creato una soluzione efficace in primo luogo.

Concentrati sull'esperienza dell'utente

Un buon programmatore sviluppa pensando all'esperienza utente (UX). L’interazione uomo-macchina è un argomento con infinite ricerche e soluzioni. Più soluzioni vengono applicate, migliore sarà il risultato del programma. Ecco alcuni esempi, solo per darti un'idea di quale sia questa direzione:

• Quando si progettano moduli di immissione dati come la posta elettronica, un buon programma dovrebbe ignorare il caso dell'indirizzo di posta elettronica. Non dovrebbe generare un errore se viene premuto il tasto CAPSLOCK perché l'indirizzo e-mail è univoco in lettere minuscole. Se il programma accetta un nuovo indirizzo email come input, controllalo all'inizio del processo di input per avvisare l'utente che sta utilizzando il formato dell'indirizzo sbagliato. Questa soluzione include sia controlli ovvi come il segno “@” mancante, sia controlli meno ovvi, come il controllo dell'ordine sbagliato di caratteri come “gmail.ocm”

• Quando l'utente viene reindirizzato per eseguire un'azione, un buon programma dovrebbe ricordare la sua posizione attuale e riportarlo indietro una volta terminata. Un buon programma dovrebbe anche ricordare i dati già trasmessi dall'utente, il che è importante per un'ulteriore interazione con lui.

  Supponiamo che tu stia cercando viaggi aerei come ospite su Expedia. Successivamente decidi di creare un account. L'app dovrebbe salvare tutte le tue ricerche precedenti nel nuovo account e dovresti essere in grado di accedervi da altri dispositivi.




• Un buon programma è progettato pensando agli scenari comportamentali degli utenti. Non devi solo aggiungere nuove funzionalità “così così”: mettiti nei panni dell’utente. Un giorno stavo prenotando i biglietti aerei e ho dimenticato di includere il mio numero frequent flyer. Dopo aver ricevuto la conferma, ho deciso di andare sul sito della compagnia aerea e aggiungerla per ottenere lo sconto. Per capire come farlo, ho girato il sito per 10 minuti buoni. L'applicazione era così discreta che ho semplicemente vagato senza meta tra le diverse pagine del sito per trovare ciò di cui avevo bisogno. Più tardi, ho scoperto di essere già atterrato sulla pagina giusta un paio di volte, ma non l'ho nemmeno capito, poiché il campo di cui avevo bisogno si era perso tra altri campi simili di forma enorme.

  Si è scoperto che per modificare le informazioni di viaggio era necessario scorrere una ventina di righe del modulo, inserire il numero della carta fedeltà e il numero di telefono, senza i quali il modulo non poteva essere inviato per la verifica. Questo è un esempio di un programma che è stato sviluppato senza pensare a quanto l'utente si sarebbe sentito a proprio agio con esso.

Affidabilità, sicurezza e protezione

A mio avviso, la differenza più importante tra uno sviluppatore di software professionista e uno amatoriale è tenere conto di parametri quali affidabilità, sicurezza e protezione dell'applicazione durante la sua creazione. Parti del programma devono essere tolleranti nei confronti di input errati, stati errati e interazioni errate. Questo è davvero molto difficile da applicare ed è il motivo principale per cui sentiamo storie di persone che muoiono a causa di bug del software. Gli utenti hanno inserito, stanno inserendo e continueranno ad inserire nel programma dati errati. Questo deve essere accettato come un dato di fatto. Inoltre, alcuni lo faranno apposta, con l'obiettivo di danneggiare l'applicazione e di impossessarsi delle risorse a sua disposizione. Ecco un esempio di vita reale: la persona presumibilmente responsabile della recente violazione dei dati di Equifax è accusata di non aver adempiuto alle sue responsabilità lavorative, che consistevano nello sviluppare soluzioni per resistere a input dannosi in tutti i prodotti software resi disponibili al pubblico. Gli incidenti legati alla sicurezza delle informazioni coinvolgono non solo input errati e dannosi, ma anche dati inseriti in modo errato. Se un utente ha dimenticato la password, quante volte può provare ad inserirla? Lo bloccherai dopo questo? Cosa succede se qualcun altro tenta di bloccare il suo account? Un utente può trasmettere le proprie credenziali su un canale dati non crittografato? Cosa succede se la richiesta di accesso proviene da una località insolita? Cosa farai se il tentativo di accesso sembra essere automatico? Che cosa hai fatto per proteggere i tuoi utenti dallo scripting cross-site, dalla falsificazione delle richieste cross-site e dal phishing comune? Hai una strategia di backup in caso di attacco DDoS ai tuoi server? Queste domande evidenziano solo alcune delle questioni che devono essere prese in considerazione. Il programma protetto non salva le informazioni importanti in formato testo. Lo protegge con una complessa cifratura unidirezionale (facile da crittografare ma quasi impossibile da decrittografare senza la chiave). Queste sono misure di backup nel caso in cui il programma venga violato. Gli hacker scopriranno dati crittografati che per loro sono inutili. Anche nei migliori programmi sorgono problemi imprevisti. Un programmatore che non è preparato al loro verificarsi difficilmente può essere definito un professionista. Finché non si aspetta un comportamento inaspettato, non è un ingegnere. È “l’autore di programmi non sicuri”. Gli errori nei programmi non sono sempre evidenti. La nostra capacità intellettuale di anticipare e prevenire errori noti è limitata. Questo è il motivo per cui gli ingegneri del software comprendono l'importanza di buoni strumenti che consentano loro di scrivere software corretto e sicuro.

Strumenti richiesti

Non c’è dubbio che abbiamo bisogno di strumenti di sviluppo diversi e validi. Il loro ruolo è spesso sottovalutato, ma in realtà fanno risparmiare molto tempo e fatica, semplificando alcuni compiti di un ordine di grandezza. Immagina se dovessi ancora caricare file tramite FTP per la distribuzione, per così dire, alla vecchia maniera. Immagina di eseguire il debug di problemi di rete e prestazioni senza Chrome DevTools! E quanto sarebbe inefficiente scrivere codice JavaScript senza ESlit e Prettier al giorno d'oggi! Qualsiasi strumento che riduca i tempi di feedback durante la scrittura del codice dovrebbe essere accolto favorevolmente. Quando trovo uno strumento che prima non mi era familiare, ma che è veramente utile ed efficace, posso solo rimpiangere di non averlo utilizzato prima di quel felice momento.

L'evoluzione dell'ingegneria del software

Nessuno può imparare l’ingegneria del software in due mesi, sei mesi o anche un anno. Non ti verrà insegnato come diventare un ingegnere del software in un corso, in un'università o in un campo di addestramento. Ho studiato negli ultimi venti e più anni e continuo a studiare anche adesso. Ho potuto tranquillamente definirmi un programmatore esperto solo dopo un decennio di apprendimento e sviluppo, creazione e manutenzione di applicazioni utilizzate da migliaia di utenti. L’ingegneria del software non è per tutti, ma tutti dovrebbero imparare a risolvere i propri problemi utilizzando un computer. Se puoi imparare a scrivere programmi semplici, dovresti. Se puoi imparare a utilizzare il software disponibile al pubblico, dovresti. Se puoi imparare a utilizzare il software open source e personalizzarlo per te stesso, hai un superpotere! Ogni giorno porta agli sviluppatori nuove sfide, nuovi problemi, motivo per cui è necessaria l'ingegneria del software. Il compito principale di questa professione è creare software in modo che una persona comune non debba affrontarlo per molti anni. In modo che non siano necessari lunghi studi per interagire con i programmi. Eppure, gli ingegneri del software pensano costantemente alla creazione di strumenti migliori in grado di risolvere problemi noti più complessi e fanno tutto il possibile per garantire che nuovi problemi appaiano il più raramente possibile.