Muszę rozpocząć projektowanie i rozwój nowej platformy do interakcji z ECM typu open source. Obejmuje to dostosowany model danych, aby pomóc programistom stron internetowych w interakcji z tym ECM, aby nie musieli przejmować się szczegółami manipulacji węzłami i innymi szczegółami niskiego poziomu. To tylko garść klas i metod do opracowania.

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

Jestem pewien, że istnieją pewne różnice między tworzeniem frameworku lub biblioteki a aplikacją.

Najpierw są moje 2 zasady, aby uniknąć syndromu marnotrawstwa ramowego:

• Brak istniejącej, pokrywającej 80% moich potrzeb i rozszerzalnej w celu dopasowania do ostatnich 20%
• Niemal pewność, że użyję go ponownie, w innej aplikacji

Po ich przejściu sprawdź:

• 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

1) Funkcje powinny być dodawane do frameworka tylko wtedy, gdy zostaną wyodrębnione z działającego kodu. Innymi słowy, przed dodaniem nowego, fajnego pomysłu do nowego, fajnego frameworka, upewnij się, że w rzeczywistości dodaje on wartości i zmniejsza powtarzalność w działającej aplikacji w świecie rzeczywistym.

2) Dokumentacja, dokumentacja, dokumentacja.

3) Dokumentacja, dokumentacja, dokumentacja.

Bolesne doświadczenie i dużo zmarnowanego wysiłku prowadzą do tej rady: wyciągnij lub przebuduj środowisko z działającego oprogramowania. Zbuduj to oprogramowanie, pamiętając, że uważasz, że będziesz chciał wyodrębnić platformę w przyszłości, ale nie buduj jej najpierw.

Proponuję książkę Wytyczne dotyczące projektowania ram . Ma kilka lat, ale zasady pozostają prawdziwe. Ma mnóstwo wzorców i wyjaśnia powody decyzji, które podejmiesz podczas budowania 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 komentarzy do kodu, aż do wyjaśnienia, jakie najważniejsze funkcje wymagają i produkują, nawet jeśli wydaje ci się to bardzo proste, możesz mieć kogoś, kto użyje go w 14. godzinie, a oni w tym momencie potrzebuję tylko jednej rzeczy.

3) Przygotuj dla siebie krótki opis projektu z tym, co chcesz osiągnąć w ramach, realistyczne cele i ogólne priorytety.

4) Jeśli będzie dostępna dla ludzi, upewnij się, że masz jakąś formę procesu wsparcia / śledzenia błędów. Będą pluskwy, zdarza się to nam wszystkim, ale jeśli zdołasz sobie z nimi poradzić od razu, ułatwi ci to życie.

Podsumowując, podobne podejście do tworzenia dowolnej aplikacji, ale programiści są nawet bardziej wybredni niż użytkownicy, a najlepsze frameworki to te, które możemy wybrać, zrozumieć i nie musimy walczyć.

Nie zgadzam się z dużą ilością tego, co zostało powiedziane, i czuję, że więcej nie zostało wspomniane, więc zacznę od zera.

Zwinne metodyki

Przyjęcie zwinnych metodologii podczas opracowywania struktury, aby można było dostosować się do zmian, szybko reagować na przeszkody i zapewnić funkcjonalny produkt końcowy wysokiej jakości. Metodyki zwinne to takie, które zgodnie z „Manifestem zwinności” nadają priorytet:

Osoby i interakcje między procesami i narzędziami
Oprogramowanie robocze nad obszerną dokumentacją
Współpraca z klientami nad negocjacjami umowy
Reagowanie na zmianę w związku z planem

Zgadza się. Powiedziałem, że funkcjonalność jest ważniejsza niż dokumentacja. Zauważ, że „Manifest zwinności” wspomina, że ​​priorytety po prawej stronie są nadal ważne, tylko mniej niż po lewej.

Komunikacja

Ktokolwiek tworzy ramy, musi wiedzieć:

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

Na przykład, jeśli firma zamierza opracować końcową aplikację za pomocą ASP .NET, głupotą byłoby powiedzieć jej programistom, aby „stworzyli tę platformę”, nie mówiąc im o tym powyżej. Jeśli programiści nie znają docelowej aplikacji, mogą nie uczynić jej zorientowaną na sieć. Jeśli nie znają problemu, mogą stworzyć ramy dla innego celu. Gdyby nie znali odbiorców, mogliby zaprogramować framework w C ++. Każda z tych okoliczności sprawiłaby, że powstały szkielet byłby bezużyteczny.

Styl

Nie trzeba dodawać, ustal styl / format programowania i trzymaj się go.

E's

1. Modułowość : Ponownie użyj kodu programowo, a nie dosłownie.
2. Wydajność : Twój kod jest przeznaczony do ponownego użycia. Wszelkie szkody dla prędkości zostają pomnożone.
3. Konserwowalność : Chcesz mieć możliwość edycji frameworka, aby zaktualizować kilka programów, bez konieczności modyfikacji tych programów.
4. Użyteczność : czy aplikacje mogą faktycznie używać twojego frameworka bez przeskakiwania przez obręcze?
5. Praktyczność : nie wymyślaj ponownie koła, jeśli nie musisz tego robić. Twój framework może zależeć od innych frameworków.
6. Redundancja : wyjątki / błędy połowu. Wszędzie. Radzić sobie z nimi. Wszędzie. Nigdy nie ufaj żadnemu kodowi poza lokalnym w zakresie obsługi błędów, nawet jeśli wiesz, że tak.

Jestem pewien, że istnieją pewne różnice między tworzeniem frameworku lub biblioteki a aplikacją.

Procesy rozwojowe są zasadniczo takie same. Różnice mogą sprowadzać się do problemów marketingowych i wdrożeniowych, chociaż uważam, że największe różnice dotyczą zwykle zakresu projektu i jego definicji. Pamiętaj, że aplikacja może zawierać lub używać frameworka lub biblioteki, frameworkiem może być zbiór bibliotek.

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

Organizacja i zarządzanie projektem są znów takie same dla każdego projektu deweloperskiego. Ponownie sprowadza się to do zakresu. Jednak jeśli chodzi o pisanie frameworka, opłaca się mieć bardzo jasną wizję tego, co próbujesz osiągnąć, i wprowadzić surowe reguły projektowania publicznego interfejsu do frameworka, aby zapewnić spójność prezentacji interfejsu API. Jeśli pozwolisz każdemu deweloperowi robić swoje, skończy się skomplikowanym bałaganem i bardzo nieelegacyjnym projektem interfejsu API.

Poparnę zalecenie Ryana Hayesa do przeczytania Wytyczne dotyczące projektowania ram, mimo że sama książka ma na celu opracowanie ram opartych na .NET, ponieważ ogólne porady mają zastosowanie niezależnie od konkretnych technologii wdrażania, które możesz wybrać.

Z doświadczenia radziłbym trzymać się klasycznej zasady YAGNI, wdrażając najpierw najprostsze publiczne interfejsy, a następnie rozwijając, aby zapewnić większą kontrolę i głębię, ale bądź ostrożny, używając użytecznych nazw, aby pokazać, dlaczego metody lub klasy są rozwijane. 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 mam nadzieję, że mniej zaciemnione i mylące.