Hier zijn eerst mijn 2 regels om het Framework Waste Syndroom te voorkomen:

• De afwezigheid van een bestaande, die 80% van de mijn behoeften en uitbreidbaar om te voldoen aan de laatste 20%
• De nabije zekerheid dat ik het opnieuw zal gebruiken, in een andere applicatie.

Als je die hebt gehaald, kijk dan eens naar:

• 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

Opmerkingen

• Ik zou eraan willen toevoegen dat als je ‘ geen raamwerk kunt vinden dat voldoet aan je 80/20-regel, je ofwel werkt in een extreem uniek domein OF je ‘ begrijpt je domein niet goed genoeg.

1) Functies mogen alleen aan een Framework worden toegevoegd als ze uit werkende code zijn gehaald. Met andere woorden, voordat u uw coole nieuwe idee aan uw coole nieuwe framework toevoegt, moet u ervoor zorgen dat het daadwerkelijk waarde toevoegt aan en herhaling vermindert in een werkende, echte applicatie.

2) Documentatie, documentatie, documentatie.

3) Documentatie, documentatie, documentatie.

Pijnlijke ervaring en veel verspilde moeite leid tot dit advies: extraheer of refactor een framework uit werkende software. Bouw die software en houd er rekening mee dat u denkt dat u in de toekomst een framework wilt extraheren, maar “bouw niet eerst het framework.

Ik zou het boek Framework Design Guidelines willen voorstellen. Het is een paar jaar oud, maar de principes blijven waar. Het heeft een heleboel patronen en legt de redenering uit achter de beslissingen die u “zult nemen bij het bouwen van een raamwerk.

1) Houd u vanaf het begin aan goede conventies, zorg ervoor dat u “een zeer specifieke conventie hebt gedocumenteerd, de beste frameworks zijn degene die intern consistent zijn.

2) Zorg ervoor dat alles goed gedocumenteerd is, van goede coderegels helemaal om uit te leggen wat de belangrijkste functies vereisen en produceren, zelfs als het je supereenvoudig lijkt, kan het zijn dat iemand het op het 14e achtereenvolgende uur gebruikt en dat ze dat ene ding nodig hebben op dat moment.

3) Stel een projectopgave voor jezelf op, met wat je wilt dat het raamwerk bereikt, realistische doelen en algemene prioriteiten.

4) Als het beschikbaar komt voor mensen om te gebruiken, zorg er dan voor dat je een vorm van ondersteuningsproces / bug-tracking hebt. Er zullen bugs zijn, het overkomt ons allemaal, maar als je ze vanaf het begin kunt beheren, zal het je leven gemakkelijker maken.

Al met al een vergelijkbare benadering voor het bouwen van een applicatie, maar ontwikkelaars zijn nog drukker dan gebruikers, en de beste frameworks zijn degene die we kunnen oppikken, begrijpen en waar we niet voor hoeven te vechten.

Ik ben het niet eens met veel van wat er is gezegd en ik heb het gevoel dat er meer niet wordt genoemd, dus ik zal helemaal opnieuw beginnen.

Agile Methodologieën

Pas agile methodologieën toe tijdens de ontwikkeling van uw framework, zodat u zich kunt aanpassen aan veranderingen, snel kunt reageren op obstakels en een functioneel eindproduct van hoge kwaliteit kunt garanderen. Agile-methodologieën zijn methodologieën die volgens het “Agile Manifesto” prioriteit geven aan:

Individuen en interacties boven processen en tools
Werkende software over uitgebreide documentatie
Klantensamenwerking over contractonderhandelingen
Reageren op verandering over volgens een plan

Dat klopt. Ik zei dat functionaliteit belangrijker is dan documentatie. Merk op dat het “Agile Manifesto” vermeldt dat de rechterprioriteiten nog steeds belangrijk zijn, alleen minder dan die aan de linkerkant.

Communicatie

Wie het framework maakt, moet weten:

1. Hoe het zal worden gebruikt: de doeltoepassing
2. Welk probleem is bedoeld om op te lossen: het doelprobleem
3. Wie gaat het gebruiken: de doelgroep

