Qual è il ruolo della soggettività nella programmazione?

Question

Ho letto spesso sull'importanza della leggibilità e della manutenibilità. Oppure, leggo opinioni molto forti su quali caratteristiche di sintassi sono cattive o buone. O discussioni sui valori di alcuni paradigmi, come OOP.

A parte questo, questa stessa domanda mi viene in mente ogni volta che leggo i dibattiti su SO o Meta su domande soggettive. Oppure leggi le domande sulle migliori pratiche e a volte trovi me stesso o altri in disaccordo.

Quale ruolo gioca la soggettività nel campo della programmazione?

A volte penso che giochi un ruolo importante. Gli sviluppatori di software sono ingegneri in un certo senso, ma anche persone. Gran parte della programmazione riguarda il codice leggibile dall'uomo. Questo è molto diverso dalla matematica o dalla fisica o da altre discipline con regole molto precise e strutturate. Qui la struttura e le regole esatte sono in gran parte nell'aria, mutevoli per un capriccio, e quindi la quantità di lingue esistenti. E una persona potrebbe trovare una lingua molto leggibile, e un'altra persona potrebbe trovare la propria lingua più confortevole.

Lo stesso con le pratiche. A una persona potrebbero non piacere certe pratiche accettate. Io stesso trovo che le classi di divisione in file diversi siano illeggibili, ad esempio.

Ma, non posso dire che le regole non hanno aiutato in generale. Alcune pratiche hanno e rendono la vita più facile. E i nuovi linguaggi hanno dato origine a sintassi e struttura che semplificano la vita. Sicuramente c'è stata una progressione verso il codice che è più facile da leggere e mantenere anche in considerazione di un gruppo di persone ampiamente diversificato. Quindi forse queste cose non sono così soggettive come pensavo.

Mi ricorda, in un certo senso, il design dell'interfaccia utente. Certamente è soggettivo, ma poi c'è un'intera disciplina coinvolta nella creazione di una buona interfaccia utente e tende a funzionare.

Esiste qualcosa di non soggettivo sulle idee alla base della manutenibilità, della leggibilità e di altre best practice? C'è qualcosa di tangibile da comprendere quando si sviluppa un nuovo linguaggio o si pensa a nuove pratiche?

Answer 1

Probabilmente la tua domanda è davvero sulla distinzione tra programmazione, che è matematico, algoritmico e scientifico, e software di ingegneria, che è soggettivo, variabile e umano-concentrato.

I grandi programmatori non sono necessariamente grandi ingegneri del software e viceversa. I due skillset, pur non essendo esclusivi in ​​alcun modo, si sovrappongono meno di quanto non appaiano in un primo momento. La loro importanza relativa dipende molto dal progetto: un brillante programmatore che lavora da solo può dar vita a incredibili esempi di genio tecnico, e non importa che nessun altro possa capirlo o mantenerlo, perché comunque non condividerà il codice. Ma trasferirsi in un ambiente aziendale - come lo sviluppo di software aziendale interno - e sarò lieto di scambiare dieci geni "troll da caverna" per un programmatore mediocre che capisce l'importanza della leggibilità e della documentazione.

È stata la mia esperienza che il mondo ha bisogno di grandi ingegneri del software più di quanto abbia bisogno di grandi programmatori. Relativamente poche persone al giorno d'oggi stanno scrivendo software che è veramente critico per le prestazioni (kernel OS, compilatori, motori grafici, sistemi embedded in tempo reale, ecc.) E Internet consente ai programmatori mediocri di afferrare rapidamente soluzioni algoritmiche per problemi che non potrebbero risolvi da solo Ma quasi tutti coloro che scrivono codice professionale devono lavorare all'interno di una squadra.La produttività del team aumenta e diminuisce drasticamente la capacità dei suoi membri di comunicare in modo efficace e distribuire il carico di lavoro in modo efficiente, due abilità che sono altamente soggettive e impossibili da dimostrare con una formula rigida.

La maggior parte dei principi di ingegneria del software si basa sull'esperienza anziché sulla legge oggettiva. Proprio come le scienze sociali, studiamo, apprendiamo, adattiamo e applichiamo - ma senza garanzie reali di risultato. Tutto quello che possiamo dire è che alcune cose sembrano funzionare meglio di altre nella maggior parte dei gruppi.

