Nejprve zde jsou moje 2 pravidla, jak se vyhnout syndromu plýtvání rámcem:

• Absence stávajícího, pokrývající 80% moje potřeby a rozšiřitelné tak, aby odpovídaly posledním 20%
• blízko jistotu, že ji znovu použiji, v jiné aplikaci

Poté, co jste je předali, zkontrolujte toto:

• 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

Komentáře

• Dodal bych, že pokud ‚ nenajdete rámec, který splňuje vaše pravidlo 80/20, ať už pracujete v extrémně jedinečné doméně NEBO ‚ vaší doméně dostatečně nerozumíte.

1) Funkce by měly být přidány do rámce, pouze pokud jsou extrahovány z pracovního kódu. Jinými slovy, než přidáte svůj skvělý nový nápad do svého skvělého nového rámce, ujistěte se, že ve skutečnosti přidává hodnotu a snižuje opakování v fungující aplikaci v reálném světě.

2) Dokumentace, dokumentace, dokumentace.

3) Dokumentace, dokumentace, dokumentace.

Bolestná zkušenost a spousta zbytečného úsilí vést k této radě: extrahovat nebo refaktorovat rámec z pracovního softwaru. Vytvořte si tento software a mějte na paměti, že si myslíte, že v budoucnu budete chtít rámec extrahovat, ale nejdříve jej nevytvářejte.

Navrhuji knihu Pokyny pro návrh rámce . Je to pár let staré, ale zásady zůstávají pravdivé. Má spoustu vzorů a vysvětluje důvody rozhodnutí, která „učiníte při vytváření rámce.

1) Držte se dobré konvence hned od začátku, ujistěte se, že jste dokumentovali velmi konkrétní konvenci, nejlepší rámce jsou ty, které jsou interně konzistentní.

2) Ujistěte se, že je vše dobře zdokumentováno, od dobrého komentáře k kódu až po vysvětlení toho, co nejdůležitější funkce vyžadují a produkují, i když se vám to zdá super jednoduché, můžete si nechat někoho použít 14. hodinu po sobě a potřebuje tuto jedinou věc hned poté.

3) Stanovte si projekt, který vám bude stručně představen, s tím, co má rámec dosáhnout, realistickými cíli a celkovými prioritami.

4) Pokud to bude pro lidi dostupné, ujistěte se, že máte zavedenou nějakou formu procesu podpory / sledování chyb. Budou se vyskytovat chyby, to se stane každému z nás, ale pokud je dokážete spravovat z místa, „usnadní vám to život.

Celkově vzato, podobný přístup k vytváření jakékoli aplikace, ale vývojáři jsou ještě hůř než uživatelé a nejlepší rámce jsou ty, které dokážeme zachytit, pochopit a nemusíme bojovat.

Nesouhlasím se spoustou toho, co bylo řečeno, a mám pocit, že toho bylo ponecháno více, takže začnu od nuly.

Agilní metodiky

Při vývoji rámce přijměte agilní metodiky, abyste se mohli přizpůsobit změnám, rychle reagovat na překážky a zajistit funkční a kvalitní finální produkt. Agilní metodiky jsou ty, které podle „Agilního manifestu“ upřednostňují:

Jednotlivci a interakce nad procesy a nástroje
Pracovní software over komplexní dokumentace
Spolupráce se zákazníky over vyjednávání smlouvy
Reakce na změnu over podle plánu

To je pravda. Řekl jsem, že funkčnost je důležitější než dokumentace. Všimněte si, že „Agilní manifest“ zmiňuje, že pravostranné priority jsou stále důležité, o to méně než ti nalevo.

Komunikace

Kdokoli vytváří rámec, musí vědět:

1. Jak bude použit: cílová aplikace
2. Jaký problém má vyřešit: cílový problém
3. kdo to bude používat: cílové publikum