Als een bedrijf bijvoorbeeld van plan was een laatste applicatie met ASP .NET te ontwikkelen, zou het dwaas zijn om zijn programmeurs te vertellen “maak dit framework” zonder hen het bovenstaande te vertellen. Als de programmeurs de doeltoepassing niet kenden, zouden ze deze misschien niet webgericht maken. Als ze het probleem niet kenden, zouden ze een raamwerk kunnen maken voor een ander doel. Als ze het publiek niet kenden, zouden ze het raamwerk in C ++ kunnen programmeren. Elk van deze omstandigheden zou het resulterende raamwerk onbruikbaar maken.

Stijl

Het behoeft geen betoog dat een programmeerstijl moet worden vastgesteld / format en blijf erbij.

The E “s

1. Modulariteit : hergebruik code programmatisch, niet letterlijk.
2. efficiëntie : uw code is bedoeld voor hergebruik . Eventuele nadelige gevolgen voor snelheid worden vermenigvuldigd.
3. Onderhoudbaarheid : u wilt het framework kunnen bewerken naar update verschillende programmas, zonder de genoemde programmas te hoeven wijzigen.
4. Bruikbaarheid : Kunnen applicaties uw framework daadwerkelijk gebruiken? zonder door hoepels te springen?
5. Praktisch : vind het wiel niet opnieuw uit als je dat niet hebt om dat te doen. Uw framework kan afhankelijk zijn van andere frameworks.
6. Redundantie : ontdek uitzonderingen / fouten. Overal. Hou ze onder controle. Overal. Vertrouw nooit enige code behalve die in de lokale scope om fouten af te handelen, zelfs als u weet dat dit het geval is.

Reacties

• Welkom naar P.SE! Ik ‘ ben het niet eens met # 6 over het opvangen van uitzonderingen in je framework. Ik ‘ ben er een groot voorstander van dat het framework een absolute snotaap moet zijn en uitzonderingen moet maken en het aan de programmeur overlaat om het framework te gebruiken om ze te vangen of (beter nog) hun code zo te heroriënteren om de uitzondering te vermijden – conventieconformiteit aanmoedigen.

Ik weet zeker dat er een verschil is tussen de ontwikkeling van een framework of bibliotheek en een applicatie.

Ontwikkelingsprocessen zijn in wezen hetzelfde. verschillen kunnen te maken hebben met marketing- en implementatieproblemen, hoewel ik vind dat de grootste verschillen meestal zijn in termen van projectomvang en -definitie. Onthoud dat een applicatie een framework of een bibliotheek kan bevatten of gebruiken, een framework kan een verzameling bibliotheken zijn.

Ik heb enige twijfels over hoe ik de organisatie en het beheer van dat project moet aanpakken: zijn er enkele algemene regels voor llow, tips, best practices of iets om in gedachten te houden bij het ontwikkelen van dit soort projecten?

Projectorganisatie en -beheer zijn weer hetzelfde voor elk ontwikkelingsproject . Opnieuw komt het aan op de reikwijdte. Als het echter aankomt op het schrijven van een raamwerk, loont het om een zeer duidelijke visie te hebben over wat u probeert te bereiken, en om strikte ontwerpregels op de openbare interface van het raamwerk te plaatsen om consistentie in termen van de APIs te garanderen. presentatie. Als je elke ontwikkelaar zijn eigen ding laat doen, krijg je een ingewikkelde puinhoop en een zeer onelegant API-ontwerp.

Ik “ll tweede Ryan Hayes” aanbeveling om Framework Design Guidelines ook al is het boek zelf gericht op het ontwikkelen van .NET-gebaseerde frameworks, omdat het algemene advies van toepassing is ongeacht de specifieke implementatietechnologieën die u zou kunnen gebruiken.

Uit ervaring zou ik adviseren om vast te houden aan het klassieke YAGNI-principe door eerst de meest simplistische openbare interfaces te implementeren en vervolgens uit te breiden om later meer controle en diepgang te bieden, maar wees voorzichtig met het gebruik van bruikbare namen om te laten zien waarom methoden of klassen worden uitgebreid. Ik ben nooit een fan geweest van het toevoegen van “Ex” of andere soortgelijke achtervoegsels aan methodenamen, of het toevoegen van getallen aan uitgebreide interfacedefinities. Maak onderscheid op functionaliteit, en je interface- / methodenamen zouden duidelijker moeten worden, en hopelijk minder verdoezeld en verwarrend.