I sistemi non falliscono perché sono male scritti; falliscono perché non riescono a tenere il passo con le esigenze complesse e in continua evoluzione di un'azienda. Quando ha parlato con Ignacio Brasca, che è un ingegnere software personale con diversi anni di esperienza nella costruzione di sistemi di dati complessi, ha sottolineato che il software si comporta molto come un sistema biologico - e che l'entropia coinvolta nel farlo crescere non può essere sottovalutata. Come le organizzazioni e i sistemi si evolvono insieme, gli sviluppatori devono pianificare il cambiamento a lungo termine fin dall'inizio. Ignacio spesso si riferisce all'idea di Donella Meadows che "non ci sono sistemi separati, il mondo è un continuum", sostenendo che i sistemi durano solo quando sono costruiti non solo per funzionare, ma per crescere. Determinismo delle tue azioni Sotto il presupposto che non si dipende da servizi che non si possono controllare, Brasca sostiene che il determinismo è uno degli elementi più importanti di un sistema efficace. 
 
 Se sai cosa cambierai e cosa provocerà quel cambiamento, puoi costruire un sistema che durerà per sempre. Se sai cosa cambierai e cosa provocerà quel cambiamento, puoi costruire un sistema che durerà per sempre. Questa chiarezza è spesso ciò che impedisce l'astrazione inutile, la flessibilità prematura e l'eccessiva ingegneria.Per Brasca, il determinismo non riguarda la rigidità; si tratta di avere una solida base che promuove la crescita senza perdere di vista ciò che ha reso il tuo sistema funzionare bene in primo luogo. Flessibilità vs. super-ingegneria La flessibilità è un'altra area che deve essere affrontata con attenzione. Ignacio ritiene che, nelle aziende reali, la flessibilità diventi costosa quando viene perseguita senza una chiara comprensione di quali esigenze reali sorgeranno nel tempo. “La parola Ci fa pensare a complessità inutili”, spiega, “ma a volte è il contrario. prendi l’approccio sbagliato alle restrizioni iniziali e finisci con qualcosa che è semplice, robusto e ancora non funzionale”. Ingegneria eccessiva Brasca si basa su un quadro semplice: “fai funzionare, fai bene, fai veloce”. provare che un sistema risolve un problema reale viene prima. In definitiva, la flessibilità vale il suo costo solo quando si allinea con il modo in cui si prevede che il sistema si evolva.L'eccesso di ingegneria si verifica quando i team progettano per futuri immaginati invece di cambiamenti osservabili, aggiungendo complessità senza migliorare la chiarezza o il controllo. La sostenibilità in pratica Risolvere i vincoli aziendali in teoria è una cosa; quando la teoria incontra la pratica, le cose possono svanire rapidamente. “Ecco la cosa: sbagliare è l’unica parte dell’ingegneria del software che ha davvero senso.Non si scrive mai un programma supponendo che tutto andrà bene. Oggi, con l'aiuto dell'IA, la scrittura di codice è diventata relativamente facile.La parte difficile è mantenere una base di codice pulita, solida e comprensibile mantenendo traccia di tutti i cambiamenti in un'architettura orizzontale che consente di seguire quando qualcosa va storto. Avere ragione, dice Ignacio, è ciò che separa i sistemi che sopravvivono da quelli che lentamente crollano. Tooling, DX e il cambiamento di sopravvivenza Ottenere il codice giusto è solo il primo passo del processo. Per scalare, gli strumenti e l'esperienza dello sviluppatore svolgono un ruolo critico nel sapere se un sistema sopravvive alla crescita, al cambiamento e al fatturato del personale. Egli osserva che gli ingegneri tendono ad essere incredibilmente appassionati dei loro strumenti e dell'artigianato; a volte, tentare di sovra-ottimizzare tutto può diventare un problema. 
 
 Una decisione che ha ridotto in modo significativo l'attrito a lungo termine per i suoi team è stato l'investimento precoce in pipeline CI/CD. Mentre spesso sottovalutate, le guardiane forti creano fiducia. Una decisione che ha ridotto in modo significativo l'attrito a lungo termine per i suoi team è stato l'investimento precoce in pipeline CI/CD. Mentre spesso sottovalutate, le guardiane forti creano fiducia. In questo senso, lo strumento diventa un'estensione della filosofia del sistema. rafforza il determinismo, limita la complessità inutile e assicura che la crescita non venga a spese della affidabilità. Conclusione: costruire per il cambiamento, non per la permanenza Dopo questa conversazione con Ignacio, ho capito che i sistemi non durano perché sono intelligenti o perfetti; durano perché sono progettati con il cambiamento in mente. L'obiettivo, quindi, non è quello di prevedere il futuro perfettamente, ma di allineare i sistemi il più possibile con i problemi che sono destinati a risolvere oggi, lasciando spazio per adattarsi domani. E in un settore ossessionato da velocità, novità e scala, progettare sistemi che possono essere compresi, mantenuti e evoluti può essere il vantaggio competitivo più duraturo di tutti. 
 
 Questa storia è stata distribuita come un rilascio da Jon Stojan nell'ambito di HackerNoon's Business Blogging Program. This story was distributed as a release by Jon Stojan under  . HackerNoon’s Business Blogging Program Il programma di blogging aziendale di HackerNoon Il programma di blogging aziendale di HackerNoon

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Questo audio è prodotto nella lingua originale della storia!

Ignacio Brasca su sistemi di costruzione che durano

About Author

COMMENTI

CARTELLINI

QUESTO ARTICOLO È STATO PRESENTATO IN

Related Stories

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

The Ultimate FAQ Guide to HackerNoon's Business Blogging

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

HackerNoon - A User Experience Analysis: Part 2

Meet the HackerNoon Top Writers: Nebojsa Nesha Todorovic - Upwork, Freelancing, and Future of Work

The Ultimate FAQ Guide to HackerNoon's Business Blogging

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

HackerNoon - A User Experience Analysis: Part 2

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps