Najpierw są moje dwie zasady unikania syndromu marnotrawstwa ram:

• Brak istniejącego, obejmujący 80% moje potrzeby i możliwość rozszerzenia w celu dopasowania do ostatnich 20%
• blisko pewność, że użyję go ponownie, w innej aplikacji

Po ich zaliczeniu sprawdź to:

• 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

Komentarze

• Dodam, że jeśli potrafisz ' t znaleźć platformę spełniającą twoją regułę 80/20, albo pracujesz w wyjątkowo unikalnej domenie LUB nie ' nie rozumiesz swojej domeny wystarczająco dobrze.

1) Funkcje powinny być dodawane do Framework tylko wtedy, gdy są wyodrębniane z działającego kodu. Innymi słowy, zanim dodasz swój fajny nowy pomysł do swojego nowego, fajnego frameworka, upewnij się, że faktycznie dodaje on wartości i zmniejsza liczbę powtórzeń w działającej, rzeczywistej aplikacji.

2) Dokumentacja, dokumentacja, dokumentacja.

3) Dokumentacja, dokumentacja, dokumentacja.

Bolesne doświadczenie i dużo zmarnowanego wysiłku prowadzą do tej rady: wyodrębnij lub przeredaguj framework z działającego oprogramowania. Zbuduj to oprogramowanie, pamiętając, że myślisz, że w przyszłości będziesz chciał wyodrębnić framework, ale nie twórz najpierw frameworka.

Proponuję książkę Wytyczne dotyczące projektowania ram . Ma kilka lat, ale zasady pozostają aktualne. Zawiera mnóstwo wzorców i wyjaśnia powody decyzji, które podejmiesz podczas tworzenia frameworka.

1) Trzymaj się dobrych konwencji od samego początku, upewnij się, że udokumentowałeś bardzo konkretną konwencję, najlepsze ramy to te, które są wewnętrznie spójne.

2) Upewnij się, że wszystko jest dobrze udokumentowane, od dobrych komentarze do kodu aż do wyjaśnienia, czego wymagają i produkują najważniejsze funkcje, nawet jeśli wydaje ci się to bardzo proste, możesz mieć kogoś, kto użyje go 14 z rzędu i po prostu potrzebuje tej jednej rzeczy właśnie wtedy.

3) Sformułuj dla siebie wytyczne dotyczące projektu, określ, co chcesz osiągnąć w ramach, realistyczne cele i ogólne priorytety.

4) Jeśli będzie dostępny dla ludzi, upewnij się, że masz jakąś formę wsparcia procesu / śledzenia błędów. Pojawią się błędy, zdarza się to każdemu z nas, ale jeśli możesz zarządzać nimi od razu, ułatwi to ci życie.

Podsumowując, podobne podejście do tworzenia dowolnej aplikacji, ale programiści są nawet bardziej zaciekli niż użytkownicy, a najlepsze frameworki to te, które możemy odebrać, nadać im sens i nie musimy z nimi walczyć.

Nie zgadzam się z wieloma z tego, co zostało powiedziane, i uważam, że nie wspomniano o innych, więc zacznę od zera.

Metodyki zwinne

Stosuj zwinne metodologie podczas tworzenia frameworka, abyś mógł dostosowywać się do zmian, szybko reagować na przeszkody i zapewnić funkcjonalny, wysokiej jakości produkt końcowy. Metodyki zwinne to te, które zgodnie z „Manifestem zwinnym” nadają priorytet:

Osoby i interakcje ponad procesami i narzędziami
Działające oprogramowanie ponad obszerną dokumentacją
Współpraca z klientem ponad negocjacją umowy
Reagowanie na zmianę ponad zgodnie z planem

Zgadza się. Powiedziałem, że funkcjonalność jest ważniejsza niż dokumentacja. Zwróć uwagę, że „Manifest Agile” wspomina, że priorytety po prawej stronie są nadal ważne, ale mniej ważne niż te po lewej stronie.

Komunikacja

Ktokolwiek tworzy framework, musi wiedzieć:

1. Jak będzie używany: docelowa aplikacja
2. Jaki problem ma rozwiązać: problem z celem
3. Kto będzie z niego korzystać: docelowi odbiorcy

