Come iniziare a scrivere codice ‘complesso’

Questo è un post su come pensare al codice che scrivi. Tutto ciò che qui è contenuto è la mia opinione e dovresti sempre considerare la validità delle mie opinioni confrontandole con quelle migliori! La lingua che userò è Javascript. Un pre-requisito per comprendere questo articolo è conoscere Javascript intermedio e la familiarità con alcuni concetti orientati agli oggetti. Questo post è ispirato al capitolo 9 dell’eccellente libro di Cristina Lopes “Esercizi in stile di programmazione”.

Un modello molto comune nel codice è—

1. Definire un oggetto semplice

var store_item = {
name : 'wonderball'
}

2. Quindi per prepararlo per essere visualizzato su una pagina Web, eseguiamo ogni proprietà attraverso alcune funzioni.

addExclamationPoint(store_item);
capitalizeName(store_item);function addExclamationPoint(item) {
item.name = item.name + '!';
}function capitalizeName(item) {
// some code to capitalize item.name, cut out for brevity.
}

Ed è così che spesso prepariamo i dati per la visualizzazione. Ora che il nostro store_item ha un nome in maiuscolo e un punto esclamativo, possiamo visualizzarlo sulla nostra pagina web senza problemi. Se c’è una terza cosa che dobbiamo fare, scriveremo semplicemente una terza funzione per trasformare i dati e passare l’elemento come al solito.

Il modello di immagine più grande che abbiamo creato qui è:

Ci sono alcuni termini fantasiosi per questo tipo di programmazione come “procedurale” o “imperativo”, ma lo chiamerei un termine diverso: “semplice”. È una programmazione molto semplice. È il tipo di programmazione che tutti imparano per primi. Per i programmi di piccola scala, è assolutamente il modo migliore per programmare, perché gli esseri umani sono bravi a seguire ovunque da 1 a 10 passi logici abbastanza bene.

Quando il tuo programma diventa sufficientemente grande (oltre 10 trasformazioni prima che i dati vengano visualizzati), o una funzione sta modificando molti oggetti dati (più di 2), o abbiamo molte istruzioni IF che causano la logica di ramificazione, questa programmazione “semplice” diventa invece “un pasticcio”.

La maggior parte di ogni progetto o pezzo di codice diventa disordinata. La maggior parte della programmazione è in realtà i programmatori che escogitano modi per evitare di fare confusione, non soluzioni al problema reale della visualizzazione dei dati. Il lavoro di programmazione consiste nell’imparare a scrivere codice in modo tale da poter applicare 100 di trasformazioni su 100 di pezzi di dati e renderlo “non un disastro”.

Ora, lascia che ti presenti un grande cambiamento al modello sopra, e considera che quello che sto per mostrarti è il primo passo per diventare un codificatore più avanzato perché ti rompe dalla codifica “semplice”. Ti introduce a nuovi modi di pensare a come fare una cosa semplice come modificare alcuni dati per una pagina web. L’oggetto avrà ora la propria funzione chiamata ‘bind’ e tale funzione sarà responsabile della trasformazione dei dati.

var store_item = {
name: 'wonderball',
bind: function(func) {
this.name = func(this.name);
return this;
}
}// Here are two functions I'll use to transform the store_item.name, each one now just takes a name and modifies it, neither function has any clue what properties it's changing in store_item anymore.function capitalize(name) {
return name.replace(/\w\S*/g, function(txt) {
return txt.charAt(0).toUpperCase() +
txt.substr(1).toLowerCase();
});
}function addExclamationPoint(name) {
return name + '!';
}store_item.bind(addExclamationPoint).bind(capitalize);

Questa soluzione si comporta esattamente come il codice “semplice” originale sopra, ma sembra più complesso, perché? Perché per il semplice compito che abbiamo, è eccessivo, ma quali sono i compromessi di questa complessità?

Per rispondere, parliamo di cosa c’è di diverso:

1. Abbiamo questa folle, strana, funzione ‘bind’, che prende come argomento, non un nuovo valore per name, ma invece un’altra funzione, dì cosa ora?
2. le funzioni capitalize e addExclamationPoint sono diverse, ora non chiamano item.name direttamente più.
3. Non impostiamo più il nome con un’=’, usiamo invece questo strano store_item.bind (function_name), sintassi invece.

Con queste tre differenze, ora dobbiamo chiederci, questo cambiamento è migliore? Forse no se il progetto rimane così piccolo. Forse sì se il progetto diventa molto più grande.

La modifica chiave è che l’oggetto store_item è ora responsabile della gestione del suo stato tramite la funzione bind. Naturalmente, se si voleva, si potrebbe modificare direttamente store_item.name, ma l’oggetto sta praticamente urlando: “Hey, usi la mia funzione di bind per cambiarmi!”.

Ma ora è facile vedere un modello in cui più store_items gestiscono ciascuno il proprio stato con il proprio .funzione bind:

// Three store items, each one with a different state.store_item1.bind(addExclamationPoint).bind(capitalize); //Wonderball!store_item2.bind(capitalize);
//Wonderballstore_item3.bind(addExclamationPoint);
//wonderball!

Possiamo creare 100 store_item e gestire il loro stato abbastanza facilmente. Tutto quello che dobbiamo fare è scrivere una funzione che ha solo un valore di ritorno e usare il nostro oggetto .funzione bind.

La magia di questo modello è nella funzione bind, quindi esploriamo un po ‘ di più ora.

// 1. First define the function, and have it take as an argument another function. Taking a function as an argument, instead of data is the core change here. bind: function(func) { // 2. This second line is the secret sauce, it will run the function you passed in with 'this.name' as an argument, and then assign whatever value is returned to this.name. Mull this over. this.name = func(this.name);// 3. Finally, return 'this'. You don't have to have this step in here, but returning 'this' is what allows .bind chainging to happen (.e.g. doing .bind().bind() vs .bind(); .bind();) return this;
}

Quindi ce l’hai, abbiamo reso il nostro codice più complesso, ma ora abbiamo alcuni nuovi vantaggi:

1. Un oggetto ora modifica il proprio stato e può farlo in modo significativo in una sola riga.
2. Le funzioni che abbiamo scritto sono più pure, non modificano le proprietà degli oggetti come nell’esempio sopra, prendono solo un input e restituiscono un output.
3. Sappiamo che quando modifichiamo lo stato di un oggetto, le funzioni che usiamo probabilmente non modificheranno accidentalmente lo stato di nessun altro oggetto

Ma abbiamo anche alcuni aspetti negativi:

1. Il tuo codice è decisamente meno intuitivo per un nuovo arrivato ora.
2. Per un piccolo sito, questo codice è eccessivamente complesso.

Quindi qual è il giudizio finale, è meglio così? Peggio? Più confusione? (All’inizio, sì.) Tutte queste domande sono aperte, ma posso dire una cosa di sicuro, considerare e comprendere modelli come questo fa parte dell’apprendimento di Javascript e crescere come codificatore. Usare continuamente il modo “semplice” di codificare per risolvere i problemi diventa insostenibile dopo un po’. Se si prende il tempo per imparare modi più ‘complessi’ di fare le cose un sacco di grandi cose accadono: la vostra capacità di pensare lateralmente si apre, si può leggere più diversi tipi di codice, e si aumenta il modo in cui si può pensare di risolvere i problemi. Forse questo è il vero vantaggio di imparare questo e altri modelli.