Zanim cokolwiek powiesz, pozwól, że wytłumaczę o co chodzi. Pamiętasz, jak kiedyś musiałeś zmodyfikować część aplikacji, którą napisał ktoś inny, parę miesięcy temu, i nagle okazuje się, że właśnie ten kawałek jest napisany tak bardzo „na sztywno”, że ciężko do niego dodać nową funkcjonalność bez przepisania kodu prawie całkowicie?
Prawdopodobnie ten kawałek kodu był pisany na kolanie, przez niedoświadczonego programistę lub nawet juniora. Kod ten nie przeszedł review i został włączony do aplikacji bez większych modyfikacji.
Nie zawsze tak jest, jednak czasami przy dużych zmianach lub dużym projekcie, doświadczony developer pomyśli dłużej nad rozwiązaniem problemu niż junior. Pomysł juniora, który zajmie mniej czasu nie jest zły z punktu widzenia celu – wprowadzone zmiany mają przynieść wymierne korzyści. W większości przypadków biznes oczekuje korzyści materialnych. Im szybciej zostanie wdrożona nowa funkcjonalność, tym bardziej opłaca się ją dodawać do projektu. Jednak podczas kodowania, nie zawsze zwracana jest dostateczna uwaga dotycząca sposobu wdrożenia tej funkcjonalności.
Zawsze należy założyć, że wprowadzane dzisiaj zmiany, mogą ulec dalszej modyfikacji za miesiąc czy rok. Po tym czasie może okazać się, że użytkownicy końcowi oczekują innego podejścia do danej funkcjonalności. Jeśli kod tej modyfikacji został napisany poprawnie (czytaj: przyszłościowo), to późniejsza jego zmiana zajmie relatywnie mało czasu, ponieważ miejsce na kolejne modyfikacje zostało w nim przewidziane wcześniej. Doświadczony developer zdaje sobie z tego sprawę i potrafi przewidzieć niektóre rzeczy i stworzyć taki kod, który będzie modyfikowalny w dalszej perspektywie.
Dlatego, gdy tą samą zmianę oddamy dwóm osobom z różnym doświadczeniem, może się okazać, że junior zrobi to szybciej niż senior – jednak jakość kodu juniora może być dość marna. Odwróci się to natomiast w momencie, gdy będzie trzeba zmienić zasady działania tej modyfikacji – może się okazać, że senior zmodyfikuje swój kod szybciej, niż junior, który w najgorszym wypadku najzwyczajniej usunie to co ma i napisze od nowa, zgodnie z nowymi wytycznymi.
W związku z marną jakością kodu zaciągamy tak zwany dług technologiczny. Powoduje on, że nasza aplikacja starzeje się szybciej niż powinna i każda następna modyfikacja „zjada” coraz więcej czasu i zasobów. Z czasem może się okazać, że nie będzie opłacało się już rozwijać danej aplikacji, ponieważ każda jej modyfikacja będzie niosła ze sobą duży nakład pracy.
Zdarzają się również takie przypadki, w których pomimo tego, że chcemy zrobić coś porządnie, biznes chce, by skrócić czas wdrożenia kosztem jakości –„ jakoś to będzie”. Bądźmy szczerzy – nawet najtrwalszy zawodnik nie jest w stanie ugiąć się pod naporem biznesu. Możemy oczywiście zrobić coś na szybko, jednak należy mieć z tyłu głowy naglącą potrzebę refaktoryzacji tego kawałka kodu. W pierwszej możliwej okazji należy przepisać lub zmodyfikować kod tak, by był podatny na zmiany w przyszłości – inaczej mówiąc, należy go „naprawić”.
Polub stronę PHPCenter.pl by zyskać dostęp do najnowszych wiadomości ze świata PHP!
Każdy z nas kiedyś zaczynał, prawda? Pamiętasz jak wyglądał Twój kod? Ja wolałbym się swoim nie chwalić 🙂
Jest kilka sposobów na to, by rozwijać się (jeśli jesteś juniorem) lub pomóc rozwijać się osobie z mniejszym doświadczeniem.
Najlepszym, i najłatwiejszym rozwiązaniem jest Code Review. Każda modyfikacja kodu przechodzi przez ręce bardziej doświadczonego programisty, który analizuje i wskazuje co należy zmienić, poprawić. Czyż nie powinniśmy uczyć się właśnie od lepszych od nas?
Doświadczenia można nabrać również czytając czyjś kod. Jeśli masz wolną godzinę, pobierz sobie Symfony, Zend czy inny popularny Framework, albo otwórz pliki które zostały napisane przez inne osoby z zespołu – czytaj, analizuj. Jeśli masz możliwość – zadawaj pytania, fora internetowe czy koledzy z zespołu bardzo chętnie podzielą się swoją wiedzą.
Twórz – pisząc kod zawsze masz kilka rozwiązań danego problemu – może warto by w wolnej chwili przysiąść do taska z zeszłego tygodnia, i przeanalizować go ponownie – co byś w nim zmienił? Możesz również przedstawić swoje myśli komuś doświadczonemu z zespołu, lub zapytać jak ten ktoś by to zrobił – ponownie, uczmy się od mądrzejszych od nas.
Artykuł ten miał na celu przedstawić różnice i efekty tych różnic pomiędzy dwoma developerami. Świadomość wyboru i ich konsekwencji jest ważna przy podejmowaniu decyzji. Należy rozważyć za i przeciw, ale przede wszystkim, należy kodować tak, by kod był podatny na zmiany, by był przyszłościowy – krótkowzroczność w dużych projektach powoduje duże straty.
A jak to wygląda u Was? Może macie odmienne zdanie? Podzielcie się swoimi spostrzeżeniami w komentarzach.
Najbardziej dociekliwy członek zespołu. Zainteresowany rozwojem osobistym i bezpieczeństwem IT. Zakochał się w programowaniu DDD i CQRS. Pomysłodawca portalu phpcenter.pl, autor wielu artykułów i milionów linii kodu.
Polub naszą stronę aby dostawać powiadomienia o nowych, niesamowitych treściach!
Artykuł spoko. Przyczępię się tylko do redakcji tekstu: masz powtórzenie:
„to późniejsza jego modyfikacja zajmie relatywnie mało czasu, ponieważ miejsce MIEJSCE na kolejne modyfikacje zostało w nim przewidziane wcześniej.”
Ah, starałem się to wyłapać, ale jednak gdzieś mi umknęło. Dzięki za czujność Bartosz 🙂