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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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