Först här är mina två regler för att undvika ramavfallssyndrom:

• Frånvaron av en befintlig, som täcker 80% av mina behov och kan utökas för att matcha de senaste 20%
• The near säkerhet att jag kommer att använda den igen, i en annan applikation

När du har klarat dem, kolla in det här:

• 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

Kommentarer

• Jag tillägger att om du kan ’ inte hittar ett ramverk som uppfyller din 80/20 regel antingen arbetar du på en extremt unik domän ELLER förstår du inte ’.

Smärtsam upplevelse och mycket slösad ansträngning leda till detta råd: extrahera eller omformulera ett ramverk från fungerande programvara. Bygg den programvaran med tanke på att du tror att du vill extrahera ett ramverk i framtiden, men bygg inte ramverket först.

1) Håll dig till goda konventioner redan från början, se till att du har dokumenterat en mycket specifik konvention, de bästa ramarna är de som är internt konsekventa.

2) Se till att allt är mycket dokumenterat, från bra kodkommentarer hela vägen för att förklara vad de viktigaste funktionerna kräver och producerar, även om det verkar super enkelt för dig kanske du får någon att använda den på 14: e raka timmen och de behöver den ena saken just då.

3) Sätt upp en projektinformation för dig själv, med vad du vill att ramen ska uppnå, realistiska mål och övergripande prioriteringar.

4) Om det kommer att finnas tillgängligt för människor att använda, se till att du har någon form av supportprocess / felspårning på plats. Det kommer att bli buggar, det händer oss alla, men om du kan hantera dem från början kommer det att göra ditt liv enklare.

Sammantaget liknar man att bygga alla applikationer, men utvecklare är ännu krångligare än användarna, och de bästa ramarna är de som vi kan plocka upp, förstå, och vi behöver inte slåss.

Jag håller inte med mycket av det som har sagts och jag känner att mer har blivit omnämnda så jag börjar från början.

Agila metoder

Anta smidiga metoder under din ramutveckling så att du kan anpassa dig till förändringar, reagera snabbt på spärrar och säkerställa en funktionell, kvalitativ slutprodukt. Agila metoder är de som enligt ”Agile Manifesto” prioriterar:

Individer och interaktioner över processer och verktyg
Arbetsprogramvara över omfattande dokumentation
Kundsamarbete över kontraktsförhandlingar
Svara på förändring över efter en plan

Det stämmer. Jag sa att funktionalitet är viktigare än dokumentation. Observera att ”Agile Manifesto” nämner att de högra prioriteringarna fortfarande är viktiga, bara mindre än de till vänster.

Kommunikation

Den som skapar ramverket behöver veta:

1. Hur den kommer att användas: målapplikation
2. Vilket problem det är tänkt att lösa: målproblem
3. Vem ska använda den: målgruppen

Till exempel, om ett företag tänkte utveckla en slutlig applikation med ASP .NET skulle det vara dumt att säga till sina programmerare att ”göra detta ramverk” utan att berätta för dem ovan. Om programmerarna inte kände till målapplikationen skulle de kanske inte göra den webbinriktad. Om de inte visste problemet kan de skapa en ram för ett annat syfte. Om de inte kände publiken kunde de programmera ramverket i C ++. Någon av dessa omständigheter skulle göra det resulterande ramverket värdelöst.

Style

Det är självklart att skapa en programmeringsstil / format och hålla fast vid det.

E ”s

1. Modularitet : Återanvänd kod programmatiskt, inte bokstavligen.
2. Effektivitet : Din kod är avsedd för återanvändning . Eventuella skador på hastigheten multipliceras.
3. Underhållsförmåga : Du vill kunna redigera ramverket till uppdatera flera program utan att behöva modifiera nämnda program.
4. Användbarhet : Kan applikationer faktiskt använda ditt ramverk utan att hoppa genom bågarna?
5. Praktik : Inte uppfinna hjulet om du inte har att göra så. Ditt ramverk kan bero på andra ramar.
6. Redundans : Fånga undantag / fel. Överallt. Hantera dem. Överallt. Lita aldrig på någon kod utom den i det lokala omfånget för att hantera fel, även om du vet att den gör det.

Kommentarer

• Välkommen till P.SE! Jag ’ Jag är inte överens med w / # 6 om att fånga undantag inom ditt ramverk. Jag ’ är mycket övertygad om att ramverket ska vara ett absolut brat och kasta undantag och lämna det upp till programmeraren som använder ramverket för att fånga dem eller (ännu bättre) omorientera deras kod så för att undvika undantaget – uppmuntra konventionens överensstämmelse.

Jag är säker på att det finns någon skillnad mellan utvecklingen av ett ramverk eller ett bibliotek och en applikation.

Utvecklingsprocesserna är i stort sett desamma. skillnader kan komma ner till marknadsförings- och distributionsproblem, även om jag tycker att de största skillnaderna vanligtvis är när det gäller projektets omfattning och definition. Kom ihåg att en applikation kan inkludera eller använda ett ramverk eller ett bibliotek, ett ramverk kan vara en samling bibliotek.

Jag tvivlar på hur man hanterar organisationen och hanteringen av det projektet: Finns det några allmänna regler för llow, tips, bästa praxis eller något att tänka på för att utveckla denna typ av projekt?

Projektorganisation och ledning är återigen desamma för alla utvecklingsprojekt . Återigen kommer det till omfattning. När det gäller att skriva ett ramverk lönar det sig dock att ha en mycket tydlig vision om vad det är du försöker uppnå och att placera strikta designregler på det offentliga gränssnittet till ramverket för att säkerställa enhetlighet när det gäller API: s presentation. Om du tillåter varje utvecklare att göra sina egna saker kommer du att få en komplicerad röra och en mycket oelegant API-design.

Jag kommer andra Ryan Hayes ” rekommendation att läsa Riktlinjer för ramkonstruktion även om själva boken syftar till att utveckla .NET-baserade ramar, eftersom de allmänna råd är tillämpliga oavsett de specifika implementeringstekniker som du kan välja att använda.

Av erfarenhet skulle jag rekommendera att hålla fast vid den klassiska YAGNI-principen genom att först implementera de mest förenklade offentliga gränssnitten och sedan expandera för att ge större kontroll och djup senare, men var försiktig med användbara namn för att visa varför metoder eller klasser utvidgas. Jag har aldrig varit ett fan av att lägga till ”Ex” eller andra liknande suffix till metodnamn, eller lägga till nummer till utökade gränssnittsdefinitioner. Differentiera funktionalitet, och ditt gränssnitts- / metodnamn bör bli tydligare och förhoppningsvis mindre förvirrad och förvirrande.