I metodi di sviluppo dovrebbero schiacciare l'individualismo di uno sviluppatore?

Sono nel mio ultimo semestre di college e sto seguendo un corso di ingegneria del software. Nella classe apprendiamo vari metodi di sviluppo del software. Quello su cui ci siamo concentrati, e utilizzato per sviluppare il nostro progetto, era il metodo a cascata.

Sento che l'istruttore potrebbe averlo implementato in modo sbagliato. Nei nostri diagrammi di classe, abbiamo dovuto elencare TUTTE le proprietà e i metodi, compresi quelli privati. Ho letto alcuni libri, in particolare Clean Code, che dicono di mantenere le funzioni più brevi e mirate possibile. Sembra noioso elencare ogni piccola funzione nei nostri diagrammi se non aiutano altri sviluppatori (sono privati, nessun altro li userà). Inoltre, potrei non pensare a tutte le minuscole funzioni durante la progettazione del programma, ma potrebbero presentarsi durante il refactoring.

L'istruttore ci ha detto male chiedendoci di elencare ogni funzione? E questi metodi di progettazione schiacciano l'individualismo dello sviluppatore per scrivere codice come possono comprenderlo meglio?

Hai chiesto all'istruttore perché hai dovuto elencare tutti i metodi?

È possibile che, come con gran parte di ciò che viene richiesto in un ambiente di classe, l'intenzione non fosse quella di rendere i tuoi diagrammi di classe più utili per gli sviluppatori, ma di aiutare te e i tuoi compagni di classe a pensare a come progettare le tue classi. Quando gli studenti stanno imparando come scomporre i problemi più grandi in problemi più piccoli, è probabilmente utile per loro pensare a quali metodi privati ​​avrebbero probabilmente bisogno. Ed è probabilmente utile che l'istruttore abbia una migliore idea di quali metodi gli studenti stiano pensando di implementare per intervenire prima nel processo se il design di qualcuno è mal concepito. La documentazione in un ambiente di classe è spesso molto più coinvolta della documentazione in un ambiente del mondo reale perché l'istruttore "

Naturalmente, è anche possibile che l'istruttore ritenga che questo livello di documentazione sia utile in un progetto reale. In tal caso, l'istruttore è probabilmente obsoleto o proviene da un particolare background di nicchia in cui questo livello di pianificazione e documentazione è appropriato. Se stai costruendo il sistema di navigazione per la navetta spaziale o progettando dispositivi medici, ad esempio, è generalmente molto più appropriato investire pesantemente nella progettazione in anticipo piuttosto che nel refactoring del codice durante lo sviluppo. Se stai sviluppando un sito di social network, d'altra parte, un approccio più agile è più appropriato.

No, l'istruttore ha ragione nel dirti di elencare tutte le proprietà e i metodi in anticipo se stai usando il metodo waterfall. Wikipedia nota una critica alla cascata:

Molti sostengono che il modello a cascata sia una cattiva idea nella pratica: ritengono impossibile per qualsiasi progetto non banale completare perfettamente una fase del ciclo di vita di un prodotto software prima di passare alle fasi successive e imparare da esse. Ad esempio, i clienti potrebbero non sapere esattamente quali requisiti sono necessari prima di rivedere un prototipo funzionante e commentarlo. Possono cambiare costantemente le loro esigenze. I progettisti e i programmatori possono avere poco controllo su questo. Se i clienti cambiano i loro requisiti dopo che il progetto è stato finalizzato, il progetto deve essere modificato per soddisfare i nuovi requisiti. Ciò significa effettivamente invalidare una buona parte delle ore di lavoro, il che significa un aumento dei costi, soprattutto se una grande quantità delle risorse del progetto è già stata investita in Big Design Up Front.

Questi metodi di progettazione non schiacciano l'implementatore dell'individualismo del design in quanto ci sono ancora parti da interpretare e modi per mettere i tocchi unici sulla struttura, ad esempio l'immagine con uno scheletro e l'aggiunta di muscoli e altri tessuti per creare un animale chiedendosi quanto libertà hai dovuto progettare quell'animale?