Answer 2

Penso che molto sia necessariamente determinato da quanto la nostra mente è in grado di elaborare in una volta. Quindi si tratta di quanto il linguaggio e gli strumenti consentono a un team o a uno sviluppatore di suddividere il problema in blocchi significativi, ma non così grandi da renderli troppo difficili da afferrarli. Il tema comune è l'arte di organizzare le informazioni (in questo caso, il codice, la logica, ...) Ma non è così diverso da Matematica o Fisica, a proposito.

Answer 3

Tutto dipende dal vostro punto di vista :-)

Ma per rispondere alle vostre domande, penso che un modo per visualizzare la soggettività è quello di riconoscere che le lingue del software, strumenti e best practice sono un mezzo di comunicazione condivisi tra gli individui. Sì, un linguaggio di programmazione è un modo formale di insegnare a un computer come comportarsi, ma un linguaggio di programmazione può anche essere visto come un modo per definire e comunicare le specifiche ad un alto livello di dettaglio (il codice è la specifica definitiva, non è ?).

Quindi, per quanto possiamo desiderare di occuparci del grado di soggettività nei linguaggi del software, degli strumenti e delle migliori pratiche, direi che la mancanza di soggettività può indicare quanto sia agevole la comunicazione.

Sì, gli individui hanno certe inclinazioni che si esprimono nelle loro abitudini e tendenze, ma che in definitiva non dovrebbero essere troppo importanti nella piattaforma perfetta per lo sviluppo.

Answer 4

Proprio come i migliori autori prendono in prestito da molti stili, i migliori programmatori mantengono una vasta gamma di modelli nel loro arsenale mentale. Seguire pedissequamente alcuni schemi e aderire ad una verità assoluta è sia pigro che pericoloso.

In un altro modo, il giorno in cui ci affidiamo ai robot per la revisione del codice è il giorno in cui ho smesso.

Answer 5

Rivolgendomi alla mia dottoressa di matematica, ho chiesto se c'è qualche soggettività in matematica. La sua risposta è sì, soprattutto nel modo in cui noi umani otteniamo la risposta.

Se una prova matematica è il risultato, come si arriva a quel risultato può variare. Se il set di dati è di grandi dimensioni, potrebbe essere necessario utilizzare un computer, che può introdurre errori, e quindi discutere se questo sia l'approccio giusto. O a volte i matematici possono non essere d'accordo sulla teoria: uno sta cercando di dimostrare che x è vero mentre l'altro sta cercando di dimostrare che x è falso.

Penso che la stessa cosa esista nell'informatica. Una risposta corretta è un programma che funziona correttamente, ma quella definizione di corretto può essere diversa per ogni progetto. A volte corretto non significa bug. A volte significa correre in modo efficiente.

Da qui i programmatori possono discutere il modo migliore per ottenere il risultato "corretto". Un buon esempio di ciò è l'applicazione FizzBuzz. Una semplice risposta sarebbe solo un ciclo for, ma Enterprise FizzBuzz è anche "corretto" nel senso che produce la risposta corretta, ma generalmente è deriso come ingegneria "cattiva" a causa della sua eccessiva complicazione dell'idea (era un'app di scherzo dopotutto).

Quale ruolo gioca la soggettività nella programmazione? Direi che è una parte molto ampia di ciò che facciamo, semplicemente perché siamo umani, e perché ci sono molti modi per ottenere la risposta "corretta", quindi c'è disaccordo su quale sia la via migliore.

Answer 6

Sono stati effettuati studi che dimostrano che alcune pratiche riducono i tassi di errore nel software. Ad esempio, uno study ha trovato una forte correlazione tra la complessità ciclomatica e la probabilità di essere soggetta a errori. Other studies mostrano l'efficacia media del design e le ispezioni del codice sono 55 e 60 percento. Sembra quindi che sia nel nostro migliore interesse favorire la semplicità, controllare le metriche e fare revisioni del codice.

Qui stiamo parlando di probabilità. Se rivedo il tuo codice, non ho la certezza di trovare il 60% dei tuoi bug. Ci sono anche alcuni assoluti nello sviluppo del software; gli sviluppatori esperti sanno che la risposta corretta è generalmente "dipende". Detto questo, ci sono un certo numero di pratiche con dati oggettivi a loro favore.