Come scoprire effettivamente cosa si deve fare nella progettazione orientata agli oggetti?

12

In primo luogo una dichiarazione di non responsabilità: non so davvero se questa domanda si adatta a questo sito, ma trovo comunque una domanda pertinente non solo per me, ma per altre persone che sono alle prime armi. Se la domanda può essere migliorata per adattarsi qui, si prega di sottolineare i commenti int. Se non si adatta, fammi sapere anche e se possibile fammi sapere dove questo può essere discusso perché non ho trovato alcun forum valido per questo.

Ho imparato a programmare nel 2009 quando ho studiato PHP. Più tardi nel 2012, mi sono trasferito in C # e .NET. Ad ogni modo, la codifica non è un problema, scrivere algoritmi non è un mio problema. Il mio vero problema è sapere che deve essere codificato per raggiungere un requisito e dove deve essere codificato.

La maggior parte dei corsi disponibili sul web affronta il come - come scrivere codice in una determinata lingua, come utilizzare alcuni set di API, ecc. Non è questo il mio punto qui.

In questi anni ho letto molto su un sacco di cose: analisi orientata agli oggetti e design, modelli di progettazione, progettazione basata sul dominio e così via. Capisco ad esempio i principi SOLID, alcune delle idee principali del DDD come la necessità di coinvolgere esperti di dominio, lo sviluppo di un linguaggio ubiquo e così via. Oserei dire uno sfondo teorico almeno ragionevole.

Ma quando si tratta di pratica mi sento come se fossi un disastro. Qualche tempo fa avevo bisogno di continuare lo sviluppo di un sistema finanziario che era già stato sviluppato da qualcun altro. È quel tipo di "vecchio sistema" sviluppato con C # e WinForms. È stata la prima volta che ho scelto un progetto con una complessità di dominio reale, con molte regole aziendali e così via.

Confesso che quando ricevo i requisiti per la maggior parte del tempo penso "come diavolo si può fare?" - Non ho idea di come iniziare a lavorare sui requisiti per capire cosa deve essere fatto. Le mie principali confusioni credo siano ciò che devo codificare, quali classi, interfacce e dove ogni pezzo di logica va, su quale classe ogni cosa deve essere. Il problema è che non so da dove cominciare.

La maggior parte delle volte, con un sacco di pensieri, finisco con alcune idee, ma non so mai come giudicare se la mia idea è corretta o meno.

Voglio dire, non penso che questa sia una mancanza di teoria, come ho detto di aver letto su un po 'di cose sull'architettura software e l'orientamento agli oggetti mi è stato raccomandato ma non è stato di grande aiuto nell'individuare ciò che deve essere fatto in pratica.

Quindi, come posso imparare a veramente fare design orientato agli oggetti? Quello che voglio imparare è: dati requisiti sanno come iniziare a lavorare su di loro in un processo che porta a scoprire cosa deve essere fatto e dove ogni pezzo di codice appartiene. Come posso anche imparare a giudicare se la mia idea è corretta o no?

Credo che spiegarlo pienamente come risposta qui non sarebbe possibile. Quello che sto cercando, tuttavia, che può essere in base allo stile del sito sono le risposte, solo dando una panoramica e indicando alcuni riferimenti (libri, corsi online, ecc.) Che possono essere utilizzati per espandere le idee e imparare davvero queste cose. p>     

posta user1620696 07.05.2017 - 00:35
fonte

2 risposte

21

So how can I learn to really do object oriented design? What I want to learn is: given requirements know how to get started working on them in a process that leads to find out what has to be done and where each piece of code belongs. How can I also learn to judge if my idea is correct or not?

Prima di tutto, smetti di pensare al design orientato agli oggetti come corretto. È come pensare che l'inglese sia corretto.

Il paradigma orientato agli oggetti non è corretto. Ha alcuni vantaggi e svantaggi. È un ideale Non è il nostro unico. È meglio di niente ma non è certamente tutto.

Ho iniziato a scrivere codice per decenni. Ho studiato questa roba per quasi tutto il tempo in cui le idee sono esistite. Sto ancora imparando cosa significa. Gli esperti stanno ancora imparando cosa significa. Il nostro intero campo ha meno di 100 anni.

Quindi, quando prendi un mucchio di requisiti e ottieni codice che li soddisfi e senti come se il codice che hai scritto fosse un disastro tragico, non sei il solo. Il codice di lavoro è semplicemente il primo passo verso un grande codice. Codice che funziona non solo ma che gli altri possono leggere e capire facilmente. Codice che può essere adattato rapidamente quando cambiano i requisiti. Codice che ti fa venir voglia di sederti e dire "Wow, è così semplice".

