Kto widział “nasz własny dostęp do danych”, bo “ORMy są słabe“? Kto widział “nasz własny kontener Dependency Injection”, bo “to przecież proste“? Kto widział…?
[blogvember2016 no=”9”]
Ilekroć miałem do czynienia z projektami, w których większość kodu stanowiły narzędzia i infrastruktura, a nie logika biznesowa, wiedziałem TO. Czułem. Najpierw intuicja, potem doświadczenie, zgodnie podpowiadały: oj stary, nie będzie wesoło.
RETREEEEAT!!!
Powodów wynajdowania koła na nowo może być wiele. A to żałowanie kasy na kupno gotowca (choć finalnie wychodzi drożej). A to nieufność do cudzego kodu (choć własny bardzo rzadko jest lepszy). A to chora ambicja (MY NIE ZROBIMY??). A to wreszcie: niedouczenie i brak rozeznania w ofercie rynku.
Jest to zjawisko bardzo powszechne. Spotykane często, zaraźliwe jak ospa. Przenoszone drogą elektroniczną. Dorobiło się nawet własnej nazwy: Not Invented Here Syndrome (NIH).
Chcesz dowiedzieć się, jak działa ORM? Proszę bardzo, napisz swój. Kontener DI? Napisz swój! Biblioteka do walidacji? Napisz! Program do wersjonowania baz danych? Napisz! Biblioteka do testów? Napisz!
Ale, na Boga Swaroga, nie skazuj swojego projektu na używanie go. Potraktuj to jako ciekawe doświadczenie, eksperyment. Bardzo wartościowy sposób na podszlifowanie własnych umiejętności i dogłębne zrozumienie danego (rozwiązanego wszak) problemu. Nic więcej.
Wiecie ile czasu jest co miesiąc marnowanego na utrzymywanie takich “własnych” rozwiązań w prawdziwych, komercyjnych projektach? Dużo. Jest tu obecny ktoś, kto ten czas marnuje w taki sposób? Palec pod budkę, podzielcie się w komentarzach :).
The NIH syndrome is a disease.
Linus Torvalds
P.S. Wiem, że czasem NIE DA SIĘ inaczej, chociażby ze względów prawnych. Ale to margines.
