Nowy projekt

Jakoś ponad rok temu, czy może dwa lata zaczynałem nowy projekt. Nowy dla nas, nie tak nowy dla developerów już tam siedzących. Jednak jak zawsze bywa z nowym projektem miałem wielką nadzieję, że to będzie on, projekt marzenie. Życie miało inne plany.

Oczywiście że śmiechy-chichy, że coś głupio zrobione, że ja zrobiłbym to inaczej gdybym to ja robił czy też taki klasyk:

Takie są najczęstsze początki “nowych” projektów.

Historia lubi się powtarzać

Szczególnie w pamięci leży mi jeden przypadek, szczególnie blisko memu sercu i projektowi. Mianowicie wyświetlanie danych z różnych tabel bazodanowych, w różnym formacie, różne modele danych, różne typy danych, różna ilość dostępnych danych. Sporo czasu spędziliśmy dodając i odejmując komórki w tabelach czy dodając !!more-importanetery!!!! w css, żeby wreszcie dwa+ różne produkty wyglądały i zachowywały się tak samo. Pamiętam to ponieważ powiedziałem wtedy: “szkoda, że nie przemyśleli tego wcześniej i od razu nie zrobili fajnej abstrakcji^[1] nad tym wszystkim“.

Po dwóch nutkach

Wspominam o tym, ponieważ teraz sam jestem w podobnej sytuacji i nie chce tego właśnie koncertowo załatwić. Jak być może ktoś pamięta na początku pisałem, że można będzie obserwować kanał z rss jak i aktywności innych użytkowników, np. Kowalski przeczytał wiadomość na onecie “Jak żyć – pytają premiera”, a jednocześnie w tym samym strumieniu wiadomości chciałbym umieszczać wiadomości z rss, które będą wyglądać na zasadzie: “blog jareczka: nowy przepis na ciastka bez bugów”. Kliknięcie na jeden czy drugi ma w założeniu wyświetlić podgląd treści wpisu, udostępnić jakieś dodatkowe akcje czy coś.

Dlaczego o tym piszę

Działa mi obserwowanie innych użytkowników (lepiej lub gorzej), działa mi obserwowanie kanałów i czytanie wiadomości i w zasadzie dosyć tanim kosztem mógłbym ifami ogarnąć dwa przypadki i jakoś zmusić je do działania ze sobą, ale nie chce. Nie mogę się z tą myślą zgodzić, nie mogę tego tak zostawić. Nie mogę ponieważ boję się, że w niedalekiej przyszłości przyjdzie mi do głowy inny typ obserwacji, który będę chciał zaimplementować i pojawi się kolejny wyłom i będzie syf. Później będzie trzeba to ustabilizować i poprawiać i może optymalizować kilku (bleh!) miejscach. NIE. Ktoś może powiedzieć, że jestem kłamcą bo: http://jaroslawstadnicki.pl/2016/03/good-enough-software-moim-zdaniem/ – ale w tym przypadku ja mam czas i “pieniądze” i poza chęcią zobaczenia tego co jest za zakrętem i napisania kolejnej funkcjonalności – nic mnie nie goni.

Z każdym takim wpisem i przemyśleniami i decyzjami zaczynam znajdować zrozumienie wielu decyzji, które podejmowane są w takich lub innych projektach, z który później się śmiejemy. Mój projekt (ITAN) ma nieskończony budżet (0zł) i duży zapas czasowy – z drugiej strony wiem też że chciałbym coś wypuścić, jakieś małe MVP.
W komercyjnych projektach ktoś wyciągał ze swojego portfela złoto i przelewał je komuś innemu. Doskonale rozumiem, że tydzień refaktoringu jest zajebisty. Ale jeśli praca nie przyniesie kasy, lecimy na bruk. To nic, że potem będzie łatwiej, niestety dla nas i naszego produktu nie będzie potem. Czas=Pieniądz.

Refaktoring jak bugfix

Chce jeszcze napisać, że podobnie jak z bugami, które wykryte wcześnie są tańsze w naprawie, tak samo refaktoring im wcześniej przeprowadzony kosztuje mniej i wprowadza mniejsze ryzyko. Refaktoring można porównać do korygowania kursu, który się przyjęło. Płyniesz i co jakiś czas sprawdzasz jak bardzo odbiłeś(aś) o planowanej trasy i korygujesz. Im częściej to robisz, tym mniejsze poprawki musisz wprowadzać. Tym mniej czasu na to potrzebujesz. Tym mniej to kosztuje. Bardzo polecam ten długi artykuł: http://martinfowler.com/articles/designDead.html

Akapitem zakończenia

Jeśli traficie kiedyś do “nowego” projektu, zamiast pojechać po nim jak po burej, spójrzcie na ów i pomyślcie “czemu?”. Co musiało się stać, że napisali to w taki sposób. Pomyślcie gdzie były pieniądze podczas pisanie danego featurea. Richard z .net rocks często mówi: “zakładam, że ludzie w momencie pisania danego kodu, zrobili wszystko co mogli i najlepiej jak umieli, aby dostarczyć pewną funkcjonalność” – bardzo mi się podoba takie podejście, chciałbym je mieć zawsze przy sobie gdy otrzymuje spadek. Jasne, można się chwilę pochichrać ze sposobu rozwiązania, ale nie rzucajmy klątwy na tamtych programistów. Jest bardzo duża szansa, że za miesiąc to nam będą kurzaje wyrastać, gdy jakiś młodziak będzie coś po nas poprawiać.

Tymczasem ja udaje się go magicznego projektu, gdzie jest czas i pieniądz na wieczny refaktoring.

^[1] – Abstrakcja jak wiadomo zawsze rozwiązuje problem. Lubię powtarzać: “Abstrakcja was uwolni”