Niestandardowe narzędzia w projekcie
Dwa tygodnie temu, projekt nad którym aktualnie pracuję w pracy, ruszył na produkcji. Ogólnie (wg. wszystkich menadżerów) projekt zakończył się sukcesem. Dowodem na to jest zadowolenie klienta i maksymalna ocena od klienta uzyskana.
Czy to znaczy, że wszyscy są zadowoleni? Nie do końca, ja mam zamiar pomarudzić w paru następnych postach 
Spokojnie, będzie bez nazwisk, wypominania, itp. Ogólne myśli, które mogą stanowić poradę/przestrogę dla innych (a dla mnie fajne wspomnienie, jak za parę lat jak to przeczytam).
Temat 1: niestandardowe narzędzia w projekcie
Poprzez niestandardowe rozumiem tutaj takie, które nie są zgodne z istniejącymi standardami (oczywiste) oraz takie, które nie należą do powszechnie używanych (nie do końca tutaj słowo niestandardowe pasuje 
. Poprzez narzędzia rozumiem zarówno IDE, kompilatory, maszyny wirtualne, biblioteki.
W naszym projekcie pojawiło się kilka tym podobnych czynników. Większość z nich to efekt tego, że te narzędzia były stosowane przez firmę od wielu lat lub zostały po prostu przez firmę stworzone. Jak to wpływa na całokształt projektu?
Odpowiedź: to zależy To zależy, czy narzędzia są odpowiednio dobrane do potrzeb. Wyobraźcie sobie framework, który został napisany do wsparcia aplikacji web dla niewielkiej ilości użytkowników, z założenia robiących rozdzielenie zadania. Framework jest produktem firmy, więc nie można go znaleźć na sieci. Framework zawiera w sobie biblioteki robiące mapowanie ORM, biblioteki upraszczające wykonanie niektórych zadań, itp. itd. Dotychczas sprawdzał się idealnie. Teraz dostajemy nowe zadanie: napisanie aplikacji integrującej dwa systemy (a właściwie migrującej dane z jednego do drugiego systemu). Framework zawiera pewne uproszczenia, które redukują ilość potrzebnego kodu, upraszczając sprawę programiście. Czy to oznacza, że framework do nowego zadania się nadaje?
Kolejna odpowiedź: to zależy. Pewnie gdyby był napisany dobrze, nadawałby się (albo przy najmniej jego część). Ale prawdopodobnie autorzy nie testowali tego frameworku w wielowątkowym środowisku, nie badali jego wydajności dla obsługi dużej ilości danych, itp. itd. Mamy dwie możliwości: sprawdzi się albo się nie sprawdzi. Jeśli się sprawdzi, to dobrze dla nas, a jeśli nie to co wtedy? Nie znajdziemy odpowiedzi na nasze problemy w google'u. Osoba, która pisała problematyczny kod może już w firmie nie pracować. Osoba utrzymująca kod może nie mieć czasu na poprawki. Poprawki mogą wiązać się z poważnym refaktoringiem, co skutecznie może zwiększyć koszta zmian.
Czy to znaczy, że należy takich samorobnych rozwiązań unikać? Oczywiście nie. Często nie ma innej opcji, niż wykorzystanie samorobnego narzędzia, gdyż gotowce mogą nie istnieć, mogą być zbyt nieoptymalne lub mogą okazać się armatą na komara.
Moim zdaniem, decydując się na wybór konkretnej biblioteki/narzędzia należy wziąć pod uwagę:
- czy dane narzędzie spełnia nasze potrzeby i oczekiwania
- czy nasza wiedza na temat narzędzia pozwala uczciwie odpowiedzieć na pierwsze pytanie
- czy wykonaliśmy proof-of-concept
Z kolei decydując się na napisanie własnego narzędzia, należy wziąć pod uwagę:
- czy na pewno rozumiemy wszystkie wymagania
- jeśli je rozumiemy, to czy na pewno potrafimy je zrealizować
- jakie ryzyko niesie za sobą pisanie własnego narzędzia (wsparcie, pomoc od innych osób w firmie, pomoc z sieci, rozwiązywanie problemów, o których mamy nikłe pojęcie)
- czy ktoś już naszego problemu nie rozwiązał
Błędne decyzje na początku projektu mogą odbić się poważną czkawką pod koniec. W większości wypadków, zastosowanie gotowych bibliotek i narzędzi rozwiąże nasz problem. Decyzja o tworzeniu własnej biblioteki czy narzędzia powinna być podjęta na spokojnie, z pełną świadomością ryzyka, jakie to niesie. Żeby zabrać się na pisanie własnego narzędzia, powinniśmy mieć mocne, ciężkie do zbicia argumenty.
Jaka jest Wasza opinia i jakie są Wasze doświadczenia?
