I più strani principi di programmazione di cui non hai mai sentito parlare

Ti abbiamo già illustrato i principi di programmazione più essenziali 10 Principi di programmazione di base Ogni programmatore deve seguire 10 Principi di programmazione di base Ogni programmatore deve seguire Scrivi sempre il codice che può essere gestito da chiunque possa finire a lavorare sul tuo software. A tal fine, qui ci sono diversi principi di programmazione per aiutarti a ripulire il tuo atto. Per saperne di più è necessario conoscere, ma c'è un'altra classe di principi di programmazione che può dimostrare ancora più vantaggioso di quelli.

Mentre i principi sopra menzionati ti insegnano come essere inteligente con il tuo codice, i seguenti principi ti insegneranno ad essere saggio con il tuo codice. Alcuni di loro sono strani e molti di loro sono divertenti, ma sono tutti ugualmente pratici e importanti. Badate!

1. Il principio Bloat

Questo ha così tante varianti che è difficile sceglierne uno come principale. Forse il più “ufficiale” la versione è la legge dell'involucro del software, più comunemente chiamata La legge di Zawinski, prende il nome da Jamie Zawinski e menzionato in L'arte della programmazione UNIX:

“Ogni programma tenta di espandersi fino a quando non può leggere la posta. Quei programmi che non possono espandersi sono sostituiti da quelli che possono.”

Sta parlando della tendenza dei programmi ad attrarre sempre più caratteristiche nel tempo e inevitabilmente alla deriva verso una crescente complessità. Potresti sapere questo come caratteristica creep, che è l'aggiunta continua di nuove funzionalità che non hanno nulla a che fare con lo scopo principale del programma. Lo scorrimento viscoso porta a ingrossarsi e il rigonfiamento è spesso indesiderabile.

Questo può valere anche per le prestazioni del software:

“Il software si espande per consumare tutte le risorse disponibili.”

Negli anni '90, i dischi rigidi, le CPU e la RAM erano molto più restrittivi di oggi e i programmatori lavoravano duramente per adattarsi il più possibile ai limiti. Eppure ora che abbiamo dischi più grandi e CPU più veloci e più RAM, facciamo ancora fatica a rispettare i limiti. Tutto diventa gonfio nel tempo. È tuo compito tenerlo sotto controllo.

2. Il “Peggio è meglio” Mentalità

Quasi come se in risposta al principio Bloat, abbiamo il Peggiore è migliore mentalità, prima coniato da Richard P. Gabriel in un saggio che ha scritto sulla qualità del software:

“Il software che è limitato, ma semplice da usare, può essere più attraente per l'utente e il mercato rispetto al contrario.”

In altre parole, è saggio capire il un problema il tuo software ha lo scopo di risolvere e quindi essere molto buona a quell'unica cosa Mantienilo semplice. Più ti dividi sottile, più diventa ingestibile il progetto e più diventa indesiderabile per gli utenti.

Cosa succede quando ignori questo? Finisci con il Software Principio di Peter:

“Un progetto troppo complesso finirà per diventare troppo complesso per essere compreso anche dai suoi stessi sviluppatori.”

Viene dal più ampio Peter Principle, che afferma che quando i dipendenti vengono promossi sulla base della loro attuale competenza e non della loro competenza attesa nella loro posizione successiva, tutti i dipendenti alla fine finiscono in una posizione di incompetenza. Prendi questo principio e applicalo al software, e vedrai perché il software peggiore può spesso essere migliore.

3. Legge di Eagleson

“Qualsiasi codice personale che non hai guardato per sei o più mesi potrebbe essere stato scritto da qualcun altro.”

Questo detto apparentemente demotivazionale è in realtà qualcosa da abbracciare. Il fatto è che nessuno è perfetto. Potresti pensare di essere un programmatore geniale in questo momento, ma c'è sempre Qualcosa in più che puoi imparare, sempre più spazio per crescere. Se si guarda indietro sul vecchio codice e rabbrividire, probabilmente significa hai imparato qualcosa di nuovo da allora.

Detto in altro modo: se guardi indietro a un vecchio progetto e non riesci a vedere nulla che puoi migliorare o farebbe diversamente la prossima volta, probabilmente sei stagnante come programmatore.

4. Principio di minima stordimento

“Se una caratteristica necessaria ha un alto fattore di stupore, potrebbe essere necessario riprogettare la funzione.”

