Unire le tabelle è il pane e il burro dell'utilizzo di database relazionali. Quando non puoi fare JOIN, non li capisci veramente. Ecco perché ogni buon corso di database di solito inizia con il disegno di diagrammi ERD prima ancora di scrivere la prima riga di SQL.
I modelli di progettazione orientati agli oggetti vengono spesso ignorati da persone che li usano ogni giorno, ma non hanno la capacità di riconoscerli. Ma essere in grado di riconoscerli e usarli consente di leggere e scrivere un codice OO molto più elegante e modulare.
Ti chiedi come qualcuno possa ancora scrivere un'applicazione sufficientemente complessa e di successo utilizzando sia database relazionali che un linguaggio di programmazione orientato agli oggetti senza comprendere queste cose? È sorprendente fino a che punto si può arrivare nello sviluppo del software senza realmente sapere cosa si sta facendo quando si è abbastanza perseveranti. Non conosci JOINs? Nessun problema, basta selezionare tutto da entrambe le tabelle e scrivere un algoritmo di corrispondenza nell'applicazione. Ci vorrà un tempo di sviluppo cinque volte maggiore, sarà dieci volte più lento e avrà venti volte la quantità di codice sorgente rispetto alla semplice scrittura di un JOIN, ma alla fine hai i dati che desideri. E tu sei orgoglioso di te stesso, perché non potresti immaginare un modo migliore per risolvere questo complesso problema. Quando il tuo unico strumento è un martello, ogni problema sembra un chiodo.
In effetti scrivere una grande applicazione completa di funzionalità non è la parte difficile. La parte difficile è mantenerla .
La differenza tra codice buono e codice cattivo in genere non è notevole durante la fase di sviluppo di un prodotto. Direi anche che un team di sviluppo non qualificato potrebbe portare un prodotto sul mercato ancora più veloce , perché tende a trascurare una complessità nascosta che non verrà notata senza una corretta verifica e gestione del QA (saranno notati dopo che il prodotto è in produzione - che di solito sarà peggiore).
Tuttavia, la qualità del software inizia a essere importante dopo che il prodotto passa dalla fase di sviluppo alla fase di supporto e devono essere apportate modifiche inaspettate al codice base. Una base di codice ben congegnata, scritta da un abile ed esperto software architect, è molto più flessibile di una hackerata da un principiante, il che significa che modificare l'applicazione dopo il rilascio sarà molto più semplice e quindi più economica. E peggio il team di sviluppo iniziale, più bug e funzionalità mancanti dovranno essere risolti.
