Il buon codice è impossibile nello sviluppo di software moderno? [chiuso]

Sembra che anche gli strumenti per sviluppatori siano diventati più solidi e robusti, scrivere un buon codice è diventato una sfida. Anche se gli strumenti sono più potenti, la qualità del codice non è migliorata. Mi vengono in mente due fattori importanti, c'è meno tempo e i progetti sono più complessi. Poiché gli strumenti che utilizziamo oggi sono più potenti, è più facile scrivere codice più complesso, ma non avere tempo per pianificare e senza guardare indietro riduce la qualità del codice e aumenta bug e manutenzione. Non è che non abbiamo scritto codice complesso prima. È che scriviamo un codice più complesso.

La mia domanda è la seguente: considerando che abbiamo un linguaggio e strumenti più potenti.

• Perché scrivere un buon codice è più difficile?
• Fattori, tempo e complessità contribuiscono a questo?
• Le metodologie non sono praticate correttamente?

Il tipo di progetto che considero è un'applicazione enterprise con grande complessità e logica aziendale. La definizione di "buon codice" è individuale, per favore non rimanere bloccato nell'interpretazione di "buon codice".

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

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

Perché scrivere un buon codice è più difficile?

Non sono del tutto convinto che sia davvero più difficile scrivere un buon codice ora rispetto a decenni fa. In effetti, rispetto al codice macchina o all'assemblaggio, tutto ciò che abbiamo ora nel mainstream è molto più facile da gestire. Solo potremmo aver bisogno di produrne di più.

È solo a causa dei fattori di menzione, tempo e complessità?

Sì, la complessità raggiungibile è certamente aumentata (e continua ad aumentare) all'aumentare della potenza dei nostri strumenti. In altre parole, continuiamo a spingere i confini. Il 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 da quando il campo è cresciuto così enormemente, ora ci sono molti più "piccoli" o "noti" problemi rispetto a 30 anni fa. Questi problemi tecnicamente non dovrebbero (essere) più una sfida, ma ... qui entra nella massima di cui 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.

Le metodologie non sono praticate correttamente?

IMHO certamente no. DeMarco e Lister hanno alcune dure parole sulle metodologie big-M. Dicono che nessuna metodologia può far funzionare un progetto, solo le persone del team possono farlo. OTOH le metodologie di piccole dimensioni che elogiano sono abbastanza vicine a ciò che ora conosciamo come "agile", che si sta diffondendo ampiamente (IMHO per una buona ragione). Per non parlare di buone pratiche come i test unitari e il refactoring, che solo 10 anni fa non erano ampiamente conosciuti, e oggigiorno anche molti laureati lo sanno.

Questioni relative alla codifica in tempi non realistici e alla gestione del debito tecnico sono note sin da Weinberg '71 e Brooks '72. La letteratura diventa difficile da approfondire online prima di quello, ma sono abbastanza sicuro che ci sono vecchi rapporti CDC, IBM e NASA che dicono la stessa cosa.

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

• L'applicazione errata di "farlo funzionare e poi migliorarlo" significa che lasciamo codice morto e 10 diverse varianti dello stesso metodo in cui ognuno viene utilizzato solo una volta nella base di codice. Questa roba non sembra mai essere ripulita.
• Mancanza di tempo e budget. Il cliente desidera 100 nuove funzionalità in 3 mesi, alcune delle quali non banali, e non vogliono spendere soldi per cose che non possono vedere direttamente.
• Mancanza di cura. Ammettiamolo, alcuni sviluppatori si preoccupano dell'aspetto e del comportamento del codice più di altri. Vedi il primo punto elenco per un esempio.
• Non sappiamo davvero come creare un "buon codice". Il mio concetto di buon codice è in continua evoluzione. Quello che pensavo fosse buono dieci anni fa non lo è più.
• "Good code" è 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 "buono" o "migliore". Se vedessimo il miglior codice là fuori, lo riconosceremmo come tale?

Perché scrivere un buon codice è più difficile?

Perché il software viene sempre più costruito sopra i livelli di astrazione. Ogni nuova tecnologia che afferma di rendere lo sviluppo più semplice e veloce aggiunge solo un ulteriore livello di complessità che uno sviluppatore deve comprendere. Ora, questa astrazione può avere enormi benefici per la produttività, ma se non capisci cosa stanno cercando di nascondere, rende il software più suscettibile a bug e scarsa qualità.

Il buon codice è impossibile nello sviluppo di software moderno?

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

La portata della stragrande maggioranza dei progetti va ben oltre la capacità di un cervello umano. Questo è il motivo per cui le persone hanno avuto l'idea dell'astrazione , ovvero nascondere i dettagli e scalare più in alto l'albero di astrazione fino a quando la densità dei rami (quantità di informazioni da gestire) diminuisce a un tasso accettabile.

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

È ancora troppo complesso per noi da gestire.

Per creare una soluzione di alta qualità dobbiamo essere in grado di vedere e comprendere simultaneamente tutto allo stesso tempo, ovvero tutti i moduli in modo dettagliato e con 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 allo stesso tempo l'intera base di codice.

