Strzeż się współdzielenia
Oryginalny tytuł: Beware the Share
Autor: Udi Dahan
To był mój pierwszy projekt w tej firmie. Byłem świeżo upieczonym absolwentem, który nie może doczekać się, aż będzie mógł się wykazać. Siedziałem po godzinach, przeglądając istniejący kod, a podczas pracy nad moją pierwszą funkcjonalnością, zadbałem o to, by wykorzystać wszystko, czego się do tej pory nauczyłem — komentarze, logowanie, wyciąganie wspólnego kodu do bibliotek itp. Jednakże na pierwszym przeglądzie mojego kodu, na który byłem, jak mi się wówczas wydawało, dobrze przygotowany, czekało mnie brutalne przebudzenie — recenzent skrzywił się, gdy zobaczył wspołdzielenie kodu!
Jak to możliwe? Przez całe studia wpajano mi, że ponowne wykorzystanie kodu leży u podstaw inżynierii oprogramowania wysokiej jakości. Wszystkie te artykuły i podręczniki, które przeczytałem, ci doświadczeni programiści, od których się uczyłem — cała ta wiedza była niewłaściwa?
Okazuje się, że w tym wszystkim brakowało jednej, dośc istotnej rzeczy.
Kontekstu.
Fakt, że dwie całkowicie różne części systemu wykonują pewną logikę w ten sam sposób, ma mniejsze znaczenie, niż sądziłem. Przed tym jak wyciągnąłem wspólny kod do biblioteki, te części systemu były niezależne od siebie. Każda z nich mogła ewoluować oddzielnie. Każda mogła zmieniać swą logikę, aby dostosowywać się do zmiennych wymagań biznesowych. Te cztery wiersze podobnego kodu były przypadkowe &mdash taka tymczasowa anomalia, zbieg okoliczności. To znaczy, zanim ja się pojawiłem.
Te biblioteki współdzielonego kodu, które stworzyłem, związały ze sobą sznurówki dwóch butów. Jedna część systemu nie mogła zrobić kroku naprzód, zanim druga się z nią nie zsynchronizowała. Koszty utrzymywania kodu tych funkcji, gdy były niezależne, był zaniedbywalny, natomiast współdzielony kod w bibliotece wymagał o wiele więcej testowania.
Mimo że zmniejszyłem całkowitą liczbę wierszy kodu w systemie, to jednak liczba zależności wzrosła. Kontekst tych zależności jest tutaj decydujący — gdyby były one lokalne, współdzielenie kodu byłoby usprawiedliwione i mogłoby przynieść jakieś korzyści. Gdy zależności nie da utrzymać się w ryzach, ich pnącza zaczynają oplatać coraz to większe i ważniejsze elementy systemu, mimo że sam kod wydaje się być w porządku.
Tego typu pomyłki bywają zdradzieckie z tego względu, że sama idea współdzielenia kodu wydaje się dobra. Zastosowana w odpowiednim kontekście, ta technika jest wartościowa. Z kolei w niewłaściwym kontekście powoduje raczej wzrost kosztów niż wartości. Podchodząc do nowego kodu, gdy nie mam jeszcze wiedzy, gdzie poszczególne jego części są używane, jestem teraz dużo bardziej ostrożny w kwestii tego, co powinno być współdzielone.
Strzeż się współdzielenia. Wpierw sprawdź kontekst. Dopiero potem działaj.
Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.
Komentarze (4)