Pubblicato per la prima volta nel IBM Systems Journal già nel 1984, questo principio è ancora sorprendentemente attuale oggi, forse più che mai.

Tocca essenzialmente sul delicato equilibrio tra innovazione e familiarità: se un software è troppo diverso da altri nel suo genere e non è conforme alle aspettative dell'utente, quindi probabilmente non lo adotteranno. È meglio puntare a miglioramenti incrementali che sono abbastanza grandi per essere impressionanti ma abbastanza piccoli da rimanere familiari.

5. Legge dell'entomologia cibernetica

“C'è sempre un altro bug.”

Chiamato spesso Legge di Lubarsky sull'entomologia cibernetica, non è chiaro chi sia in realtà questo Lubarsky. Tuttavia, il suo principio suona vero per tutti i programmatori: non importa quanto scriva il tuo codice in modo pulito, indipendentemente dal modo con cui testerai i tuoi moduli, non importa quanto spesso si refactoring le classi, ci sarà sempre un altro bug.

In un certo senso, questo è un principio di liberazione. Mentre dovremmo sicuramente lottare per il codice privo di bug, è anche importante ricordare che il perfezionismo è il nemico del bene. Cerca bug, correggili quando si presentano e poi vai avanti.

6. La legge di Kernighan

“Il debugging è due volte più duro rispetto alla scrittura del codice, in primo luogo. Pertanto, se si scrive il codice nel modo più intelligente possibile, per definizione non si è abbastanza intelligenti da eseguirne il debug.”

Brian Kernighan, lo stesso che è stato coautore della bibbia del linguaggio di programmazione C Perché la programmazione C vale ancora l'apprendimento Perché la programmazione C vale ancora l'apprendimento C non è una lingua morta. In effetti, la rivista IEEE Spectrum l'ha classificata come seconda lingua nel 2017. Ecco cinque ragioni per cui. Per saperne di più, è famosa per questa legge perspicace. Il punto cruciale è questo: scrivere bene codice, scrivere leggibile codice, scrivere semplice codice, qualsiasi cosa finchè non lo è intelligente codice.

Cercando di flettere i tuoi muscoli di programmazione con la complessità della torre d'avorio è l'esatto opposto di ciò che significa scrivere codice pulito e migliore 10 Suggerimenti per scrivere Cleaner & Better Codice 10 Suggerimenti per scrivere Cleaner e Better Code Scrittura di codice pulito sembra più facile di quanto sia in realtà, ma i benefici valgono la pena. Ecco come iniziare a scrivere codice più pulito oggi. Leggi di più . Più il tuo codice è difficile da comprendere, più difficile sarà eseguire il debug quando inevitabilmente si interrompe.

E come spiega Robert C. Martin, non si tratta solo di debugging:

“In effetti, il rapporto tra tempo di lettura e scrittura è ben oltre il 10 a 1. Stiamo leggendo costantemente il vecchio codice come parte dello sforzo di scrivere un nuovo codice ... [Pertanto,] renderlo facile da leggere rende più facile scrivere.”

7. Debug di gomma dell'anatra

Questo non è tanto un principio quanto una tecnica, ma è così utile e strano che saremmo negligenti a lasciarlo fuori.

