Wewnętrzne frameworki

Musiałem właśnie coś zmienić w projekcie, w którym ktoś wpadł na pomysł aby rozwiązać pewne problemy za pomocą wewnętrznego frameworka. A raczej stworzyć całą aplikację w oparciu o nigdzie nikomu nieznany framework. Na mojej prywatnej liście programistycznego zła wewnętrzne frameworki zajmują zasłużone wysokie miejsce. Nie twierdzę tu oczywiście, że nie ma dobrych wewnętrznych frameworków, ale ja się z takimi jeszcze nie spotkałem (a dawno temu sam jeden popełniłem zamiast poszukać czegoś uniwersalnego).

Wszystko zaczyna się od tego, że ktoś wpada na pomysł by coś przyspieszyć. "Zamiast pisać kod zróbmy sobie framework. Będziemy mogli łatwo dodawać kolejne funkcjonalności i w ten sposób oszczędzimy czas. I wszystko będzie uniwersalne i będziemy mogli to wykorzystać w kolejnych projektach".  Najczęściej żadne z założeń się nie sprawdza, funkcjonalności wykraczają poza możliwości frameworku co dodaje do niego kolejne narośle mające rozwiązywać nieprzewidziane wcześniej problemy. W ten sposób zamiast tworzyć kod aplikacji rozwijamy framework (który najczęściej jest w stanie zrozumieć tylko jego twórca), aby z satysfakcją dodać do naszej aplikacji jedną linijkę XML-a, tudzież jakiegoś wewnętrznego języka.Frajdy dodaje fakt, że tworzenie frameworku jest najczęściej zadaniem bardzo twórczym i przyjemnym. O wiele przyjemniejszym niż późniejsze korzystanie z niego.

Jak dla mnie największymi wadami wewnętrznych frameworków są:
- Brak jakiejkolwiek dokumentacji, co powoduje, że nowa osoba dowiaduje się o różnych smaczkach utykając na głupim błędzie, przez który pozostali programiści zdążyli już przebrnąć. W tym momencie Google, standardowe narzędzie programisty na nic się nie zdaje.
- Uzależnienie firmy, dla której tworzy się oprogramowanie od frameworku. Najczęściej jest to dla niej bilet w jedną stronę, bo znalezienie programistów, którzy chcieliby się babrać w utrzymywaniu cudzego frameworku... no cóż, graniczy z cudem
- Ograniczenie rozwoju programisty, który jest zmuszony pisać w nigdzie nie znanym frameworku. Po pewnym czasie faktycznie zaczyna rozumieć framework, ale wiedza ta jest kompletnie nieprzenośna. W żaden sposób nie poprawia to jego ogólnego technicznego obycia, bo co z tego, że jest frameworkowym ekspertem jeżeli nie jest w stanie tej wiedzy nigdzie indziej zastosować. Słowem, z każdą chwilą szanse na zmianę pracy maleją a frustracja rośnie.
- Brak 100% zaufania do frameworku - skoro powstał tylko na potrzeby danego projektu, to jesteśmy jego jedynymi użytkownikami. Niby są testy, ale skoro nawet w Hibernate mającym tysiące użytkowników znajdują się okazjonalne błędy, to możemy podejrzewać że w naszym też się znajdą, wtedy gdy się tego nie spodziewamy.

Z pewnością są sytuacje, w których napisanie frameworku w jakiś sposób się zwraca, jednak z tego co zaobserwowałem, najczęściej rodzi to frustracje ponieważ czegoś się po prostu zrobić nie da. Nauczka dla samego siebie, jeżeli kiedykolwiek będę miał możliwość wyboru czy tworzyć frameworki czy korzystać nawet ze skomplikowanych rozwiązań, które są ogólnodostępne, zdecydowanie wybieram to drugie.