È più semplice definire e riconoscere una progettazione di applicazioni scadente rispetto a una buona progettazione dell'applicazione? [chiuso]

Un adagio classico è "Un buon design non è quando non c'è nulla da aggiungere ad esso, ma quando non c'è nulla da togliere" . Non ricordo chi lo abbia detto, ma è vero. Un buon design è semplice e pulito, non ci sono parti superflue in esso, ma è aperto alle estensioni allo stesso tempo.

Si noti che il riconoscimento di questi tratti richiede in definitiva un'analisi approfondita della struttura del codice. Considerando che riconoscere alcuni tratti comuni di cattiva progettazione è facile (pensare a classi enormi, metodi lunghi, convenzioni di denominazione incoerenti / inesistenti ...). Naturalmente, si potrebbe dire, è possibile avere un codice con un grande design ma nomi poveri o altri odori di codice. O cattivo design ma codice pulito e facilmente leggibile. Tuttavia, la nostra pratica ci ha insegnato che il lavoro sciatto o frettoloso crea entrambi codice errato e cattiva progettazione e viceversa: le persone che creano un design accattivante danno anche lo stesso livello di sforzo nella maggior parte o in ogni dettaglio del loro codice.

Un altro fattore è che il codice e il design sono molto più cattivi che buoni . Quindi abbiamo semplicemente probabilità di lavorare contro di noi, così otteniamo più esperienza nel riconoscere e gestire il codice cattivo che con quello buono (il che probabilmente ci rende anche pregiudizievoli). E tenderei a pensare che le persone che lavorano su un grande codice hanno più probabilità di rimanere lì per più tempo, quindi c'è meno fluttuazione in quei progetti. Che riduce ulteriormente le possibilità di inciampare su tale codice.

Penso che sia più sulla falsariga di pensare che tutto il software sia cattivo. In realtà c'è un blog su questo Coding Horror . La maggior parte del software è lavoro a noleggio e le persone che lo fanno rientrano in uno dei seguenti bucket sul motivo per cui stanno scrivendo software non valido.

• Non qualificato, ma lo finge bene.
• È più interessato all'MMO che è in esecuzione sul suo laptop.
• È più interessato alla sua parte progetto quindi il suo vero lavoro.
• Bruciato e non gli importa più Cambieranno solo le specifiche domani.

Ora non sto dicendo che tutti gli sviluppatori sono in questo modo. Ma quando gli sviluppatori sono in questo modo, vedi software non valido.

Quando non sono in questo modo è quando vedi la magia accadere.

Aggiungerò ancora una cosa a questo. Gli sviluppatori di solito fanno anche ciò che è più facile per loro nell'interfaccia utente del programma, il che a volte rende l'interfaccia utente sbagliata in cui l'utente è interessato.

In generale tutti sanno cosa NON vogliono fare o essere fatto, quindi in programmazione accade la stessa cosa:

I programmatori che avevano sofferto di problemi di progettazione e dovevano migliorarlo, capiscono quali sono le cose che hanno reso il loro lavoro più difficile, in modo che possano vedere più velocemente. Anche questi programmatori tendono ad evitare quel codice, non importa cosa, perché sanno quanto è difficile correggerlo in seguito.

È una questione di esperienza che penso: più esperienza, apper di progettazione scadente più veloce durante l'analisi del codice.

Penso che puoi dire onestamente che hai un buon design quando non c'è più nulla da togliere e è facile capire cosa fa a colpo d'occhio.

È complicato? Refactor in componenti più piccoli.

Il codice si ripete da solo? Refactor.

Idealmente dovresti essere in grado di quantificare la progettazione / l'architettura dell'applicazione. Ci sono varie statistiche di ingegneria del software (complessità ciclomatica, coesione, ecc.) Che usi come misura, queste metriche sono disponibili usando Visual Studio (sono sicuro che ci sono anche altri strumenti)

L'architettura dell'applicazione può anche essere valutata utilizzando varie tecniche (schede di revisione dell'architettura, metodo ATAM), un buon articolo può essere trovato su microsoft architecture journal qui

Penso in parte perché un'applicazione o un database ben progettati funzionano senza alcuna fanfara, quindi a malapena lo si nota. I difetti, d'altra parte, sono molto evidenti.

È facile individuare subito alcuni disegni errati. È più difficile individuare quelli che sulla superficie sembrano buoni, ma non lo sono. Ed è per questo che non riesci a individuare un buon design ... potrebbe non esserlo se guardi più a fondo.