Innanzitutto ecco le mie 2 regole per evitare la sindrome da spreco quadro:

• L'assenza di uno esistente, che copre l'80% delle mie esigenze ed è estensibile per abbinare l'ultimo 20%
• La quasi certezza che lo userò di nuovo, in un'altra applicazione

Dopo averli passati, controlla questo:

• link
• link
• link

1) Le caratteristiche 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 valore e riduca la ripetizione in un'applicazione funzionante e reale.

2) Documentazione, documentazione, documentazione.

3) Documentazione, documentazione, documentazione.

Un'esperienza dolorosa e molti sforzi inutili portano a questo consiglio: estrai o rifatti un quadro dal software funzionante. Costruisci quel software tenendo presente che pensi di voler estrarre un framework in futuro, ma non creare prima il framework.

Suggerirei il libro Linee guida per la progettazione di quadri . Ha un paio di anni, ma i principi rimangono veri. Ha un sacco di schemi e spiega il ragionamento dietro le decisioni che prenderai quando costruirai un framework.

1) Aderisci alle buone convenzioni fin dall'inizio, assicurati di aver documentato una convenzione molto specifica, i migliori framework sono quelli internamente coerenti.

2) Assicurati che tutto sia altamente documentato, dai buoni commenti al codice fino alla spiegazione di ciò che le funzioni più importanti richiedono e producano, anche se ti sembra super semplice potresti averne qualcuno che la usa al 14 ° rettilineo ora e hanno appena bisogno di una cosa in quel momento.

3) Stabilisci un brief di progetto per te stesso, con ciò che desideri ottenere dal framework, obiettivi realistici e priorità generali.

4) Se sarà disponibile per le persone, assicurati di avere qualche forma di supporto / tracciamento dei bug in atto. Ci saranno dei bug, succede a tutti noi, ma se riesci a gestirli da subito ti renderà la vita più facile.

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

Non sono d'accordo con molto di ciò che è stato detto e sento che più è stato lasciato non menzionato quindi inizierò da zero.

Metodologie agili

Adottare metodologie agili durante lo sviluppo del framework in modo da poter adattarsi ai cambiamenti, reagire rapidamente ai blocchi stradali e garantire un prodotto finale funzionale e di qualità. Le metodologie agili sono quelle che, in base al "Manifesto Agile", stabiliscono la priorità:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

È vero. Ho detto che la funzionalità è più importante della documentazione. Nota che il "Manifesto Agile" afferma che le priorità della mano destra sono ancora importanti, meno di quelle a sinistra.

Comunicazione

Chiunque stia costruendo il framework deve sapere:

1. Come verrà utilizzato: l'applicazione di destinazione
2. Quale problema è destinato a risolvere: il problema dell'obiettivo
3. Chi lo utilizzerà: il pubblico di destinazione

Ad esempio, se un'azienda intendesse sviluppare un'applicazione finale con ASP.NET sarebbe sciocco dire ai propri programmatori "creare questo framework" senza dirgli quanto sopra. Se i programmatori non conoscevano l'applicazione di destinazione, potrebbero non renderla orientata al web. Se non conoscessero il problema, potrebbero creare un quadro per uno scopo diverso. Se non conoscessero il pubblico, potrebbero programmare il framework in C ++. Ognuna di queste circostanze renderebbe la struttura risultante inutile.

Stile

Inutile dire che stabilisci uno stile / formato di programmazione e mantienilo.

Le E

1. Modularità : riusa il codice a livello di codice, non letteralmente.
2. Efficienza : il tuo codice è destinato al riutilizzo. Qualsiasi danno alla velocità viene moltiplicato.
3. Manutenibilità : vuoi essere in grado di modificare il framework per aggiornare diversi programmi, senza dover modificare i suddetti programmi.
4. Usabilità : le applicazioni possono effettivamente utilizzare il framework senza saltare i cerchi?
5. Praticità : non reinventare la ruota se non è necessario. Il tuo framework può dipendere da altri framework.
6. Ridondanza : ammette eccezioni / errori. Ovunque. Gestirli. Ovunque. Non fidarti mai di alcun codice, ma quello nello scope locale per gestire gli errori, anche se sai che lo fa.

I'm sure there are some difference between the development of a framework or library and an application.

I processi di sviluppo sono essenzialmente gli stessi. Le differenze possono arrivare a problemi di marketing e di implementazione, anche se trovo che le maggiori differenze sono di solito in termini di portata e definizione del progetto. Ricorda che un'applicazione può includere o utilizzare un framework o una libreria, un framework può essere una raccolta di librerie.

I have some doubts about how to handle the organization and managment of that project: Are there some general rules to follow, tips, best practices or something to keep in mind for developing this kind of project?

L'organizzazione e la gestione del progetto sono ancora le stesse per qualsiasi progetto di sviluppo. Di nuovo si tratta di portata. Quando si tratta di scrivere un framework, tuttavia, è utile avere una visione molto chiara di ciò che si sta tentando di ottenere e inserire regole di progettazione rigorose nell'interfaccia pubblica al framework per garantire la coerenza in termini di presentazione dell'API. Se permetti a ogni sviluppatore di fare le sue cose, finirai con un pasticcio complicato e un design API poco elegante.

Seguirò la raccomandazione di Ryan Hayes per leggere Firework Design Guidelines 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.

Dall'esperienza, consiglierei di attenersi al classico principio di YAGNI implementando prima le interfacce pubbliche più semplicistiche e poi espandendole per offrire maggiore controllo e profondità in seguito, ma fai attenzione a usare nomi utili per mostrare perché i metodi o le classi sono essendo espanso. Non sono mai stato entusiasta di aggiungere "Ex" o altri suffissi simili ai nomi dei metodi o di aggiungere numeri alle definizioni di interfaccia espanse. Differenzia sulla funzionalità e i nomi dell'interfaccia / metodo dovrebbero diventare più chiari e, auspicabilmente, meno offuscati e confusi.