Prima di tutto ecco le mie 2 regole per evitare la sindrome da spreco di struttura:

• Lassenza di una esistente, che copre l80% le mie esigenze ed estendibile per corrispondere allultimo 20%
• Il near certezza che lo userò di nuovo, in unaltra applicazione

Dopo averli passati, controlla questo:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

Commenti

• Aggiungerei che se puoi ‘ t trovare un framework che soddisfi la tua regola 80/20 o stai lavorando in un dominio estremamente unico OPPURE non ‘ comprendi abbastanza bene il tuo dominio.

1) Le funzionalità dovrebbero essere aggiunte a un Framework solo quando vengono estratte dal codice funzionante. In altre parole, prima di aggiungere la tua nuova fantastica idea al tuo nuovo fantastico framework, assicurati che aggiunga effettivamente valore e riduca la ripetizione in unapplicazione funzionante e del mondo reale.

2) Documentazione, documentazione, documentazione.

3) Documentazione, documentazione, documentazione.

Esperienza dolorosa e molti sforzi inutili portare a questo consiglio: estrarre o rifattorizzare un framework dal software funzionante. Crea quel software tenendo presente che pensi di voler estrarre un framework in futuro, ma non creare prima il framework.

Suggerirei il libro Framework Design Guidelines . Ha” un paio di anni, ma i principi rimangono veri. Ha un sacco di schemi e spiega il ragionamento alla base delle decisioni che prenderete durante la creazione di un framework.

1) Attenersi a buone convenzioni fin dallinizio, assicurarsi di aver documentato una convenzione molto specifica, i migliori framework sono quelli che sono internamente coerenti.

2) Assicurati che tutto sia altamente documentato, da buono commenta il codice fino alla spiegazione di cosa richiedono e producono le funzioni più importanti, anche se ti sembra semplicissimo potresti chiedere a qualcuno di usarlo la quattordicesima ora consecutiva e loro hanno bisogno di quella cosa proprio allora.

3) Prepara un brief di progetto per te stesso, con ciò che vuoi che il framework raggiunga, obiettivi realistici e priorità generali.

4) Se sarà disponibile per luso da parte delle persone, assicurati di avere una qualche forma di processo di supporto / tracciamento dei bug in atto. Ci saranno dei bug, capita a tutti noi, ma se riesci a gestirli dallinizio, ti semplificherà la vita.

Tutto sommato, un approccio simile alla creazione di qualsiasi applicazione, ma gli sviluppatori sono ancora più pignoli degli utenti e i framework migliori sono quelli che possiamo raccogliere, dare un senso e non dobbiamo combattere.

Non sono daccordo con molto di quanto è stato detto e sento che di più non è stato menzionato, quindi comincerò da zero.

Metodologie agili

Adotta metodologie agili durante lo sviluppo del tuo framework in modo da poterti adattare ai cambiamenti, reagire rapidamente agli ostacoli e garantire un prodotto finale funzionale e di qualità. Le metodologie agili sono quelle che, secondo il “Manifesto Agile”, danno la priorità a:

Individui e interazioni su processi e strumenti
Software funzionante oltre documentazione completa
Collaborazione con il cliente oltre negoziazione del contratto
Rispondere al cambiamento oltre seguendo un piano

Esatto. Ho detto che la funzionalità è più importante della documentazione. Nota che il “Manifesto Agile” menziona che le priorità della mano destra sono ancora importanti, solo meno di quelli a sinistra.

Comunicazione

Chiunque stia realizzando il framework deve sapere:

1. Come verrà utilizzato: il applicazione di destinazione
2. Quale problema intende risolvere: il problema di destinazione
3. Chi lo utilizzerà: il pubblico di destinazione

Per esempio, se unazienda avesse intenzione di sviluppare unapplicazione finale con ASP .NET, sarebbe sciocco dire ai suoi programmatori “crea questo framework” senza dirgli quanto sopra. Se i programmatori non conoscessero lapplicazione di destinazione, potrebbero non renderla orientata al Web. Se non conoscessero il problema, potrebbero creare un framework per uno scopo diverso. Se non conoscessero il pubblico, potrebbero programmare il framework in C ++. Ognuna di queste circostanze renderebbe inutile il framework risultante.

Stile

Inutile dire che stabilisci uno stile di programmazione / format e rispettalo.

La E “s

1. Modularità : riutilizza il codice in modo programmatico, non letteralmente.
2. Efficienza : il tuo codice è destinato al riutilizzo . Eventuali danni alla velocità vengono moltiplicati.
3. Manutenibilità : si desidera poter modificare il framework per aggiorna diversi programmi, senza doverli modificare.
4. Usabilità : le applicazioni possono effettivamente utilizzare il tuo framework senza fare salti mortali?
5. Praticità : non reinventare la ruota se non ce lhai fare così. Il tuo framework può dipendere da altri framework.
6. Ridondanza : individua eccezioni / errori. Ovunque. Gestiscili. Ovunque. Non fidarti mai di alcun codice tranne quello nellambito locale per gestire gli errori, anche se sai che lo fa.

Commenti

• Benvenuto a P.SE! ‘ non sono daccordo con # 6 sul rilevamento delle eccezioni nel tuo framework. Sono ‘ un grande sostenitore del fatto che il framework dovrebbe essere un monello assoluto e lanciare eccezioni e lasciare che sia il programmatore che usa il framework per catturarli o (meglio ancora) riorientare il loro codice in modo per evitare leccezione, incoraggiando la conformità alle convenzioni.

Sono sicuro che ci siano alcune differenze tra lo sviluppo di un framework o di una libreria e unapplicazione.

I processi di sviluppo sono essenzialmente gli stessi. le differenze possono dipendere da problemi di marketing e distribuzione, anche se trovo che le differenze maggiori siano di solito in termini di ambito e definizione del progetto.Ricorda che unapplicazione può includere o utilizzare un framework o una libreria, un framework può essere una raccolta di librerie.

Ho qualche dubbio su come gestire lorganizzazione e la gestione di quel progetto: ci sono alcune regole generali per llow, suggerimenti, best practice o qualcosa da tenere a mente per lo sviluppo di questo tipo di progetto?

Lorganizzazione e la gestione del progetto sono ancora le stesse per qualsiasi progetto di sviluppo . Ancora una volta si tratta di scopo. Quando si tratta di scrivere un framework, tuttavia, vale la pena avere una visione molto chiara di ciò che si sta cercando di ottenere e di inserire regole di progettazione rigorose sullinterfaccia pubblica del framework per garantire la coerenza in termini di API “s presentazione. Se permetti a ogni sviluppatore di fare le proprie cose, ti ritroverai con un pasticcio complicato e un design API molto poco elegante.

Secondo Ryan Hayes “ raccomandazione di leggere le Linee guida per la progettazione del framework anche se il libro stesso è finalizzato allo sviluppo di framework basati su .NET, perché il consiglio generale è applicabile indipendentemente dalle specifiche tecnologie di implementazione che potresti scegliere di utilizzare.

Per esperienza, consiglierei di attenersi a il classico principio YAGNI implementando prima le interfacce pubbliche più semplicistiche e poi espandendosi per offrire maggiore controllo e profondità in seguito, ma attenzione a usare nomi utili per mostrare perché i metodi o le classi vengono espansi. Non sono mai stato un fan dellaggiunta di “Ex” o di altri suffissi simili ai nomi dei metodi, o dellaggiunta di numeri alle definizioni di interfaccia espanse. Differenziare le funzionalità e i nomi di interfaccia / metodo dovrebbero diventare più chiari e, si spera, meno offuscati e confusi.