Тайна на ефективността — качествен код, а не ефективен мениджър

Една от най-претоварените специалности с идиоти са мениджърите, управляващи програмисти. Не всички, а тези, които никога не са били програмисти. Тези, които мислят, че може да се "повиши" ефективността (или да се повиши "ефективността"?) с методи от книжки. Дори не си направили труда да прочетат тези книжки — все пак има видео, нали.

Тези, които никога не са писали код. Тези, за които правят холивудски филми за програмисти — да, тези, в които електронната поща се гледа с команден ред. Тези, на които не им интересува нищо друго освен показатели, срокове и собствената им заплата.

Тези, които са мнозинство.

Но идиотите са идиоти по друга причина. Те искат ефективност или поне резултатност (давай, мениджър, гугли, каква е разликата), без да разбират нито едното, нито другото. Изобщо не разбират същността на процеса за получаване на резултат, загубите, които настъпват в този процес, разходите за разработка. С една дума, работят с програмист като с черна кутия.

Натрупаха се в управлението на програмисти точно по една причина: тук е хип, пари, пазар и куп такива идиоти. Има къде да се скрият.

Ако имаше хип в механосборъчната индустрия — щяха да се втурнат и там. Страшни универсали. Няма да се учудя, ако човекът, който продава коледни елхи през декември в нашия квартал, е ИТ-мениджър в отпуск.

С една дума, ако имате възможност, изгонете тези хора. Не се притеснявайте, те ще намерят работа. Никой от тях никога няма да направи нещо прилично, докато сам не стане програмист. Защото не разбира същността, механизма, логиката на процеса, който управлява.

Добре, достатъчно за мениджърите. Сега по същество, за програмистите. Как да повишим ефективността на разработката, научавайки се да пишем качествен код.

За да повишим ефективността, трябва по-бързо да решаваме задачи, без да губим качество. За да решаваме задачи по-бързо, трябва да можем веднага да пишем качествен код. И „качествен“, и „да пишем“, и „веднага“. Ще обясня с метафора.

Да пишеш качествен код е като да говориш правилно на чужд език. Когато не знаеш езика, харчиш куп време, за да формулираш мислите си на него.

Ако трябва да кажеш нещо спешно, просто лепиш какви да е думи, най-често не тези, които са нужни, забравяш за артиклите, правилния ред на думите, да не говорим за времето на глаголите и ужасното произношение.

Ако имаш време да формулираш отговора, ще трябва да отвориш речник или интернет преводач и да похарчиш куп време за формулирането на мислите си. Чувството обаче все още ще е неприятно: говориш отговора и не знаеш дали е правилен или не. Аналогично е и с кода – изглежда написал си, изглежда работи, а качествен ли е или не – не знам.

Получава се двойна загуба на време. За да измислиш отговор, отива време. За да формулираш този отговор, също отива време – а не малко.

Ако обаче умението да пишеш качествен код присъства, можеш да формулираш отговора веднага, щом той се е появил в главата ти, без да губиш допълнително време за превод.

Умението да пишеш качествен код помага при проектирането на архитектурата. Просто няма да обмисляш в главата си неправилни, неизпълними или несъвършени варианти.

В обобщение: умението да пишеш качествен код значително ускорява решаването на задачи.

Но и това не е всичко. Поради мениджърите с валенки, има един проблем – нямаме причина да пишем качествен код. Мениджърът не гледа кода, клиентът не гледа кода. Показваме си кода рядко, само понякога, в някои проекти, където има назначен "преглеждащ" кода или периодичен рефакторинг.

Така че, в повечето случаи, лошият код отива в продукция или при клиента. У човекът, написал лошия код, се формира устойчива невронна връзка – да пишеш лош код не само, че е позволено, но и е задължително – приемат го и му плащат за това.

В крайна сметка, умението да пишеш качествен код изобщо няма шансове да се развие. Кодът, написан от условен служител, не се проверява от никого и никога. Единствената причина, поради която той ще научи да програмира нормално – вътрешната мотивация.

Но тази вътрешна мотивация влиза в противоречие с плановете и изискванията за ефективност и продуктивност. Това противоречие явно не се разрешава в полза на качествения код, защото никой не се кара за лош код. А за неспазване на плана – още как.

Как да постъпя? Виждам и предлагам два пътя, които могат да бъдат комбинирани.

Първият - да показваш своя код на някой вътре в компанията. Не реактивно (когато те питат/настояват), а проактивно (ей, човече, погледни моя код, моля). Тук основното е да не разпространяваш сладка глупост, да не се опитваш да облечеш критиката на кода в учтива форма. Ако кодът е лош, ние просто казваме: кодът е лош. С обяснения, разбира се, и препоръки как да го направим по-добре.

Но и този път също не е идеален. Неговата приложимост зависи от момента, в който е настъпил контактът. Ако работата вече е пусната в продукция и се е установило, че кодът е лош, вече няма смисъл да бъде преработван. По-точно, нямаш основания - дори и метриките ще се сринат. Мениджърите ще се нахвърлят с изисквания за ефективност. И дори не опитвай да им обясняваш, че лошият код непременно ще се върне под формата на бъгове - това ще е проблем за теб. Можеш само да поемеш ангажимент да не го правиш повече.

Ако работата все още не е сдадена или тъкмо е започнала, тогава критиката на кода (или на проекта, или идеята) може да има съвсем практическо значение – човекът ще го направи правилно.

Вторият път, най-якият – да се занимаваш с опенсорс разработка в свободното си време. Целта е каква: да видят твоят код много програмисти, именно програмисти, и да се изкажат за него. Вътре в компанията на всички им е заето. А на програмистите от целия свят им е все едно, нямат какво да правят, и ако напишеш нещо полезно от практическа гледна точка, те определено ще погледнат вътре.

Основната идея, според мен, е да пишеш код в свободното си време, защото по този начин няма да се получи противоречие между качеството на кода и бързината на получаване на резултата. Пиши своята разработка цяла година. Няма да те притесняват нито срокове, нито технически задания, нито пари, нито шефове. Пълна свобода и творчество.

Само в свободното творчество ще разбереш и усетиш какво означава страхотен код, ще видиш красотата на ЯП и технологиите и ще усетиш прелестта на бизнес задачите. А и ще научиш как да пишеш качествен код.

Истината е, че това изисква от теб инвестиции на лично време. Както и всъщност всяко друго развитие. Разглеждай го не като разход, а като инвестиция – в себе си.

Източник: habr.com