Prima raccontato in Il programmatore pragmatico, debug di anatra di gomma è quando si esegue il debug del software rotto spiegando il codice a un oggetto inanimato (ad esempio un'anatra di gomma) una riga alla volta. Funziona perché l'atto di spiegazione innesca diverse parti del tuo cervello, e hai maggiori probabilità di individuare le incoerenze e capire dove sei andato storto.

Per questo motivo, un'anatra di gomma può essere un regalo sorprendentemente elegante per i programmatori. I migliori regali per programmatori: 20 idee per programmatori e nerd. I migliori regali per programmatori: 20 idee per programmatori e nerd. Cerchi un regalo per un programmatore? Ecco i migliori regali geek, che vanno dalle tastiere meccaniche alle scrivanie in piedi e altro ancora. Leggi di più, sia che tu lo compri per te stesso o per un tuo amico programmatore.

8. La regola del novanta-novanta

“Il primo 90 percento del codice rappresenta il primo 90 percento del tempo di sviluppo. Il restante 10 percento del codice rappresenta l'altro 90 percento del tempo di sviluppo.”

Questo piccolo proverbio impertinente di Tom Cargill arriva al cuore del perché la programmazione possa essere così frustrante: non importa quanto tu pensi di essere finito, sei vicino molto più lontano anche le tue migliori stime. Quando pensi di aver finito, sei solo a metà strada.

Va di pari passo con la legge di Hofstadter:

“Ci vuole sempre più tempo del previsto, anche se si tiene conto della legge di Hofstadter.”

9. Legge di Parkinson

“Il lavoro si espande in modo da riempire il tempo disponibile per il suo completamento.”

Questo unico principio, coniato da Cyril Northcote Parkinson, è un principio più ampio che si applica in modo assoluto alla programmazione e va di pari passo con la regola delle novanta-novanta sopra riportata: per quanto tempo si debba finire un progetto è esattamente quanto tempo ci vorrà. Nello sviluppo del software, “finendo presto” è praticamente un mito.

La legge di Parkinson è la ragione per cui le scadenze corrette sono fondamentali se si vuole finire e spedire il software. Ecco perché i programmatori professionisti moderni spesso raccomandano principi di gestione del progetto agili Come utilizzare i principi di gestione agile del progetto per organizzare la tua vita Come utilizzare i principi di gestione del progetto Agile per organizzare la tua vita Agile, meglio conosciuto come un metodo di gestione del progetto, è un ottimo framework per la gestione del tuo vita privata. Ti mostreremo quali principi puoi prendere in prestito: download gratuito del foglio di lavoro incluso! Ulteriori informazioni e strumenti di gestione del progetto come Asana Trello vs. Asana: il miglior strumento gratuito per la gestione dei progetti è ... Trello vs. Asana: il miglior strumento gratuito per la gestione dei progetti è ... Scegliere tra Trello e Asana è difficile. Qui confrontiamo i piani gratuiti e ti aiutiamo a decidere quale strumento di gestione del progetto è meglio per il tuo team. Leggi di più .

10. Legge di Brook

“L'aggiunta di manodopera a un progetto software tardivo lo rende più tardi.”

La prossima volta che sei in ritardo su un progetto, che è probabile dal momento che la maggior parte dei progetti di programmazione richiede più tempo del previsto, ricorda che l'aggiunta di codificatori non la risolverà più velocemente.

In effetti, probabilmente ci vorrà più a lungo completare. Non solo è necessario portare il nuovo codificatore (s) in modo veloce, probabilmente si scontreranno con i codificatori esistenti. Più cose dovranno essere documentate, più burocrazia sarà necessaria per tenere tutti sulla stessa pagina e più frizione uscirà dall'intera esperienza crunch-time.

Andando avanti come programmatore

Ora che conosci questi principi, in realtà sei più adatto per il mondo reale di programmazione, non solo quello che hai incontrato a scuola, in un corso web o in un bootcamp. Questi principi derivano da anni e anni di esperienza e fallimenti.

Con questa nuova saggezza, è ora possibile intraprendere una carriera di programmazione ad alta richiesta 10 Lavori di programmazione informatica che sono richiesti in questo momento 10 Lavori di programmazione computerizzati che sono richiesti in questo momento Poiché l'atterraggio di un lavoro di programmazione può essere difficile nel panorama attuale, considera di concentrarti su una delle seguenti concentrazioni per migliorare le tue possibilità di successo. Leggi di più con aspettative più realistiche. Per questo, scopri come massimizzare le tue opportunità di carriera di programmazione Come migliorare la tua programmazione Opportunità di carriera Come migliorare la tua carriera Opportunità di carriera Se speri di iniziare, riavviare o migliorare la tua carriera di programmazione, non è facile. Se sei al college, il tempo è ora. Ecco alcuni suggerimenti che possono portarti lontano. Leggi di più . E se decidi che la programmazione non fa per te, non preoccuparti - considera uno di questi lavori tecnologici non codificanti invece Coding Is not For Everyone: 7 Lavori Tech che puoi ottenere senza Codificare non è per tutti: 7 Lavori tecnologici che puoi ottenere senza di esso Non scoraggiarti se vuoi far parte del settore tecnologico - ci sono molti posti di lavoro per le persone che non sanno come codificare! Leggi di più .

Quale di questi principi ti suona più vero? Conoscere altri principi di programmazione bizzarri che ci siamo persi? Fateci sapere nei commenti qui sotto!