Devo iniziare la progettazione e lo sviluppo di un nuovo framework per interagire con un ECM open source. Ciò include un modello di dati personalizzato per aiutare gli sviluppatori di siti Web a interagire con questo ECM, quindi non devono preoccuparsi dei dettagli sulla manipolazione dei nodi e di altri dettagli di basso livello. Questo è solo un mucchio di classi e metodi da sviluppare.

Ho dei dubbi su come gestire l'organizzazione e la gestione di quel progetto: ci sono alcune regole generali da seguire, suggerimenti, migliori pratiche o qualcosa da tenere a mente per sviluppare questo tipo di progetto?

Sono sicuro che ci sono alcune differenze tra lo sviluppo di un framework o libreria e un'applicazione.

Innanzitutto ecco le mie 2 regole per evitare la sindrome dei rifiuti quadro:

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

Dopo aver superato quelli, 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

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

2) Documentazione, documentazione, documentazione.

3) Documentazione, documentazione, documentazione.

Questa esperienza dolorosa e molti sforzi sprecati portano a questo consiglio: estrarre o riformattare un framework dal software funzionante. Costruisci quel software tenendo presente che pensi che vorrai estrarre un framework in futuro, ma non crearlo prima.

Vorrei suggerire il libro Framework Design Guidelines . Ha un paio d'anni, ma i principi rimangono veri. Ha un sacco di schemi e spiega il ragionamento alla base delle decisioni che prenderai quando costruisci un framework.

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

2) Assicurati che tutto sia altamente documentato, dai buoni commenti in codice fino alla spiegazione di ciò che le funzioni più importanti richiedono e producono, anche se ti sembra super semplice potresti avere qualcuno che lo usi nell'ora 14 di fila e loro ho solo bisogno di quella cosa in quel momento.

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

4) Se sarà disponibile per l'uso da parte delle persone, assicurati di disporre di una qualche forma di processo di supporto / tracciamento dei bug. Ci saranno dei bug, succede a tutti noi, ma se riesci a gestirli da subito ti semplificheremo la vita.

Tutto sommato, un approccio simile alla costruzione di qualsiasi applicazione, ma gli sviluppatori sono anche più agitati 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 ne è stato lasciato di più, quindi inizierò da zero.

Metodologie Agili

Adottare metodologie agili durante lo sviluppo del framework in modo da potersi adattare ai cambiamenti, reagire rapidamente ai blocchi stradali e garantire un prodotto finale funzionale e di qualità. Le metodologie agili sono quelle che, secondo il "Manifesto Agile", danno priorità:

Gli individui e le interazioni più di processi e strumenti di
software di lavoro su vasta documentazione
collaborazione dei clienti nel corso negoziazione dei contratti
Rispondere al cambiamento sopra a seguito di un piano di

Giusto. Ho detto che la funzionalità è più importante della documentazione. Si noti che il "Manifesto Agile" menziona che le priorità della mano destra sono ancora importanti, solo meno di quelle a sinistra.

Comunicazione

Chiunque stia realizzando il framework deve sapere:

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

Ad esempio, se un'azienda intendesse sviluppare un'applicazione finale con ASP .NET, sarebbe sciocco dire ai suoi programmatori "creare questo framework" senza dire loro quanto sopra. Se i programmatori non fossero a conoscenza dell'applicazione 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 quadro risultante.

Stile

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

Le E

1. Modularità : riutilizzare 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 tali programmi.
4. Usabilità : le applicazioni possono effettivamente utilizzare il framework senza saltare attraverso i cerchi?
5. Praticità : non reinventare la ruota se non è necessario farlo. Il tuo framework può dipendere da altri framework.
6. Ridondanza : cattura eccezioni / errori. Ovunque. Gestiscili. Ovunque. Non fidarti mai di alcun codice tranne quello nell'ambito locale per gestire gli errori, anche se sai che è così.

Sono sicuro che ci sono alcune differenze tra lo sviluppo di un framework o libreria e un'applicazione.

I processi di sviluppo sono essenzialmente gli stessi. Le differenze possono dipendere da problemi di marketing e di distribuzione, anche se trovo che le differenze più grandi siano 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.

Ho dei dubbi su come gestire l'organizzazione e la gestione di quel progetto: ci sono alcune regole generali da seguire, suggerimenti, migliori pratiche o qualcosa da tenere a mente per sviluppare questo tipo di progetto?

L'organizzazione e la gestione del progetto sono di nuovo le stesse per qualsiasi progetto di sviluppo. Ancora una volta si riduce al campo di applicazione. Quando si tratta di scrivere un framework, tuttavia, è utile avere una visione molto chiara di ciò che si sta tentando di ottenere e imporre rigide regole di progettazione sull'interfaccia pubblica al framework per garantire coerenza in termini di presentazione dell'API. Se permetti a ogni sviluppatore di fare le proprie cose, finirai con un pasticcio complicato e un design API molto elegante.

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

Per esperienza, consiglierei di attenermi al classico principio YAGNI implementando prima le interfacce pubbliche più semplicistiche, quindi espandendomi per offrire maggiore controllo e profondità in seguito, ma facendo attenzione a usare nomi utili per mostrare perché i metodi o le classi vengono espansi. Non sono mai stato un fan di aggiungere "Ex" o altri suffissi simili ai nomi dei metodi o di aggiungere numeri alle definizioni di interfaccia estese. Differenzia in base alla funzionalità e i nomi delle tue interfacce / metodi dovrebbero diventare più chiari e, si spera, meno offuscati e confusi.