Hai trovato una carenza di cascata sì, ma tutto ha i suoi punti di forza e di debolezza.

Nella classe apprendiamo vari metodi di sviluppo del software. Quello su cui ci siamo concentrati, e utilizzato per sviluppare il nostro progetto, era il metodo a cascata.

Probabilmente hai appreso il classico modello Waterfall, che la persona attribuita con l'introduzione nel mondo di sviluppo del software ha dichiarato fin dall'inizio inappropriato per lo sviluppo di sistemi software su larga scala. Probabilmente saresti interessato a leggere l'articolo di Winston Royce intitolato Gestione dello sviluppo di sistemi software di grandi dimensioni per saperne di più sui problemi con quello che molte persone considerano il modello Waterfall.

Tuttavia, il modello Waterfall è utile per insegnare il ciclo di vita dello sviluppo del software man mano che si procede e può trascorrere del tempo a conoscere ed eseguire ingegneria dei requisiti, progettazione architettonica, progettazione dettagliata, implementazione, test e manutenzione in fasi molto chiare e distinte.

Nei nostri diagrammi di classe, abbiamo dovuto elencare TUTTE le proprietà e i metodi, compresi quelli privati. Ho letto alcuni libri, in particolare Clean Code, che dicono di mantenere le funzioni più brevi e mirate possibile. Sembra noioso elencare ogni piccola funzione nei nostri diagrammi se non aiutano altri sviluppatori (sono privati, nessun altro li userà). Inoltre, potrei non pensare a tutte le minuscole funzioni durante la progettazione del programma, ma potrebbero presentarsi durante il refactoring.

Questi sono tutti punti molto validi.

Elencare tutte le proprietà e i metodi durante la fase di progettazione, anche quando si utilizza Waterfall, è probabilmente eccessivo. Dovresti assolutamente elencare tutto ciò che è pubblico, insieme alle proprietà essenziali. In realtà, tutto il resto è un dettaglio dell'implementazione che è possibile ottenere eseguendo il reverse engineering dell'implementazione in diagrammi.

