Jednym z najbardziej przeładowanych idiotami zawodów są menedżerowie zarządzający programistami. Nie wszyscy, a ci, którzy nigdy nie byli programistami. Ci, którzy myślą, że można «zwiększać» efektywność (lub podnosić «efektywność»?) metodami z książek. Nawet nie racząc się przeczytać tych książek — w końcu jest filmik.
Ci, którzy nigdy nie pisali kodu. Ci, dla których nakręca się hollywoodzkie filmy o programistach — no, te, w których e-maile ogląda się z linii poleceń. Ci, którym nie interesuje nic, oprócz wyników, terminów i własnej pensji.
Ci, których jest większość.
Ale idioci są z innego powodu. Chcą efektywności, albo chociaż skuteczności (no dalej, menedżerze, googluj, jaka jest różnica), nie rozumiejąc ani tego, ani tamtego. W ogóle nie pojmując istoty, procesu osiągania wyników, strat, jakie następują w tym procesie, nakładów na rozwój. Krótko mówiąc, pracując z programistą, jak z czarną skrzynką.
Zjawili się w zarządzaniu programistami dokładnie z jednego powodu: tu jest hype, pieniądze, rynek i mnóstwo podobnych idiotów. Jest gdzie się ukryć.
Gdyby był hype w produkcji mechanicznej — rzuciliby się tam. Złote uniwersały. Nie zdziwiłbym się, gdyby facet sprzedający choinki w grudniu w naszej okolicy był menedżerem IT na urlopie.
Krótko mówiąc, jeśli masz możliwość, przepędź tych chłopaków. Nie martw się, znajdą sobie pracę. Nikt z nich nigdy nie zrobi nic przyzwoitego, dopóki sam nie stanie się programistą. Ponieważ nie rozumie istoty, mechanizmu, logiki procesu, którym zarządza.
No dobrze, dość o menedżerach. Teraz do rzeczy, dla programistów. Jak zwiększyć efektywność rozwoju, ucząc się pisać jakościowy kod.
Aby zwiększyć efektywność, trzeba szybciej rozwiązywać zadania, nie tracąc jakości. Aby szybciej rozwiązywać zadania, trzeba umieć od razu pisać jakościowy kod. I «jakościowy», i «pisać», i «od razu». Wyjaśnię metaforą.
Pisanie jakościowego kodu jest jak poprawne mówienie w obcym języku. Kiedy nie znasz języka, tracisz mnóstwo czasu na formułowanie swoich myśli.
Kiedy trzeba mówić szybko, po prostu nabazgrzesz jakieś słowa, często nie te, które trzeba, zapomnisz o artykułach, poprawnym porządku słów, nie wspominając już o czasach czasowników i słabym wymowie.
Jeśli jest czas na sformułowanie odpowiedzi, trzeba otworzyć słownik lub internetowy translator i spędzić mnóstwo czasu na formułowaniu swoich myśli. Uczucie, prawda, i tak będzie nieprzyjemne: odpowiadasz, a nie wiesz, czy masz rację, czy nie. Podobnie z kodem – jakbyś napisał, wydaje się, że działa, ale czy jest jakościowy, to już inna sprawa.
Okazuje się, że to podwójna strata czasu. Na wymyślenie odpowiedzi potrzeba czasu. Na sformułowanie tej odpowiedzi również potrzeba czasu – przy czym, wcale nie tak mało.
Jeśli jednak umiejętność pisania jakościowego kodu jest obecna, można sformułować odpowiedź od razu, gdy tylko dojrzeje w głowie, nie tracąc dodatkowego czasu na tłumaczenie.
Umiejętność pisania jakościowego kodu pomaga przy projektowaniu architektury. Po prostu nie będziesz rozważał w głowie błędnych, nierealizowalnych lub nieudolnych wariantów.
Podsumowując: umiejętność pisania jakościowego kodu znacznie przyspiesza rozwiązywanie problemów.
Ale to nie wszystko. Dzięki menedżerom, jest jedna zagwozdka – w końcu nie mamy powodu, by pisać jakościowy kod. Menedżer nie patrzy na kod, klient nie patrzy na kod. Rzadko pokazujemy sobie nawzajem kod, tylko czasami, w niektórych projektach, gdzie jest wyznaczony 'recenzent' kodu lub okresowy refaktoring.
W rezultacie w większości przypadków słaby kod trafia do produkcji lub do klienta. U osoby, która napisała słaby kod, tworzy się trwałe połączenie neuronowe – pisać słaby kod można nie tylko, ale i trzeba – akceptują go, a nawet płacą za to.
W efekcie umiejętność pisania jakościowego kodu nie ma w ogóle szans na rozwój. Kod napisany przez jakiegoś pracownika nie jest nigdy sprawdzany przez nikogo. Jedynym powodem, dla którego nauczy się normalnie programować – jest wewnętrzna motywacja.
Jednak ta wewnętrzna motywacja stoi w sprzeczności z planami i wymaganiami dotyczącymi efektywności i produktywności. Sprzeczność ta rozwiązuje się wyraźnie nie na korzyść jakościowego kodu, bo za słaby kod nawet nie są karani. A za niewykonanie planu – jak najbardziej.
Co zrobić? Widzę i proponuję dwie drogi, które można połączyć.
Pierwsza - pokazywanie swojego kodu komuś wewnątrz firmy. Nie reaktywnie (gdy proszą/zmuszają), a proaktywnie (ej, kolego, zobacz mój kod, proszę). Tu najważniejsze - nie owijać w bawełnę, nie starać się ubierać krytyki kodu w grzeczną formę. Jeśli kod jest zły, mówimy tak: kod jest zły. Oczywiście z wyjaśnieniami i rekomendacjami, jak go poprawić.
Ale ta droga też nie jest idealna. Jej zastosowanie zależy od momentu, w którym nastąpił kontakt. Jeśli praca trafiła już do produkcji, a okazało się, że kod jest zły, nie ma sensu go poprawiać. Dokładniej mówiąc, powód - spadną także metryki. Zastąpią nas menedżerowie i zasypią wymaganiami dotyczącymi efektywności. I nawet nie próbuj im tłumaczyć, że zły kod wróci w postaci błędów - to wyjdzie ci na złe. Można jedynie wziąć na siebie zobowiązanie, aby więcej tego nie robić.
Jeśli jednak praca nie jest jeszcze oddana, lub dopiero się zaczyna, to krytyka kodu (lub samego projektu, pomysłu) może mieć całkiem praktyczny sens - człowiek zrobi to dobrze.
Druga droga, najfajniejsza - zająć się rozwojem open source w czasie wolnym. Bo celem jest, aby mnóstwo programistów, właśnie programistów, zobaczyło twój kod i wyraziło swoją opinię na jego temat. W firmie nikt nie ma na to czasu. A programiści z całego świata i tak nie mają co robić, więc jeśli napiszesz coś użytecznego z praktycznego punktu widzenia, na pewno zajrzą do środka.
Główna zasada, moim zdaniem - to pisanie kodu w czasie wolnym, ponieważ nie będzie sprzeczności między jakością kodu a szybkością dostarczania wyników. Możesz pisać swój projekt przez rok. Nikt nie będzie na ciebie naciskał - ani terminy, ani specyfikacje, ani pieniądze, ani szef. Pełna wolność i twórczość.
Tylko w wolnym twórczym działaniu zrozumiesz i poczujesz, co to jest świetny kod, zobaczysz piękno języków programowania i technologii, doświadczysz uroków wyzwań biznesowych. No i nauczysz się pisać jakościowy kod.
Prawda, to wymaga od ciebie poświęcenia czasu osobistego. Tak jak każda inna forma rozwoju. Patrz na to nie jak na koszt, a jak na inwestycję - w siebie.
Źródło: habr.com