Il problema è che non siamo pagati per fare tutto questo. Facciamo tutto questo perché siamo professionisti. Dobbiamo fare tutto questo quando il capo non guarda perché c'è sempre una scadenza. Ma vogliamo tornare tra 5 anni e dire ai neofiti: "Oh sì, l'ho scritto. Funziona ancora, eh? Fantastico."

Come ci si arriva? Pratica. Non accettare QUALSIASI idea progettuale sulla fede. Qualcuno non starà zitto su come il design guidato dagli eventi semplificherà questo design? Non sono sicuro se hanno ragione? Costruisci il tuo progetto giocattolo a casa che utilizza il modello di osservatore. Pasticciarlo. Cerca di trovare cose che NON aiuta.

Leggi. Domanda. Test. Ripeti.

Quando arrivi al punto che lo stai facendo per l'80% della tua vita, sarai altrettanto confuso di me.

I confess that when I receive the requirements most of the time I think "how on earth can this be done?" - I have no idea on how to even get started working on the requirements to figure out what has to be done. My main confusions I believe are what I must code, what classes, interfaces and where each piece of logic goes, on which class each thing must be. The problem is that I don't know where to start.

Mi sentivo allo stesso modo. Poi ho scoperto la gioia del refactoring. Siate disposti ad adattare i progetti mentre scrivete. Cercare di lavorare tutto su carta in anticipo è il modo difficile per farlo. Scrivi un codice che può essere dimostrato errato, dimostralo sbagliato e risolvilo.

    
risposta data 07.05.2017 - 02:50
fonte
1

Lo sviluppo del software si riduce alla fornitura di software funzionante, in tempo, al budget, rispettando tutti i criteri di accettazione. Supponendo che tu sia riuscito a farlo, la qualità percepita del codice o della sua struttura è una preoccupazione secondaria.

Il problema, naturalmente, è che la scrittura di un nuovo codice greenfield tende ad essere molto più economico e semplice rispetto al mantenimento del codice legacy, quindi piuttosto che essere troppo attaccati alla qualità del codice o all'architettura, ricorda che il tuo vero problema è la manutenibilità.

Tipicamente il codice è considerato mantenibile quando i costi, i tempi ei rischi associati alla modifica di quel codice sono sufficientemente bassi che la correzione di bug o l'implementazione di modifiche ai requisiti è ancora conveniente e che implementando tali modifiche non si perpetua un "spirale della morte" di entropia del codice.

Viceversa, il codice è considerato non-gestibile quando non puoi cambiare o refactoring senza il serio rischio di rompere qualcosa o di spendere troppo tempo / denaro per assicurarti che nulla sia rotto - cioè quando il tempo, il costo e il rischio coinvolti nel lavorare con quel codice sono sproporzionatamente alti rispetto ai benefici di apportare modifiche (ad esempio, il tuo datore di lavoro o il cliente non perde denaro aggiungendo nuove funzionalità, correggendo bug, ecc.)

Ricorda che anche il più diabolico pasticcio di spaghetti può essere potenzialmente mantenibile se hai abbastanza provviste intorno alla mensa per proteggerti da cambiamenti improvvisi (anche se questi casi sono rari). Il problema di un pasticcio di spaghetti è che la protezione contro i cambiamenti di rottura tende ad essere piuttosto costosa e inefficiente, specialmente se lo stai facendo in modo retrospettivo.

Forse il modo più affidabile per assicurarti di aver scritto un codice gestibile è scrivere (ove ragionevolmente possibile) una serie adeguata di test automatizzati allo stesso tempo (sfruttando al tempo stesso tutti gli altri strumenti di analisi statica che potrebbero essere disponibili ).

Non hai particolarmente bisogno di seguire una rigorosa metodologia di sviluppo come TDD / BDD per finire con un numero sufficiente di test automatici per permetterti di refactoring; hai solo bisogno di abbastanza per proteggere il codice da eventuali modifiche accidentali in futuro.

Se il tuo codice è coperto da test automatici, puoi rilassarti sul suo design e struttura sapendo che sei coperto da questi test; puoi refactoring aggressivo in un secondo momento, o anche buttarlo via e ricominciare.

Questo porta alla domanda su come scrivere codice facilmente verificabile; questo è in genere l'argomento principale per seguire i principi SOLID; infatti, il segno distintivo del codice che aderisce ai principi SOLID è che è facile e veloce ed economico scrivere i test unitari.

Ovviamente, a volte non hai nemmeno il tempo di scrivere i test unitari; tuttavia se hai scritto tutto il codice tenendo presente la domanda "Come scrivo test automatici per questo?" (anche se non hai effettivamente implementato questi test), probabilmente hai anche riuscito a trovare un disegno che è ragionevolmente mantenibile.

    
risposta data 07.05.2017 - 19:17
fonte