Kiedy budowanie własnego frameworku jest bardziej produktywne niż używanie istniejącego? [Zamknięte]

Chciałbym wiedzieć, dlaczego zdecydowałeś się zbudować własny framework w swojej firmie.

Z założenia nie mam na myśli kilku bibliotek, z których często korzystasz. Mam na myśli konkretny sposób budowania na nim aplikacji, z klasami podstawowymi, konwencją itp.

Więc dlaczego pan wbudowany własny ram? Jak możesz to uzasadnić osobie, która cię zatrudnia? Czy mierzysz jego pozytywny i negatywny wpływ?

Jeśli chodzi o twoje doświadczenia, czy zauważyłeś, że w niektórych przypadkach ramy firmy przyniosły realne korzyści, czy z drugiej strony zwiększone koszty rozwoju (krzywa uczenia się, debugowanie, utrzymanie, ...)?

Odpowiedz na pytanie:

• Problemy z licencją
• Wymagania specyficzne dla firmy, które nie istniały w obecnych ramach
• Firma chce mieć kontrolę nad wsparciem i utrzymaniem frameworka
• Architekt nie wiedział lepiej! On / ona nie wiedziała o tym, że istniał konkretny framework, więc postanowili wynaleźć koło.

Aktualizacja:

Przedsiębiorstwa wolą wymyślać koło zamiast używać „małych” ram. Mówiąc krótko, odnoszę się do ram, które mogą mieć niepewną przyszłość. Na przykład .NET Framework jest bezpieczniejszym wyborem dla przedsiębiorstw niż framework stworzony przez małą społeczność. Przedsiębiorstwa potrzebują bezpieczeństwa, ponieważ wiele ich aplikacji ma kluczowe znaczenie dla biznesu, a także ma długą żywotność. Koszt ponownego wynalezienia koła może być krótszy. Ale koszt może być większy, jeśli środowisko używane w aplikacji firmowej jest przestarzałe i nie jest już obsługiwane, lub licencje są zmieniane. Tutaj firma może być zmuszona do wyrzucenia obecnych ram i wprowadzenia innego. Visual Basic to dobry przykład języka, który nie jest już obsługiwany przez Microsoft. A to kosztuje firmy miliardy, ponieważ muszą zacząć od nowa z nowym rozwojem.

Po co budować własne?

1. ponieważ nigdy wcześniej nie był budowany (rzadko, ale mimo to możliwość)
2. ponieważ chcesz mieć pełną kontrolę.
3. ponieważ potrzebujesz tylko trochę funkcjonalności, aby taniej było zbudować ją samodzielnie

Dlaczego nie zbudować własnego?

1. nie masz na to czasu
2. prawdopodobnie jest znacznie tańszy, jeśli kupisz istniejący framework
3. oszczędzasz dużo czasu i możesz znacznie zwiększyć produktywność

W moim poście, kiedy należy wymyślić koło na nowo , wymieniam szereg zalet ponownej implementacji. Myślę, że te zalety dotyczą zwłaszcza bibliotek frameworka. Na przykład często niemożliwe jest odizolowanie korzystania z biblioteki frameworka w małej części aplikacji. Zamiast tego mają tendencję do dyktowania struktury kodu źródłowego klienta, dlatego pożądana jest pełna kontrola nad biblioteką.

Jedynym prawdziwym powodem do wymyślenia nowego koła jest to, że jest to aplikacja o krytycznym znaczeniu dla biznesu. Jeśli Twoja firma będzie korzystała przez jakiś czas. Jeśli to aplikacje / framework / etc. prawdopodobnie wykształci się poza istniejące ramy komercyjne, które mają do zaoferowania, a następnie kodery firmowe, aby ich wdrożenie było z pewnością dopuszczalne.

Jedynymi prawdziwymi powodami tego są:

1. Istniejące ramy są dobrze utrzymane, w pełni odpowiadają Twojemu zadaniu i będą dobrze wyglądać w przyszłości.

2. To tylko przypadek „ Nie wynalazł tutaj ”

3. Twoja obecna konfiguracja nie będzie w stanie pomyślnie stworzyć tego frameworka w rozsądnym czasie i rozsądnych kosztach.

Joel Spolsky napisał bardzo dobry artykuł na ten temat: W obronie syndromu nie-wynalazł-tutaj

Zasadniczo, gdy korzystasz z pracy innych, dodajesz ich jako niewidzialnych pracodawców lub „dodatkowe ręce”.

Jeśli są dobre, pomogą ci. Jeśli nie, musisz wykonywać swoją pracę oprócz swojej - innymi słowy, utrzymuj ich kod. Może to być niedopuszczalne ryzyko, ale uważam to za bardzo rzadkie.

Słowem kluczowym jest umożliwienie wymiany frameworka poprzez kodowanie do interfejsu. Najbardziej sztywnymi interfejsami w świecie Java są specyfikacje Sun, o czym świadczy API serwletu.

Wtedy nie uważałbym, że istnieje jakikolwiek powód, aby nie używać frameworka.

Mamy dość dojrzałe środowisko, w którym pracuję. Oto podsumowanie Foundations Framework

Jednym z kluczowych powodów korzystania z niego jest stabilność. Nie jesteśmy zobowiązani do Microsoft lub jakiegokolwiek innego dostawcy, który dąży do dodawania nowych funkcji i złożoności z roku na rok.

(Moje własne poglądy, nie mojego pracodawcy itp.)

Zrobiłem to kilka razy, aby spełnić wymagania nieobjęte istniejącymi ramami (wówczas).

W większości przypadków te domowe frameworki zostały później usunięte przez nowsze, w pełni dorosłe frameworki. Na przykład w 2000 roku stworzyłem platformę internetową Java, w niektórych aspektach porównywalną do Rails, używaną do tworzenia złożonego systemu wprowadzania zamówień z kilkoma ukrytymi formularzami. Działało dobrze, ale oczywiście kilka lat później bardziej dojrzałe frameworki, takie jak Struts i JSF, sprawiły, że stało się ono przestarzałe. Ale wtedy było to właściwe, działało dobrze, a szybkość rozwoju była imponująca.

Kolejne środowisko, które opracowałem, jest nadal w użyciu (a także w aktywnym rozwoju); pierwsza wersja została napisana w 2004 roku. Ta używana jest głównie do zastosowań intralogistycznych; firma, która go używa, nadal postrzega go jako cechę wyróżniającą. Głównym powodem jego utworzenia było ułatwienie tworzenia aplikacji podłączonych do bazy danych dla mobilnych skanerów kodów kreskowych (działających w systemie Windows CE); działało tak dobrze, że szefowie postanowili zastosować tę samą koncepcję również w oprogramowaniu komputerowym i, cóż, nadal są z tego zadowoleni.