Først her er mine to regler for å unngå rammeavfallssyndrom:

• Fraværet av en eksisterende, som dekker 80% av mine behov og kan utvides for å matche de siste 20%
• Det nære sikkerhet for at jeg vil bruke den igjen, i et annet program

Etter at du har bestått disse, sjekk dette:

• 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

• Jeg vil legge til at hvis du kan ‘ ikke finner et rammeverk som oppfyller 80/20-regelen din enten du jobber i et ekstremt unikt domene ELLER forstår du ikke ‘ domenet ditt godt nok.

Smertefull erfaring og mye bortkastet innsats føre til dette rådet: trekk ut eller refaktorere et rammeverk fra arbeidsprogramvaren. Bygg den programvaren med tanke på at du tror du vil ønske å hente ut et rammeverk i fremtiden, men ikke bygg rammeverket først.

1) Hold deg til gode konvensjoner helt fra starten, sørg for at du har dokumentert en veldig spesifikk konvensjon, de beste rammene er de som er internt konsistente.

2) Sørg for at alt er høyt dokumentert, fra godt kode kommentarer hele veien gjennom for å forklare hva de viktigste funksjonene krever og produserer, selv om det virker superenkelt for deg, kan du få noen til å bruke den på den 14. rette timen, og de bare trenger den ene tingen akkurat da.

3) Sett ut en prosjektoppgave for deg selv, med hva du vil at rammeverket skal oppnå, realistiske mål og overordnede prioriteringer.

4) Hvis det kommer til å være tilgjengelig for folk å bruke, må du sørge for at du har en eller annen form for støtteprosess / feilsporing på plass. Det kommer til å være feil, det skjer med oss alle, men hvis du klarer dem fra begynnelsen av, vil det gjøre livet ditt enklere.

Alt i alt en lignende tilnærming til å bygge en applikasjon, men utviklere er enda mer opptatt enn brukerne, og de beste rammene er de vi kan plukke opp, gi mening, og vi trenger ikke kjempe.

Jeg er uenig i mye av det som er blitt sagt, og jeg føler at mer har blitt igjen nevnt, så jeg begynner helt fra bunnen av.

Agile Methodologies

Vedta smidige metoder under rammeverksutviklingen din, slik at du kan tilpasse deg endringer, reagere raskt på sperringer og sikre et funksjonelt kvalitets sluttprodukt. Agile metoder er de som, ifølge «Agile Manifesto», prioriterer:

Individer og interaksjoner over prosesser og verktøy
Arbeidsprogramvare over omfattende dokumentasjon
Kundesamarbeid over kontraktsforhandlinger
Svar på endring over etter plan

Det stemmer. Jeg sa at funksjonalitet er viktigere enn dokumentasjon. Vær oppmerksom på at «Agile Manifesto» nevner at høyre prioriteringer fremdeles er viktige, bare mindre enn de til venstre.

Kommunikasjon

Den som lager rammeverket trenger å vite:

1. Hvordan den skal brukes: målapplikasjon
2. Hvilket problem det er ment å løse: målproblemet
3. Hvem skal bruke den: målgruppen

For eksempel, hvis et selskap hadde tenkt å utvikle en endelig applikasjon med ASP .NET, ville det være dumt å fortelle programmørene sine «lage dette rammeverket» uten å fortelle dem det ovennevnte. Hvis programmererne ikke kjente målapplikasjonen, gjorde de det kanskje ikke nettorientert. Hvis de ikke visste problemet, kan de lage et rammeverk for et annet formål. Hvis de ikke kjente publikum, kunne de programmere rammeverket i C ++. Noen av disse omstendighetene ville gjøre det resulterende rammeverket ubrukelig.

Style

Unødvendig å si, etablere en programmeringsstil / format og hold deg til det.

E «s

1. Modularitet : Gjenbruk kode programmatisk, ikke bokstavelig.
2. Effektivitet : Koden din er ment for gjenbruk . Eventuelle skader på hastighet blir multiplisert.
3. Vedlikeholdsevne : Du vil være i stand til å redigere rammeverket til oppdater flere programmer uten å måtte endre nevnte programmer.
4. Brukbarhet : Kan applikasjoner faktisk bruke rammeverket ditt uten å hoppe gjennom bøyler?
5. Praktisitet : Ikke oppfinne hjulet på nytt hvis du ikke har å gjøre slik. Rammeverket ditt kan avhenge av andre rammer.
6. Redundans : Fang unntak / feil. Overalt. Håndter dem. Overalt. Stol aldri på noen kode, men som i det lokale omfanget, til å håndtere feil, selv om du vet at den gjør det.

Kommentarer

• Velkommen til P.SE! Jeg ‘ jeg er ikke enig. W / # 6 om å fange unntak i ditt rammeverk. Jeg ‘ er veldig troende på at rammeverket skal være et absolutt brat og kaste unntak og overlate det til programmereren som bruker rammeverket for å fange dem eller (enda bedre) omrette koden deres så for å unngå unntaket – oppmuntre konvensjonens samsvar.

Jeg er sikker på at det er noen forskjell mellom utviklingen av et rammeverk eller et bibliotek og en applikasjon.

Utviklingsprosesser er egentlig de samme. forskjeller kan komme ned til markedsførings- og distribusjonsproblemer, selv om jeg finner ut at de største forskjellene vanligvis er når det gjelder prosjektomfang og definisjon. Husk at en applikasjon kan inkludere eller bruke et rammeverk eller et bibliotek, et rammeverk kan være en samling biblioteker.

Jeg er i tvil om hvordan jeg skal håndtere organisering og ledelse av prosjektet: Er det noen generelle regler å llow, tips, best practices eller noe å huske på for å utvikle denne typen prosjekter?

Prosjektorganisasjon og ledelse er igjen de samme for ethvert utviklingsprosjekt . Igjen kommer det ned på omfanget. Når det gjelder å skrive et rammeverk, lønner det seg imidlertid å ha en veldig klar visjon om hva det er du prøver å oppnå, og å plassere strenge designregler på det offentlige grensesnittet til rammeverket for å sikre konsistens når det gjelder API «s presentasjon. Hvis du lar hver utvikler gjøre sine egne ting, vil du ende opp med et komplisert rot, og et veldig uelegant API-design.

Jeg vil andre gang Ryan Hayes « anbefaling om å lese Framework Design Guidelines selv om boken i seg selv er rettet mot å utvikle .NET-baserte rammer, fordi de generelle rådene gjelder uansett de spesifikke implementeringsteknologiene du kan velge å bruke.

Fra erfaring vil jeg anbefale å holde deg til det klassiske YAGNI-prinsippet ved å implementere de mest forenklede offentlige grensesnittene, og deretter utvide for å gi større kontroll og dybde senere, men vær forsiktig med å bruke nyttige navn for å vise hvorfor metoder eller klasser utvides. Jeg har aldri vært fan av å legge til «Ex» eller andre lignende suffikser til metodenavn, eller legge til tall i utvidede grensesnittdefinisjoner. Forskjell funksjonalitet, og grensesnittene / metodene dine skal bli tydeligere, og forhåpentligvis mindre forvirret og forvirrende.