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

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

È possibile che, come con gran parte di ciò che è richiesto in un ambiente di classe, l'intenzione non fosse quella di rendere i diagrammi di classe più utili agli sviluppatori, ma di aiutare te ei tuoi compagni di classe a pensare a come progettare le classi. Quando gli studenti stanno imparando come scomporre problemi più grandi in problemi più piccoli, è probabilmente utile per loro pensare a quali metodi privati avrebbero probabilmente bisogno. Ed è probabilmente utile per l'istruttore avere un'idea migliore di quali metodi gli studenti stanno pensando di implementare per poter intervenire prima nel processo se il design di qualcuno non è ben pensato. La documentazione in un ambiente scolastico è spesso molto più complessa della documentazione in un ambiente reale perché l'intenzione dell'istruttore è che scrivere la documentazione costringa gli studenti a considerare cose che potrebbero essere troppo inesperte per pensare se sono solo focalizzate sul loro codice. / p>

Naturalmente, è anche possibile che l'istruttore ritenga che questo livello di documentazione sia utile in un progetto reale. Se questo è il caso, l'istruttore è probabilmente obsoleto o proviene da una particolare nicchia in cui questo livello di pianificazione e documentazione è appropriato. Se stai costruendo il sistema di navigazione per lo space shuttle o progettando dispositivi medici, ad esempio, è generalmente molto più appropriato investire pesantemente nella progettazione in anticipo piuttosto che nel codice di refactoring durante lo sviluppo. Se stai sviluppando un sito di social networking, 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 rileva una critica alla cascata:

Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them. For example, clients may not know exactly what requirements they need before reviewing a working prototype and commenting on it. They may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up Front.

Questi metodi di progettazione non schiacciano l'implementatore dell'individualismo del design in quanto vi sono ancora parti da interpretare e modi per mettere i propri tocchi unici sulla struttura, ad es. foto dato uno scheletro e l'aggiunta di muscoli e altri tessuti per creare un animale chiedendosi quanta libertà hai avuto per progettare quell'animale?

Hai trovato un difetto di cascata sì, ma ogni cosa ha i suoi punti di forza e di debolezza.

In the class we learn about various software development methods. The one we focused on, and used to develop our project, was the waterfall method.

Probabilmente hai imparato il classico modello Waterfall, che la persona attribuita introducendolo nel mondo dello sviluppo del software dichiarato dall'inizio era inappropriato per lo sviluppo di sistemi software su larga scala. Probabilmente ti interesserebbe leggere il documento di Winston Royce intitolato Managing the Developemt of Large Software Systems per saperne di più i 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 mentre si passa e può dedicare del tempo all'apprendimento e all'esecuzione dei requisiti di ingegneria, progettazione architettonica, progettazione dettagliata, implementazione, test e manutenzione in fasi molto chiare e distinte.

In our class diagrams, we had to list ALL properties and methods including private ones. I have read a few books, namely Clean Code, that say to keep functions as short and focused as possible. It seems tedious to list every little function in our diagrams if they don't help other developers out (they're private, no one else will use them). Plus, I may not think of every tiny function when designing the program, they may come along when refactoring.

Questi sono tutti punti molto validi.

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

Il consiglio di Clean Code (non l'ho mai letto - sto solo passando per quello che hai postato) sembra essere giusto e applicabile anche quando si utilizza la metodologia Waterfall. Puoi progettare le tue classi e i tuoi metodi in base al principio di responsabilità singola , separazione delle preoccupazioni e altri principi di SOLID . La cascata non ti dice come progettare, solo quando hai bisogno di farlo. Detto questo, è più difficile capire come si impara e pensare a modi migliori per farlo durante l'implementazione.

Penso che questo evidenzi il fatto che ci deve essere un'iterazione tra design e implementazione molto chiaramente - un problema che la cascata tradizionale non tiene in considerazione.

It seems tedious to list every little function in our diagrams if they don't help other developers out (they're private, no one else will use them).

Se pensi che sia noioso, aspetta di avere una vera programmazione di lavoro. Considera, per un momento, che il software potrebbe non essere una carriera praticabile per te.