Non saremo mai in grado di farlo.

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

I gestori vedranno l'influenza dei moduli ma non conosceranno i problemi interni e le limitazioni per modulo.

I programmatori del modulo conosceranno i limiti locali ma non saranno in grado di ottimizzarli nel contesto di un quadro più ampio.

Non c'è modo di comunicare la comprensione tra manager e programmatori (e persino 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 godiamoci la vita.

Nego la premessa della tua domanda. Scrivere un buon codice è più facile che mai e per questo stiamo affrontando problemi molto più difficili che abbiamo affrontato in precedenza.

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

Senza voler cadere nel sentimentalismo "Voi ragazzi di questi tempi con la vostra anatra e la VM", suggerirei che non avete idea di quanto sia stato difficile scrivere un buon codice negli anni '80: modelli di memoria TINY, SMALL e HUGE, sovrapposizioni , chiamate del sistema operativo non rentrant (shudder). Buon viaggio a tutto ciò.

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

Era tipico per un programma DOS stare in un ciclo stretto in attesa del prossimo tasto premuto dall'utente, quindi invocare il codice corrispondente e tornare in attesa del prossimo tasto premuto.

Qualsiasi applicazione moderna in cui non è possibile utilizzare TUTTO il mouse 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 all'utente le voci più recenti durante la digitazione.

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

Speriamo che quando i ricercatori avranno capito come rendere i programmi multi-tasking più utilizzabili dal punto di vista degli sviluppatori, questo potrebbe attenuarsi, ma per ora siamo bloccati da tutti quelli che cercano di farlo bene, ma non sanno esattamente come fare esso.

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

Penso che valga la pena ricordare un'antica legge della scienza:

La natura detesta il vuoto.

Francois Rabelas (monaco e satirista francese 1494-1553)

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

Allora perché non lo facciamo?

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

Quando è stata l'ultima volta che CHIUNQUE non ha scritto un exploit o non ha studiato per farlo è andato in giro con assembly (senza contare gli hacker del kernel e i ragazzi ASIC)? Quanti bug sono stati scoperti nelle librerie C core? Quasi nessuno e pochi. Tutto quello che sto dicendo è che le persone sono capaci di un codice eccellente. Strumenti e lingue migliori lo rendono meno "richiesto" e più "facoltativo". Non che penso che dovremmo tutti scrivere codice davvero orribile, ma quando penso a costrutti logici complicati ... nessuno avrebbe mai sognato di scrivere qualcosa con array di hash nell'assemblaggio. 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 è così elegante. Penso che risolva in qualche modo il problema che hai citato. Il buon codice non è sempre solo organizzato,

Penso che ciò sia dovuto al fatto che strumenti migliori e computer più veloci e reattivi significano che prevediamo di ottenere una maggiore complessità del prodotto finale per unità di tempo rispetto a qualche anno fa (o qualche decennio). Quindi la complessità delle app continua ad aumentare e le nostre ipotesi su quale sia un livello ragionevole di produttività continuano a crescere.

Dove lavoro, gli sviluppatori hanno sempre fretta (perché ci sono sempre più cose che i clienti vorrebbero e quindi hanno tempo per). Quindi molti blocchi di codice vengono copiati con una modifica minima e senza lo sforzo fatto per capirli davvero. E ovviamente vengono fatti errori. Ho appena visto un bug corretto, in cui uno sviluppatore aveva copiato del codice che avevo ottimizzato, senza rendermi conto che le ipotesi che rendevano valida l'ottimizzazione non erano vere nel luogo in cui lo stava inserendo.

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

Anche la reattività del computer incoraggia una rapida modifica rapida, quindi una compilazione ed esecuzione di test. Ai vecchi tempi (come 35 anni fa), l'inversione di tendenza era così lenta, che avrei stampato il codice (la fonte era schede perforate allora) e fatto un passaggio manuale del codice prima di inviare il mio mazzo. Ora, modifichiamo semplicemente la compilazione e l'esecuzione. Quindi un sacco di bug che avremmo individuato, attraverso una procedura dettagliata con codice metodico, ora contiamo sul compilatore e / o sulla suite di test unitari da rilevare.

In che modo le persone sono peggiorate nel produrre un buon codice?

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

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

I programmatori possono ora concentrarsi sulla produzione di una buona struttura invece di passare così tanto tempo a digitare parentesi quadre e parentesi graffe e nuove righe e a ricordare chiamate di metodi e nomi di classi.

I miei due centesimi.

Sì, come industria non stiamo praticando quelle che sono note per essere buone metodologie. Riferimento: Low Hanging Fruit di sviluppo software software Construx di Steve McConnell .

la qualità del codice non è migliorata

per favore non rimanere bloccato nell'interpretazione di "buon codice"

Grande tautologia logica.

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

Se puoi "discutere di" buon codice ", allora non puoi confrontare e non puoi davvero decidere se è" una sfida "o no.