Například pokud by společnost měla v úmyslu vyvinout finální aplikaci s ASP .NET, bylo by pošetilé říct svým programátorům „make this framework“, aniž by jim řekli výše. Pokud programátoři neznají cílovou aplikaci, nemusí ji dělat webově orientovanou. Pokud neznají problém, mohou vytvořit rámec pro jiný účel. Pokud by neznali publikum, mohli by programovat framework v C ++. Každá z těchto okolností by způsobila, že výsledný framework by byl nepoužitelný.

Styl

Není třeba říkat, vytvořit styl programování / formát a držte se ho.

E „s

1. Modularita : Opětovné použití kódu programově, nikoli doslovně.
2. Účinnost : Váš kód je určen k opětovnému použití . Jakékoli poškození rychlosti se znásobí.
3. Udržovatelnost : Chcete mít možnost upravit rámec tak, aby aktualizujte několik programů, aniž byste museli tyto programy upravovat.
4. Použitelnost : Mohou aplikace skutečně používat váš rámec aniž byste skákali přes obruče?
5. Praktičnost : Neobjevujte znovu kolo, pokud nemáte udělat to tak. Váš rámec může záviset na jiných rámcích.
6. Redundance : Chyťte výjimky / chyby. Všude. Zacházejte s nimi. Všude. Nikdy nedůvěřujte žádnému kódu kromě toho v místním oboru, který by zpracovával chyby, i když víte, že ano.

Komentáře

• Vítejte na P.SE! I ‚ ne souhlasím w / # 6 s chytáním výjimek ve vašem rámci. ‚ Jsem velkým zastáncem toho, že rámec by měl být absolutní spratek a házet výjimky a ponechat to na programátorovi, který jej používá, aby je zachytil nebo (ještě lépe) přeorientoval svůj kód tak, aby se zabránilo výjimce – podpora souladu s konvencemi.

Jsem si jist, že existují určité rozdíly mezi vývojem rámce nebo knihovny a aplikace.

Vývojové procesy jsou v zásadě stejné. rozdíly mohou přijít až k problémům s marketingem a nasazením, i když jsem zjistil, že největší rozdíly jsou obvykle z hlediska rozsahu a definice projektu. Pamatujte, že aplikace může zahrnovat nebo používat rámec nebo knihovnu, rámec může být sbírkou knihoven.

Mám pochybnosti o tom, jak zvládnout organizaci a správu tohoto projektu: Existují nějaká obecná pravidla pro Postup, tipy, osvědčené postupy nebo něco, na co byste měli pamatovat při vývoji tohoto druhu projektu?

Organizace a řízení projektu jsou pro všechny vývojové projekty opět stejné. . Opět jde o rozsah. Pokud jde o psaní rámce, vyplatí se mít velmi jasnou vizi toho, čeho se snažíte dosáhnout, a umístit přísná pravidla návrhu na veřejné rozhraní k rámci, aby byla zajištěna konzistence ve smyslu API Pokud dovolíte každému vývojáři, aby si udělal svou vlastní věc, skončíte s komplikovaným nepořádkem a velmi neelegantním designem API.

Budu sekundovat Ryanovi Hayesovi doporučení přečíst Pokyny k návrhu rámce i když je samotná kniha zaměřena na vývoj rámců založených na .NET, protože obecná rada je použitelná bez ohledu na konkrétní implementační technologie, které byste se mohli rozhodnout použít.

Ze zkušeností bych doporučil držet se klasický princip YAGNI tím, že nejprve implementujete nejjednodušší veřejná rozhraní a poté se rozšíříte, abyste později nabídli větší kontrolu a hloubku, ale buďte opatrní a použijte užitečné názvy, abyste ukázali, proč se metody nebo třídy rozšiřují. Nikdy jsem nebyl příznivcem přidávání výrazů „Ex“ nebo jiných podobných přípon k názvům metod nebo přidávání čísel k rozšířeným definicím rozhraní. Diferenciujte funkčnost a názvy rozhraní / metody by měly být jasnější a snad méně zmatené a matoucí.