Come imparare / diventare capace di fornire un design di qualità per le app?

5

Sono interessato a cose che un programmatore dovrebbe imparare / conoscere per fornire una progettazione dell'architettura dell'applicazione estremamente buona.

Come noto, qualsiasi progetto può essere considerato valido per determinate circostanze, ma quando si tratta di estendere il set di funzioni dell'app o di fornire un'ottimizzazione e così via, risulta che l'app è stata mal progettata o priva di astrazione. Come essere in grado di prevedere e includere tali elementi nella progettazione di app?

E d'altra parte, il software è qui per essere robusto, efficiente e veloce. Ed è lo scopo principale da un certo punto di vista è quello di portare soldi (salvandoli o guadagnandoli). Quindi, se si approfondisce l'astrazione e si considerano alcune cose che saranno necessarie in 2 o più anni, non avrà una buona architettura di app (avrà molte cose inutili). Quindi, come capire fino a che punto sono necessarie alcune cose nell'architettura delle app?

Spero di essere stato chiaro, altrimenti per favore commenta su parti vaghe.

    
posta Denys S. 05.04.2011 - 13:05
fonte

3 risposte

6

How to be able to predict and include such stuff into app design?

Non puoi prevedere l'inconoscibile. Pertanto, devi seguire la regola d'oro di Late Binding . Non "bloccare" le decisioni; consentire componenti, classi, moduli da rimuovere e sostituire come si impara.

link

link

if one goes deep with abstraction and considered certain stuff that will be needed in 2 or more years, he's not going to end up with good app architecture (he's gonna have lots of unnecessary stuff). So how to understand to which extent certain stuff in app architecture is needed?

Dare priorità.

Leggi i metodi Agile, in particolare "Scrum".

Assegna la priorità alle funzioni. Progetta le funzionalità che ti servono per prima. Rilasciali. Fatti pagare per loro. Passa alla prossima serie di funzioni.

Non anticipare profondamente o molto lontano nel futuro.

Segui la regola di Late Binding e crea solo ciò che è necessario e non di più.

"Deep with astrstration" diventa spesso un gioco per evitare di creare software utili.

    
risposta data 05.04.2011 - 13:23
fonte
3

Ci sono molti libri di valore sul design, ma l'apprendimento del libro ha dei limiti. Per completare l'apprendimento del libro, ecco tre cose che migliorano l'acume del design:

  1. Impara a pensare ed essere accurato : la programmazione è principalmente un'attività intellettuale. Imparare a pensare attraverso le conseguenze delle idee e comunicare con precisione aiuta nella concettualizzazione (cioè il design) della struttura del programma (sia procedurale che orientata agli oggetti). Impegnati a pensare attraverso i dettagli del tuo design: potresti dover allontanarti dal computer e disegnare alcune linee e forme sulla carta.
  2. Progettazione per test : Cruft è spesso inevitabile. Un approccio migliore risponde a una progettazione scadente tramite il refactoring. In Lavorando efficacemente con il codice legacy , Michael Feathers postula la sua definizione di codice legacy: "[L] il codice di egacy è semplicemente codice senza test. " Scrivere codice che può essere testato è spesso anche ben progettato. Migliora il design scadente anziché ricominciare.
  3. Revisioni del codice : il modo più rapido per imparare a progettare bene i componenti è che qualcuno con più esperienza spieghi che stai sbagliando e perché tu stai sbagliando. Il team deve condividere la proprietà per la qualità ed essere spietato con il codice degli altri. Leggi i migliori segreti di codici peer . Avvia revisioni di codice pre-commit spietate, approfondite per tutte le modifiche.

Modifica

Diventare capaci di fornire un design di applicazione di qualità richiede molto tempo. Leggi Ti insegnerai a programmare in dieci anni di Peter Norvig.

    
risposta data 05.04.2011 - 15:25
fonte
2

Penso che sia necessario fare una chiara distinzione tra design dell'applicazione e progettazione del sistema (ideando l'architettura di un'applicazione).

Il design dell'applicazione è ciò che vedi dall'esterno. Riguarda il design delle caratteristiche, la progettazione dell'esperienza utente e persino le decisioni di marketing (strategie di implementazione e monetizzazione). Ovviamente il design delle applicazioni non può ignorare i limiti tecnici, ma tenerne conto è la parte in cui quasi tutti hanno ragione, mentre tutto il resto è, quante persone sbagliano.

Il design del sistema è probabilmente ciò che intendi. Riguarda la dissezione di un'applicazione in unità indipendenti (livelli, servizi e altri moduli), in base alla progettazione dell'applicazione e quindi reiterando questo passaggio fino a quando non vengono lasciate unità gestibili.

La chiave per la progettazione flessibile del sistema è l'accoppiamento basso, che si ottiene nascondendo le informazioni, una parte è l'incapsulamento (cioè legando dettagli di implementazione cattivi e fragili in oggetti robusti) e l'altro astrazione (ovvero scegliere di non dipendere da un modulo concreto, ma la più piccola astrazione possibile di esso).

Ad esempio, se si dispone di un DataStore di classe, fornendo accesso agli utenti e alle immagini memorizzate, agendo quindi come IUserStore e come IPictureStore, si desidera che i singoli renderer dipendano da tali astrazioni e inject l'implementazione. Perché a un certo punto potresti decidere di mantenere i tuoi dati utente sul tuo server, ma di memorizzare le tue foto con alcuni servizi cloud di terze parti, il che significa che dividere il DataStore in due classi potrebbe essere necessario. Tutti i componenti che dipendono esclusivamente dalle astrazioni non sono interessati.

Quello che vuoi è un sistema, in cui singoli componenti possono essere modificati in isolamento, senza effetti sul sistema.
L'unica domanda che ti rimane da rispondere è quando considerare un componente stesso come un sistema e per modularlo ulteriormente e quando fermarsi. Il SRP è una regola radicale, ma è difficile da rispettare.
Preferisco un approccio più pragmatico. Finché un componente è facile da afferrare, lasciatelo così com'è. Quando cresce oltre un punto, dove puoi capirlo entro un minuto o reimplementarlo in mezza giornata, è il momento di individuare e isolare le responsabilità individuali.

Ma questa è una linea da disegnare per te, ed è qualcosa che accade naturalmente sul campo.

Quindi riassumendo:

  • Non astrarre prima dei requisiti. Usa le astrazioni per esprimere i requisiti in modo chiaro ed esatto, mantenendoli semplici ed evidenti.
  • Non modularizzare prima della complessità. Naturalmente mantieni insieme ciò che è semplice e analizza ciò che è complesso.
  • Non implementare prima delle astrazioni. Non fare supposizioni inutili, dipende dalle astrazioni, piuttosto che dai dettagli.
risposta data 05.04.2011 - 14:18
fonte

Leggi altre domande sui tag