Szybki, ale niechlujny czy czysty, ale pisany dłużej? O jakości kodu

Ponad sto odpowiedzi, a niektóre plusowane przez 9 tysięcy użytkowników. Nie mogliśmy pominąć tej debaty na Quorze, dlatego przytaczamy wypowiedzi najchętniej popieranych seniorów. Chętnie poznamy też Wasze spostrzeżenia w temacie szybkiego, ale niechlujnego kodu czy też czystego kodu tworzonego o wiele dłużej od poprzednika.

Kevin Williams, jeden z użytkowników Quory, zadał pytanie, które (ponownie) wzbudziło zainteresowanie społeczności programistów. Którego programistę zatrudniasz: tego, który w ciągu trzech godzin pisze niechlujny kod, czy drugiego, który napisał perfekcyjny kod w ciągu dwunastu godzin? Odpowiedzi były tak ciekawe, że postanowiliśmy przytoczyć te najważniejsze. Znajdziecie w niej argumenty dotyczące zarówno tych pierwszych, jak i drugich.

Dług technologiczny

Khalid Cawl podczas pięciotygodniowego stażu zmierzył się z postawionym pytaniem. Sam był w tej grupie osób, która stara się jak najszybciej realizować taski, niekoniecznie przykładając się do jakościowego kodu. – Inny stażysta był raczej wolny, bardzo dużo czasu zajmowało mu podjęcie się napisania pierwszej linijki – pisze Cawl. Dodaje, że stażysta nie przejmował się krótkim terminem oddania projektu. Jego zachowanie nauczyło Khalida jednej rzeczy:

– Ten szybszy programista może napisze kod, który nie będzie zawierał błędów. Ale jeśli nie był to kod do jednorazowego użytku (omawiane zadanie dotyczyło testowego programu, który nie trafi na produkcję – przyp. red.), na pewno przysporzy wielu problemów innym programistom – pisze Khalid Cawl. Niechlujny kod utworzy dług technologiczny, który trudno będzie zniwelować, tym bardziej, że kolejne terminy będą gonić kolejnych programistów.

Suma rozwiązań

„Ten, który pisze kod w dziewięć godzin” – takim mianem określił się Emilio Garavaglia. W odpowiedzi na postawione pytanie napisał, że szybszy programista to zazwyczaj „coder”. Nie zastanawia się nad długofalowym rozwiązaniem problemu, tylko po prostu chce odhaczyć task. Z drugiej strony, siedzenie dwunastu godzin nad krótkim kodem to przesada. – Dobry programista nie tylko rozwiąże problem, ale chce zaproponować sumę potencjalnych rozwiązań – dodaje.

Zdaniem Emilio, zadaniem dobrego programisty jest zaproponowanie takiego rozwiązania, które przyda się także za kilka lat. Nie powinien jednak pracować nad kodem w nieskończoność, dlatego Garavaglia postanowił zmniejszyć wskazany czas do dziewięciu godzin. Czas na jedną z najchętniej plusowanych wypowiedzi w tym wątku – zebrała 8,4 tysiąca łapek w górę. Robin Thomas wprowadził pod dyskusję podział:

Oferty pracy z

Niechlujny programista

1. Otwiera Bugzillę, aby znaleźć błąd. Niczego nie znajduje, jest sfrustrowany. A to dopiero poniedziałek.

2. Wyszukuje w Google. Czeka. Ktoś opublikował dokładny problem na StackOverflow. Kopiuje z niego kod, mając nadzieję, że naprawi to błąd.

3. Testuje jeden prosty przypadek użycia. Kod działa! Brak testów jednostkowych. Wrzuca kod, czekając na jego sprawdzenie.

4. Nie każdy ma czas na review, biorąc pod uwagę krótkie terminy, w których wszyscy pracują. Kod został w jakiś sposób zatwierdzony i jest teraz w wydanym produkcie.

5. Zaczyna się prawdziwa zabawa. Nowy kod uaktywnił pozostałość z przeszłości, starą funkcję, która nigdy nie powinna znajdować się we wdrożonym kodzie. Ale tam leżała, czekając na aktywację.

6. Zanim firma zorientowała się, że niechciana funkcja psuje wizerunek, straty wyniosły ponad 400 mln USD. Powodzenia w uniknięciu bankructwa!

Dobry programista

1. Otwiera Bugzillę, aby znaleźć błąd. Trochę sfrustrowany. Kto by nie był?

2. Uruchomia debugger. Znajduje dokładnie ten sam problem, ale nie jest pewien, jak najlepiej go naprawić. Wyszukuje go w Google. Czeka. Ktoś opublikował dokładny problem na StackOverflow. Czyta kod i stwierdza, że ma sens.

3. Testuje jeden prosty przypadek użycia. Kod działa. Pisze więcej testów jednostkowych. Za każdym razem znajduje problem i naprawia go. Kod jest pozbawiony wszystkich poważnych błędów. Wrzuca kod, czekając na jego sprawdzenie.

4. Nie każdy ma czas na review, biorąc pod uwagę krótkie terminy, w których wszyscy pracują. Kod został w jakiś sposób zatwierdzony i jest teraz w wydanym produkcie.

5. Kod działa dokładnie zgodnie z zaleceniami. Nadchodzi wieczór i nasz programista wraca do domu, nigdy nie chwaląc się swoim sukcesem.

Typ od prototypów

Vipata Kilembo, który określa, że ma 27 lat doświadczenia w programowaniu, podsumował obydwie strony wymienionego pytania. Jego zdaniem warto zatrudnić obydwóch programistów. – Pracuję w startupie i mamy dwóch programistów – jeden tworzy prototypy i dema, które widzą później klienci. I tym gościem jestem ja! – pisze Kilembo.

– Tworzę szybko potrzebne sprzedawcom prototypy i dema, dzięki czemu możemy reagować na ich potrzeby. Dzięki temu jestem też typem, który dostaje do testowania nowe funkcjonalności i ma możliwość eksperymentowania, co zadziała, a co nie. Pozwala to nam na testowanie wszystkich naszych pomysłów, oszczędzając czas i pieniądze – pisze Vipata Kilembo.

Poznaliście już zdanie najchętniej plusowanych seniorów. Zapraszamy do dyskusji, wypowiedzcie się w komentarzach.

Zdjęcie główne artykułu pochodzi z unsplash.com.