Plus, I may not think of every tiny function when designing the program, they may come along when refactoring.

did the instructor tell us wrong by asking us to list every function?

No. È un requisito comune.

And, do these design methods squash the implementer of the design (the developer's) individualism to write code how they can best understand it?

Sì. Lo schiacciamento delle persone è una parte importante dello sviluppo del software. Tutte le individualità saranno battute da tutti i programmatori in ogni momento in tutti i modi possibili. Dice che da qualche parte nelle "Regole di Dio della Programmazione" tramandate da qualche montagna a qualche profeta.

No. Stai solo prendendo in giro la noia. Passa oltre e torna al lavoro.

La programmazione è l'arte di lavorare all'interno di vincoli. La CPU fornisce un set di istruzioni limitato; IO è vincolato dal design dell'hardware; Le API del sistema operativo sono create per incoraggiare certi comportamenti e limitare gli altri; linguaggi di alto livello sono spesso progettati per promuovere un insieme di idiomi rispetto ad altri ...

Anche le metodologie sono predisposte per limitare.

La tua sfida, in tutti gli aspetti del processo di sviluppo, è realizzare la tua visione entro quei vincoli. Schiaccerai la tua testa contro ogni parete generata da hardware, linguaggio, 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 infinite pagine di minuzia? Quindi prova questa teoria: interrompi un programma e documenta ogni atomo. Quando la sua scrivania sta cedendo 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 tu vedi in forma. Metti in 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 brillante per averti fatto questo progetto, e quindi ti ha insegnato i pro e (soprattutto) gli svantaggi 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 essere ritenuto responsabile di qualcosa di abbastanza drammatico (in genere compresa la morte o l'enorme quantità di denaro persa) che si verifica con il software creato?" .

Ho avuto la stessa esperienza con te per alcuni dei miei corsi. Le persone che avevano una formazione nell'industria farmaceutica ci insegnerebbero le analisi. E sarebbe un'analisi completa ed esauriente, che pianificasse tutto il corso del progetto, anche nei minimi dettagli. Non puoi permetterti molte iterazioni con questo tipo di progetto (anche la bomba che esplode può andare bene, il budget che esplode non lo è), quindi non c'è spazio per la creatività qui, devi andare dal piano.

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

In conclusione, più esperienza ottieni e meglio, e ciò che il tuo istruttore ti mostra si applica in alcune parti del settore. Basta essere consapevoli del fatto che ci sono certamente tanti modi per gestire e progettare un progetto in quanto ci sono per codificarli. E troverai difensori e critici per tutti loro. Provali mentre studi e scegli quello di cui sei felice.

Alcune classi di ingegneria del software, come quella che ho avuto, vengono insegnate in uno stile strano in cui "il fallimento è successo", il successo è un'opportunità sprecata per imparare dal fallimento, e più è sempre meno. Se questo è uno di quelli, allora segui i compiti e goditi la stranezza.

Penso che il tuo istruttore sia fuori controllo. Il software commerciale è raramente progettato o documentato in tale misura. È troppo costoso e la documentazione risultante non può essere mantenuta senza ulteriori spese. Le pratiche IMO sono un retaggio dei giorni in cui la codifica veniva spesso eseguita in linguaggio assembly. Il tuo tempo sarebbe stato meglio speso nel provare pratiche più agili: sviluppo basato su test, programmazione della coppia, refactoring continuo.

Did the instructor "tell you wrong" ?

Penso di sì.

Assegnare lavori noiosi ai lavoratori della proprietà intellettuale è uno spreco. A scuola, il lavoro noioso ha poco o nessun valore pedagogico, tranne forse per attirare gli studenti a lavori noiosi. Tali esercizi hanno conseguenze negative, sia per gli studenti, sia per l'industria. Gli studenti sono danneggiati perché il loro tempo è sprecato. L'industria è danneggiata, perché alcuni studenti possono concludere che questo tedio è necessario e utile. Non è né In trent'anni di software, l'unica opera che riesco a pensare sia noiosa e utile è stata la sostituzione dei nastri di backup. C'erano robot che potevano farlo, ma erano proibitivamente costosi.