Nie bój się psuć
Oryginalny tytuł: Don't Be Afraid to Break Things
Autor: Mike Lewis
Każdy w branży bez wątpienia pracował nad kodem, który był co najmniej niepewny. System jest kiepsko zorganizowany, a zmiana jednej rzeczy oznacza zepsucie jakiejś zupełnie innej. Zawsze kiedy dodaje się moduł, pierwszorzędnym celem jego twórcy jest zmiana jak najmniejszej części kodu, a potem wstrzymywanie oddechu podczas każdego wypuszczenia produktu. Jest to programistyczny odpowiednik grania w Jenga kształtownikami w wieżowcu, musi się skończyć katastrofą.
Powodem, dla którego dokonywanie zmian tak niszczy nerwy, jest choroba systemu. Potrzebuje on lekarza, inaczej jego stan się tylko pogorszy. Gdy już wiesz, co mu dolega, boisz się zbić kilka jajek, żeby zrobić omlet. Chirurg wie, że trzeba zrobić nacięcie, żeby móc przeprowadzić operację, ale wie też, że są one tymczasowe i się zagoją. Końcowy rezultat operacji jest wart początkowego bólu a stan pacjenta w ostatecznym rozrachunku będzie lepszy niż przed zabiegiem.
Nie bój się o swój kod. Kogo obchodzi, jeżeli coś się tymczasowo zepsuje, podczas gdy przesuwasz rzeczy? Paraliżujący strach jest tym, co doprowadziło Twój projekt do obecnego stanu. Inwestowanie czasu w refaktoryzację zwróci się kilkukrotnie podczas całego cyklu życia projektu. Posiadasz tę przewagę, że zespół ma doświadczenie w obsłudze chorego systemu, co sprawia, że jesteście ekspertami od tego, jak powinien działać. Skorzystaj z tej wiedzy, a nie odrzucaj. Praca nad czymś, czego się nienawidzi, nie jest czynnością, na którą ktokolwiek powinien marnować czas.
Przedefiniuj wewnętrzne interfejsy, zmień strukturę modułów, refaktoryzuj kod powstały przez kopiuj–wklej, uprość projekt, żeby ograniczyć zależności. Możesz znacząco zredukować złożoność kodu poprzez wyeliminowanie patologicznych przypadków, które często są rezultatem źle dopasowanych elementów. Powoli przechodź od starej struktury do nowej, testując po drodze. Próba przeprowadzenia ogromnej refaktoryzacji w jednym wielkim skoku spowoduje dość problemów, abyś zaczął się zastanowić nad porzuceniem całego przedsięwzięcia.
Bądź chirurgiem, który nie boi się wyciąć chorych partii, żeby pozwolić na leczenie. Nastawienie jest zaraźliwe i zainspiruje innych do rozpoczęcia prac nad uporządkowaniem projektów, które zawsze odkładali na później. Zrób "higieniczną" listę zadań, które zespół uważa za wartościowe dla dobra projektu. Przekonaj kierownictwo, że nawet jeżeli to, co teraz robisz nie przyniesie widocznych rezultatów, zredukuje późniejsze koszty i przyspieszy wydawanie nowych wersji. Nigdy nie przestawaj przejmować się "zdrowiem" kodu.
Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.
Komentarze (1)
