Il buon codice è impossibile nel moderno sviluppo del software? [chiuso]

Come affermato da DeMarco e Lister in Peopleware circa 20 anni fa, la stragrande maggioranza di progetti software falliti non falliscono a causa di problemi tecnici, ma problemi sociologici . Questo non è cambiato negli ultimi decenni, indipendentemente da quanto siano migliorati i nostri strumenti.

Cattiva gestione, aspettative non realistiche, incapacità di ottenere le persone giuste per il lavoro e / o non lasciare che facciano il loro lavoro, di conseguenza non riuscendo a mantenerle; luoghi di lavoro e strumenti che non sono adatti per il lavoro di sviluppo di SW; conflitti personali non gestiti; Politica ; questi sono solo alcuni dei problemi tipici che possono rendere un progetto condannato fin dall'inizio.

Why writing good code is harder?

Non sono abbastanza convinto che sia davvero più difficile scrivere un buon codice ora di quanto lo fosse decenni fa. Infatti, rispetto al codice macchina o all'assemblaggio, tutto ciò che abbiamo ora nel mainstream è molto più facile da gestire. Potremmo aver bisogno di produrne di più.

Is it only because of the mention factors, time and complexity?

Sì, la complessità ottenibile è certamente aumentata (e continua ad aumentare) man mano che aumenta la potenza dei nostri strumenti. In altre parole, continuiamo a spingere i limiti. Che per me si traduce in modo che sia altrettanto difficile risolvere le più grandi sfide di oggi come lo era 30 anni fa per risolvere le più grandi sfide di quel giorno.