Na przykład, jeśli firma miała zamiar opracować ostateczną aplikację za pomocą ASP .NET, byłoby głupotą powiedzieć jej programistom „zrób ten framework” bez informowania ich o powyższym. Jeśli programiści nie znają aplikacji docelowej, mogą nie uczynić jej zorientowaną na WWW. Jeśli nie znają problemu, mogą stworzyć framework do innego celu. Gdyby nie znali odbiorców, mogliby zaprogramować framework w C ++. Każda z tych okoliczności sprawiłaby, że wynikowy framework byłby bezużyteczny.

Styl

Nie trzeba dodawać, że ustalono styl programowania / sformatuj i trzymaj się tego.

E „s

1. Modułowość : Ponowne użycie kodu programowo, a nie dosłownie.
2. Wydajność : Twój kod jest przeznaczony do ponownego wykorzystania . Wszelkie szkody dla szybkości są mnożone.
3. Konserwacja : Chcesz mieć możliwość edycji struktury, zaktualizować kilka programów bez konieczności ich modyfikowania.
4. Użyteczność : Czy aplikacje mogą faktycznie korzystać z Twojej platformy bez przeskakiwania przez obręcze?
5. Praktyczność : Nie „nie odkrywaj ponownie koła, jeśli nie masz aby to zrobić. Twój framework może zależeć od innych frameworków.
6. Nadmiarowość : Wyłap wyjątki / błędy. Wszędzie. Zajmij się nimi. Wszędzie. Nigdy nie ufaj żadnemu kodowi poza zakresem lokalnym do obsługi błędów, nawet jeśli wiesz, że tak.

Komentarze

• Witamy do P.SE! ' Nie zgadzam się w / nr 6 na wyłapywanie wyjątków w twoim frameworku. ' Jestem wielkim zwolennikiem tego, że framework powinien być absolutnym bachorem i rzucać wyjątki i pozostawić to programiście używającemu frameworka, aby je złapać lub (jeszcze lepiej) zmienić ich kod, tak aby uniknąć wyjątku – zachęcanie do zgodności z konwencją.

Jestem pewien, że istnieje jakaś różnica między tworzeniem frameworka lub biblioteki a aplikacją.

Procesy programistyczne są zasadniczo takie same. różnice mogą sprowadzać się do kwestii marketingowych i wdrożeniowych, chociaż uważam, że największe różnice dotyczą zwykle zakresu i definicji projektu.Pamiętaj, że aplikacja może zawierać lub wykorzystywać framework lub bibliotekę, framework może być zbiorem bibliotek.

Mam pewne wątpliwości co do sposobu organizacji i zarządzania tym projektem: Czy istnieją jakieś ogólne zasady llow, wskazówki, najlepsze praktyki lub coś, o czym należy pamiętać przy opracowywaniu tego rodzaju projektów?

Organizacja i zarządzanie projektem są takie same dla każdego projektu programistycznego . Znowu sprowadza się do zakresu. Jeśli jednak chodzi o pisanie frameworka, opłaca się mieć bardzo jasną wizję tego, co próbujesz osiągnąć, i umieścić ścisłe zasady projektowania publicznego interfejsu we frameworku, aby zapewnić spójność w zakresie interfejsów API Jeśli pozwolisz każdemu programiście robić własne rzeczy, skończysz ze skomplikowanym bałaganem i bardzo nieeleganckim projektem API.

Na drugim miejscu Ryan Hayes „ zalecenie przeczytania Wytyczne dotyczące projektowania ram nawet jeśli sama książka ma na celu rozwijanie frameworków opartych na .NET, ponieważ ogólne porady mają zastosowanie niezależnie od konkretnych technologii implementacji, z których możesz skorzystać.

Z doświadczenia radziłbym trzymać się klasyczna zasada YAGNI, polegająca na zaimplementowaniu najpierw najbardziej uproszczonych interfejsów publicznych, a następnie rozszerzeniu, aby zapewnić większą kontrolę i głębię później, ale uważaj, aby używać przydatnych nazw, aby pokazać, dlaczego metody lub klasy są rozszerzane. Nigdy nie byłem fanem dodawania „Ex” lub innych podobnych sufiksów do nazw metod ani dodawania liczb do rozszerzonych definicji interfejsów. Zróżnicuj funkcjonalność, a nazwy interfejsów / metod powinny stać się jaśniejsze i miejmy nadzieję, że mniej zaciemnione i zagmatwane.