Jednym z najbardziej idiotycznych zawodów są menedżerowie zarządzający programistami. Nie wszyscy, ale ci, którzy sami nie byli programistami. Ci, którzy uważają, że można „zwiększyć” efektywność (lub zwiększyć „efektywność”?) stosując metody z książek. Nawet nie zadając sobie trudu przeczytania tych samych książek, wideo jest cygańskie.
Ci, którzy nigdy nie pisali kodu. Ci, dla których kręci się hollywoodzkie filmy o programistach – cóż, tacy, dla których oglądają pocztę za pomocą wiersza poleceń. Tych, których nie interesuje nic innego jak tylko wskaźniki, terminy i własne wynagrodzenie.
Ci, którzy stanowią większość.
Ale oni są idiotami z innego powodu. Chcą efektywności, a przynajmniej skuteczności (no daj spokój, menadżerze, Google, jaka jest różnica), nie rozumiejąc ani jednego, ani drugiego. Bez ogólnego zrozumienia istoty, procesu uzyskiwania wyniku, strat jakie w tym procesie powstają, kosztów rozwoju. Krótko mówiąc, praca z programistą jak z czarną skrzynką.
Natknęli się na menedżerów programistów dokładnie z jednego powodu: jest szum, pieniądze, rynek i banda tych samych idiotów. Jest gdzie się zgubić.
Gdyby wokół produkcji zespołów mechanicznych panował szum, pobieglibyśmy tam. Kombi są do bani. Wcale bym się nie zdziwił, że facet sprzedający w grudniu choinki w naszej okolicy jest na wakacjach menadżerem IT.
Krótko mówiąc, jeśli to możliwe, strzelajcie tym chłopakom w szyję. Nie martw się, znajdą pracę. Żaden z nich nie zrobi nic porządnego, dopóki sam nie zostanie programistą. Bo nie rozumie istoty, mechanizmu, logiki procesu, którym steruje.
Dobra, dość o menadżerach. A teraz do rzeczy, dla programistów. Jak zwiększyć efektywność programowania poprzez naukę pisania wysokiej jakości kodu.
Aby zwiększyć wydajność, musisz szybciej rozwiązywać problemy bez utraty jakości. Aby szybciej rozwiązywać problemy, musisz mieć możliwość natychmiastowego napisania kodu wysokiej jakości. I „wysokiej jakości”, „pisz” i „natychmiast”. Wyjaśnię to metaforą.
Pisanie wysokiej jakości kodu jest jak poprawne mówienie w języku obcym. Jeśli nie znasz języka, spędzasz dużo czasu próbując formułować w nim swoje myśli.
Jeśli musisz coś pilnie powiedzieć, po prostu trzymasz się słówek, często niewłaściwych, zapominasz o rodzajnikach, właściwej kolejności wyrazów, nie mówiąc już o czasach czasowników i słabej wymowie.
Jeśli masz czas na sformułowanie odpowiedzi, będziesz musiał otworzyć słownik lub tłumacza online i spędzić dużo czasu na formułowaniu swoich myśli. Jednak uczucie nadal będzie nieprzyjemne: mówisz odpowiedź i nie wiesz, czy jest ona prawidłowa, czy nie. Podobnie jest z kodem – wydaje się, że został napisany, wydaje się działać, ale czy jest dobrej jakości, czy nie, pozostaje tajemnicą.
Okazuje się, że jest to podwójna strata czasu. Znalezienie odpowiedzi wymaga czasu. Sformułowanie tej odpowiedzi również wymaga czasu – i to niemałego.
Jeśli istnieje umiejętność pisania kodu wysokiej jakości, odpowiedź można sformułować natychmiast, gdy tylko dojrzeje w głowie, bez poświęcania dodatkowego czasu na tłumaczenie.
Umiejętność pisania wysokiej jakości kodu pomaga przy projektowaniu architektury. Po prostu nie będziesz rozważać w swojej głowie nieprawidłowych, niemożliwych do zrealizowania lub opuszczonych opcji.
Podsumowując: umiejętność pisania wysokiej jakości kodu znacząco przyspiesza rozwiązywanie problemów.
Ale to nie wszystko. Dzięki menadżerom butów filcowych jest jeden haczyk – nie mamy powodu pisać kodu wysokiej jakości. Menedżer nie patrzy na kod, klient nie patrzy na kod. Rzadko pokazujemy sobie kod, tylko czasami, w niektórych projektach, gdzie jest wyznaczony „weryfikator” kodu lub okresowa refaktoryzacja.
Okazuje się, że w większości przypadków gówniany kod trafia na produkcję lub do klienta. Osoba, która napisała gówniany kod, tworzy stabilne połączenie neuronowe – nie tylko da się napisać gówniany kod, ale jest to konieczne – jest to akceptowane i nawet za to płaci.
W rezultacie umiejętność pisania wysokiej jakości kodu nie ma w ogóle szans się rozwinąć. Kod napisany przez pracownika warunkowego nigdy nie jest przez nikogo sprawdzany. Jedynym powodem, dla którego nauczy się normalnie programować, jest motywacja wewnętrzna.
Jednak ta wewnętrzna motywacja jest sprzeczna z planami i wymaganiami dotyczącymi wydajności i produktywności. Ta sprzeczność wyraźnie nie jest rozwiązywana na korzyść kodu wysokiej jakości, ponieważ ludzie nawet nie krytykują ludzi za gówniany kod. I za niezrealizowanie planu - mimo wszystko.
Co powinienem zrobić? Widzę i proponuję dwie ścieżki, które można połączyć.
Pierwszym z nich jest pokazanie kodu osobie wewnątrz firmy. Nie reaktywnie (kiedy zostaniesz o to poproszony/zmuszony), ale proaktywnie (no, stary, spójrz na mój kod, proszę). Najważniejsze, żeby nie publikować słodkich smarków i nie próbować wyrażać krytyki kodu w grzecznej formie. Jeśli kod jest bzdurą, mówimy to: kod jest bzdurą. Oczywiście z wyjaśnieniami i zaleceniami, jak to ulepszyć.
Ale ta ścieżka też jest taka sobie. Jego zastosowanie zależy od punktu, w którym nastąpił kontakt. Jeżeli praca poszła już na produkcję i okazuje się, że kod jest do niczego, to nie ma sensu go przerabiać. Dokładniej, powody - wskaźniki również ulegną upadkowi. Menedżerowie wkroczą i zmiażdżą Cię wymaganiami dotyczącymi wydajności. I nawet nie próbuj im wyjaśniać, że ten gówniany kod na pewno powróci w postaci błędów – obróci się to przeciwko tobie. Możesz jedynie zobowiązać się, że więcej tego nie zrobisz.
Jeśli praca nie została jeszcze dostarczona lub dopiero się rozpoczęła, to obsypywanie kodem (lub jego projektem, pomysłem) gównem może mieć całkiem praktyczne znaczenie - osoba zrobi to normalnie.
Drugi sposób, najfajniejszy, polega na rozwijaniu oprogramowania open source poza godzinami pracy. Jaki jest cel: aby grupa programistów, mianowicie programistów, zobaczyła Twój kod i porozmawiała o nim. Wszyscy w firmie nie mają czasu. Ale programiści na całym świecie nadal nie mają nic do roboty, a jeśli napiszesz coś przydatnego z aplikacyjnego punktu widzenia, na pewno zajrzą do środka.
Moim zdaniem główną sztuczką jest pisanie kodu poza godzinami pracy, ponieważ sprzeczność między jakością kodu a szybkością dostarczenia wyniku nie zadziała. Napisz swój rozwój przynajmniej na rok. Ani terminy, ani specyfikacje techniczne, ani pieniądze, ani szef nie będą na Ciebie wywierać presji. Pełna swoboda i kreatywność.
Tylko w swobodnej kreatywności zrozumiesz i poczujesz czym jest wspaniały kod, dostrzeżesz piękno języka i technologii oraz poczujesz urok zadań biznesowych. Cóż, nauczysz się pisać kod wysokiej jakości.
To prawda, że będzie to wymagało poświęcenia czasu osobistego. Rozwój jak każdy inny. Potraktuj to nie jako koszt, ale jako inwestycję – w siebie.
Źródło: www.habr.com