OTOH dal momento che il campo è cresciuto così enormemente, ora ci sono molti più problemi "piccoli" o "noti" rispetto a 30 anni fa. Questi problemi tecnicamente (non dovrebbero) essere (essere) una sfida più, ma ... qui entra la massima sopra: - (

Anche il numero di programmatori è cresciuto enormemente. E almeno la mia percezione personale è che il livello medio di esperienza e conoscenza è diminuito, semplicemente perché ci sono molti più giovani che arrivano continuamente sul campo di quanti siano gli anziani che potrebbero educarli.

Is it that methodologies are not practiced correctly?

IMHO certamente no. DeMarco e Lister hanno alcune parole dure sulle metodologie big-M. Dicono che nessuna metodologia può far riuscire un progetto - solo le persone nel team possono farlo. OTOH le metodologie small-m che elogiano sono abbastanza vicine a quelle che ora conosciamo come "agili", che si sta diffondendo ampiamente (IMHO per una buona ragione). Per non parlare di queste buone pratiche come test unitari e refactoring, che solo 10 anni fa non erano ampiamente conosciuti, e al giorno d'oggi anche molti neolaureati lo sanno.

I problemi legati alla codifica in termini irrealistici e alla gestione del debito tecnico sono noti da Weinberg '71 e anche da Brooks '72. La letteratura diventa difficile da scavare online prima, ma sono abbastanza sicuro che ci sono vecchi rapporti su CDC, IBM e NASA che dicono la stessa cosa.

Penso che tutti abbiamo le nostre idee e le nostre soglie per "Good Code". Tuttavia, ci sono una serie di problemi che tutti contribuiscono:

• errata applicazione "farlo funzionare allora migliorarlo" per indicare lasciamo codice morto e 10 diverse varianti dello stesso metodo in cui ciascuno è usata solo una volta nella base di codice. Questa roba non sembra mai essere ripulita.
• Mancanza di tempo e budget. Cliente vuole 100 nuove funzionalità in 3 mesi, alcuni di loro non banale, e non vogliono spendere soldi per cose che non possono vedere direttamente.
• Mancanza di cura. Ammettiamolo, alcuni sviluppatori si preoccupano del modo in cui il codice appare e si comporta più di altri. Vedi il primo punto elenco per un esempio.
• Non sappiamo davvero come creare "codice buono". Il mio concetto di buon codice è in continua evoluzione. Quello che pensavo fosse buono un decennio fa non è più così buono.
• "Buono codice" è un giudizio di valore. Oltre a "funziona", e non ci sono bug noti, qualsiasi altro criterio per un buon codice è essenzialmente una questione di opinione.

Alla fine, penso che sia meglio perseguire meglio che perseguire il "bene" o il "meglio". Se vedessimo il miglior codice là fuori, lo riconosceremo come tale?

Perché scrivere un buon codice è più difficile?

Perché il software viene sempre più costruito su livelli di astrazione. Ogni nuova tecnologia che pretende di rendere lo sviluppo più semplice e veloce aggiunge solo un ulteriore livello di complessità che uno sviluppatore deve comprendere. Ora, queste astrazioni possono avere enormi benefici sulla produttività, ma se non capisci cosa stanno cercando di nascondere, rende il software più suscettibile agli errori e alla scarsa qualità.

Is good code impossible in modern software development?

In effetti, non è possibile. Ma non per nessuno dei motivi che hai già sentito.

Lo scopo della maggior parte dei progetti è ben oltre la capacità di un cervello umano. Ecco perché le persone hanno escogitato l'idea di astrazione , cioè di tenere nascosti i dettagli e di salire più in alto l'albero di astrazione fino a quando la densità dei rami (quantità di informazioni da gestire) diminuisce a un ritmo accettabile. / p>

L'abbiamo fatto, abbiamo risolto il problema di complessità, ma questo non ha rimosso il problema più grande che avevamo prima.

È ancora troppo complesso da gestire.

Per creare una soluzione di alta qualità dobbiamo essere in grado di vedere e comprendere simultaneamente tutto allo stesso tempo, cioè tutti i moduli in un grande e tutti i piccoli dettagli di implementazione. Tutto in una volta per vedere le discrepanze, vedere ogni pezzo di codice nel contesto di tutti gli scenari possibili e ottimizzare l'intera base di codice allo stesso tempo.

Non saremo mai in grado di farlo.

E se non possiamo non produrremo mai un codice di qualità.

I manager vedranno l'infarinatura dei moduli ma non conosceranno problemi interni e limitazioni per modulo.

I programmatori di moduli conosceranno i limiti locali ma non saranno in grado di ottimizzarli nel contesto di un'immagine più grande.

Non c'è modo di comunicare la comprensione tra manager e programmatori (e anche tra programmatori). E anche se ci fosse, la capacità del cervello umano non potrebbe gestirlo.

C'è poco che possiamo fare se non continuare a provare (un esercizio inutile). Manteniamo il codice più o meno operativo e ci godiamo la vita.

Rifiuto la premessa della tua domanda. È più facile che mai scrivere un buon codice, e per questo affrontiamo i problemi molto più difficili che abbiamo già affrontato.

Non voglio scegliere un particolare fornitore, ma paragonare Windows 1.0 a Windows 7. Quest'ultimo contiene migliaia di volte più codice, ma il tempo medio tra gli arresti è aumentato di cento volte. Dovremmo essere in grado di incorporare un foglio di calcolo Excel in un documento Word da Windows 3.1, ma in questi giorni in realtà funziona più o meno.

Senza voler cadere nel sentimentalismo "Voi ragazzi di questi tempi con la battitura a macchina e la VM", suggerirei di non avere idea di quanto fosse difficile scrivere un buon codice negli anni '80: PICCOLO, PICCOLO e ENORME memoria modelli, sovrapposizioni, chiamate del sistema operativo non-urgenti (brivido). Buona liberazione a tutto ciò.

Le moderne applicazioni sono più complesse di quanto non fossero 20-30 anni fa, perché il loro ambiente è più ricco e versatile.

Era tipico che un programma DOS si inserisse in un ciclo stretto in attesa della pressione del tasto successivo da parte dell'utente, quindi richiamava il codice corrispondente e tornava ad aspettare il prossimo tasto premuto.

Qualsiasi applicazione moderna in cui non è possibile utilizzare il mouse su ALL per qualsiasi cosa, ha un serio problema di spiegazione. E le cose possono accadere in qualsiasi ordine, poiché è perfettamente possibile per l'utente digitare, fare clic con il mouse e continuare a digitare mentre i feed RSS vengono aggiornati nell'applicazione mostrando le voci più recenti all'utente mentre digita.

Tutte queste cose multi-tasking sono intrinsecamente molto più complesse di quando tutto ciò a cui dovevi pensare erano le chiavi dell'utente. Ciò rende più difficile scrivere codice veramente buono.

Speriamo che quando i ricercatori avranno capito come rendere più fruibili i programmi multi-tasking visti dal punto di vista degli sviluppatori, questo potrebbe allentarsi ma per ora siamo bloccati da tutti quelli che cercano di farlo bene, ma non del tutto consapevoli come farlo.

Mi sembra che il software si sia espanso per riempire la velocità disponibile del processore, la memoria, il disco e il tempo del programmatore. Si potrebbe affermare che ciò è dovuto al fatto che il software realizza molto di più. Beh, sono sicuro che lo fa molto di più, ma non abbastanza da giustificare il gonfiarsi.

Penso che ci sia un'antica legge della scienza che vale la pena ricordare:

Nature abhors a vacuum.

Francois Rabelas (monaco francese e satirico 1494-1553)

In effetti, penso che sia diventato più facile scrivere un buon codice, cioè programmi che funzionano come previsto e sono mantenibili negli ultimi dieci anni. Gli strumenti disponibili sono migliori ora, le librerie sono più mature e complete, l'hardware è diventato molto più veloce, quindi non dobbiamo usare trucchi di ottimizzazione.

Allora, perché no?

IMO il motivo principale è che cerchiamo costantemente modi e scuse per abusare delle cose. Invece di andare alla vecchia maniera, facile, probabilmente noiosa, come creare un eseguibile di Windows, spingiamo i confini del possibile e cerchiamo modi per es. ricreare qualcosa come PhotoShop come applicazione web. Perché? Perchè noi possiamo. O almeno lo pensiamo così.

Quand'è stata l'ultima volta che qualcuno non ha scritto un exploit o studiato per farlo, ha perso tempo con il montaggio (senza contare gli hacker del kernel e i ragazzi di ASIC)? Quanti bug sono stati scoperti nelle librerie core C? Quasi nessuno e pochi. Tutto quello che sto dicendo è che le persone sono capaci di un codice eccellente. Strumenti e linguaggi migliori lo rendono meno "richiesto" e più "opzionale". Non penso che dovremmo scrivere codice davvero terribile, ma quando penso a complicati costrutti logici ... nessuno avrebbe mai sognato di scrivere qualcosa con gli hash array in assemblea. Doveva esserci un modo "migliore" per gestire la logica invece di usare un costrutto complicato. Anche se il codice è bello, a volte l'approccio non è elegante. Penso che risolva il problema che hai menzionato. Il buon codice non è sempre organizzato, a volte l'approccio alla logica è ancora più bello.

Penso che sia perché strumenti migliori, e computer più veloci e reattivi significano che ci aspettiamo di ottenere molto più tempo per unità di tempo per la produzione finale di quanto non avessimo fatto qualche anno (o qualche decennio). Quindi la complessità delle app continua ad aumentare e le nostre ipotesi su ciò che continua a crescere è un ragionevole livello di produttività.

Dove lavoro, gli sviluppatori sono sempre di fretta (perché ci sono sempre più cose che i clienti vorrebbero, quindi hanno tempo per). Quindi molti blocchi di codice vengono copiati con modifiche minime e senza lo sforzo necessario per capirli veramente. E naturalmente gli errori vengono fatti. Ho appena visto un bug riparato, in cui uno sviluppatore aveva copiato un codice che avevo ottimizzato, senza rendermi conto che le ipotesi che hanno reso l'ottimizzazione valida non erano vere dove lo stava mettendo.

Tutto ciò si riduce alle aspettative, sia interne (le nostre aspettative), sia delle nostre organizzazioni. Cerchiamo di fare il più possibile nel più breve tempo possibile. E gli errori inevitabilmente risultano.

Anche la reattività del computer incoraggia una rapida modifica rapida, quindi una compilazione e una prova di esecuzione. Nei vecchi tempi (come 35 anni fa), il turnaround era così lento, che avrei stampato il codice (la fonte era allora le schede perforate), e ho fatto un passo avanti manuale del codice prima di inviare il mio mazzo. Ora, modifichiamo semplicemente compilazione ed esecuzione. Quindi un sacco di bug che avremmo individuato, attraverso la metodica procedura dettagliata del codice, ora contiamo sul compilatore e / o sulla suite di test delle unità da catturare.

In che modo le persone hanno peggiorato la produzione di un buon codice?

Se prendi .NET e un linguaggio come C #, ad esempio (e mi rendo conto che non è l'unica piattaforma / lingua), direi che codificare bene è diventato molto, molto più facile a causa all'automazione di molte cose all'interno dell'ambiente di Visual Studio.

Se non altro, il semplice fatto che ora abbiamo IDE molto sofisticati in grado di guidarci attraverso il processo di codifica e sviluppo sta rendendo il "buon codice" più facile da ottenere.

I programmatori ora possono concentrarsi sulla produzione di una buona struttura invece di spendere così tanto tempo semplicemente digitando parentesi e parentesi e nuove linee e ricordando le chiamate ai metodi e i nomi delle classi.

I miei due centesimi.

Sì, noi come industria non stiamo praticando ciò che è noto per essere buone metodologie. Riferimento: Construx Software di Steve McConnell Frutta a bassa sospensione dello sviluppo software .

quality of code haven’t got better

please don’t get stuck in the interpretation of “good code”

Grande tautologia logica.

Il codice non migliora perché le persone continuano a spostare la definizione di "buono".

Se puoi "discutere" un buon codice ", non puoi confrontare e davvero non puoi decidere se è" una sfida "o meno.