Il consiglio di Clean Code (non l'ho mai letto - sto solo seguendo quello che hai pubblicato) sembra essere giusto e applicabile anche quando si utilizza la metodologia Waterfall. È possibile progettare le classi e i metodi rispetto al principio di responsabilità singola , alla separazione delle preoccupazioni e ad altri principi di SOLID . Waterfall non ti dice come progettare, proprio quando devi farlo. Detto questo, è più difficile in anticipo mentre impari e pensi a modi migliori per farlo durante l'implementazione.

Penso che ciò evidenzi il fatto che ci deve essere un'iterazione tra progettazione e implementazione molto chiaramente - un problema che Waterfall tradizionale non tiene conto.

Sembra noioso elencare ogni piccola funzione nei nostri diagrammi se non aiutano altri sviluppatori (sono privati, nessun altro li userà).

Se ritieni che ciò sia noioso, attendi di ottenere una vera programmazione di lavoro. Considera, per un momento, che il software potrebbe non essere una carriera praticabile per te.

Inoltre, potrei non pensare a tutte le minuscole funzioni durante la progettazione del programma, ma potrebbero presentarsi durante il refactoring.

Così?

l'istruttore ci ha detto male chiedendoci di elencare ogni funzione?

No. È un requisito comune.

E questi metodi di progettazione schiacciano l'implementatore dell'individualismo di progettazione (lo sviluppatore) per scrivere codice come possono comprenderlo meglio?

Sì. Lo schiacciamento dell'anima degli individui è una parte importante dello sviluppo del software. Tutta l'individualità sarà sempre battuta da tutti i programmatori in tutti i modi possibili. Dice che da qualche parte nelle "Regole di programmazione di Dio" tramandate da qualche montagna ad un profeta.

No. Ti stai solo prendendo in giro per il tedio. Superalo e torna al lavoro.

La programmazione è l'arte di lavorare entro limiti. La CPU fornisce un set di istruzioni limitato; IO è vincolato dalla progettazione dell'hardware; Le API del sistema operativo sono create per incoraggiare determinati comportamenti e limitarne altri; le lingue di alto livello sono spesso progettate per promuovere un insieme di idiomi su altri ...

E anche le metodologie sono progettate per limitare.

La tua sfida, in tutti gli aspetti del processo di sviluppo, è realizzare la tua visione entro quei limiti. Sfonderai la testa contro ogni muro abbattuto da hardware, lingua, API e metodologia? O troverai un modo per armonizzare ciò che desideri ottenere con ciò che è permesso e incoraggiato?

Pensi davvero che il tuo istruttore desideri leggere attraverso infinite pagine di minutia? Quindi prova questa teoria: spezza un programma e documenta ogni atomo. Quando la sua scrivania si abbassa sotto il peso, sospetto piuttosto che scoprirai che il suo vero desiderio è in qualche modo diverso da quello che ti aspetti.

Oppure prepara la documentazione come ritieni opportuno. Rendilo chiaro, rendilo comprensibile, fallo leggere come un romanzo di Dashiell Hammett. E poi siediti e parla con lui, mostragli quello che hai fatto, convincilo del suo merito.

Penso che l'istruttore sia geniale per averti fatto fare questo progetto, insegnandoti così i pro e (principalmente) i contro dello sviluppo di Waterfall.

Una semplice regola empirica per valutare la complessità dell'analisi del progetto è "Può lo sviluppatore o la società per cui lavora può essere ritenuto responsabile di qualcosa di abbastanza drammatico (in genere tra cui morte o enormi perdite di denaro) che sta accadendo con il software creato?".

Ho avuto la tua stessa esperienza per alcuni dei miei corsi. Le persone che avevano una formazione nel settore militare ci insegnerebbero l'analisi. E questa sarebbe un'analisi completa ed esaustiva, pianificando tutto il corso del progetto, anche nei minimi dettagli. Non puoi permetterti molte iterazioni con questo tipo di progetto (anche l'esplosione delle bombe può essere ok, l'esplosione del budget non lo è), quindi non c'è spazio per la creatività qui, devi seguire il piano.

D'altra parte, se hai letto un po ', sicuramente leggi delle metodologie agili. Di solito c'è meno documentazione e più spazio per lo sviluppatore di usare la sua creatività mentre sviluppa una soluzione al problema che incontra.

In conclusione, più esperienza ottieni, meglio è e ciò che il tuo istruttore ti sta mostrando si applica in alcune parti del settore. Basta essere consapevoli del fatto che esistono molti modi per gestire e progettare un progetto quanti sono i codici. E troverai difensori e critici per tutti loro. Mettili alla prova mentre studi e scegli quello di cui sei felice.

Alcune lezioni di ingegneria del software, come quella che ho tenuto, sono tenute in uno strano stile in cui "il fallimento è successo", il successo è un'opportunità sprecata per imparare dal fallimento, e più è sempre meno. Se questo è uno di quelli, basta attenersi agli incarichi e godersi la stranezza.

Penso che il tuo istruttore sia fuori dal mondo. Il software commerciale è raramente progettato o documentato in tale misura. È troppo costoso e la documentazione risultante non può essere mantenuta senza ulteriori spese. Tali pratiche dell'IMO sono un retaggio dei giorni in cui la codifica veniva spesso eseguita in linguaggio assembly. Il tuo tempo sarebbe stato speso meglio cercando pratiche più agili: sviluppo guidato dai test, programmazione di coppie, refactoring continuo.

L'istruttore "ti ha detto di sbagliato"?

Credo di si.

Assegnare lavoro noioso ai lavoratori della proprietà intellettuale è uno spreco. A scuola, il lavoro noioso ha poco o nessun valore pedagogico, tranne forse per indurre gli studenti a un lavoro noioso. Tali esercizi hanno conseguenze negative, sia per gli studenti che per l'industria. Gli studenti sono feriti perché il loro tempo è sprecato. L'industria è danneggiata, perché alcuni studenti possono concludere che tale tedio è necessario e utile. Non è nessuno dei due. In trent'anni di software, l'unico lavoro a cui riesco a pensare è stato noioso e utile è stato cambiare i nastri di backup. C'erano dei robot che potevano farlo, ma erano proibitivamente costosi.