Написаните редове код не са мярка за производителност

Софтуерният разработчик е стойностен не когато пише много редове код, а когато споделя знанията си с колеги и спомага за развитието на екипа (снимка: CC0 Public Domain)

Колко реда код е написал даден разработчик? Количеството редове означава ли качество? Кое е по-важно – обемът или надеждността? Това са само част от въпросите, които вълнуват световната общност на софтуерните разработчици днес.

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

Твърди се, че „главният чуруликатор“ Илон Мъск е уволнил редица технолози само въз основа на изпратените редове код. Вярно или не, това ни връща към вечната главоблъсканица: „как да измерваме производителността на разработчиците?“ Въпросът отново надигна глава, след като уж бе постигнато някакво разбиране по темата. Трябва ли обаче да отидем още по-далеч и да зададем по-уместни въпроси като „трябва ли“ и „как“ да измерваме производителността на разработчиците и точно „кой“ трябва да я измерва?

Когато мерките престанат да бъдат полезни

Историята показва, че редовете код, броят на коригираните грешки и свързаните с всичко това измерители са пример за закона на Гудхарт — „когато една мярка стане цел, тя престава да бъде добра мярка“. След като компаниите са поели по този път в миналото, днес не бива да е изненада, ако сме свидетели на раздуване на кодовата база или нарочно вкарване на грешки, казва Джеф Уоткинс, главен продуктов и технологичен директор в xDesign.

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

Гениалните неща са прости

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

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

Махнете ръцете си от клавиатурата за момент

Опитните ръководители на екипи понякога стигат до крайност, като си търсят хора, които …. не пишат код. Защо? Има някои много важни съображения, които трябва да се вземат под внимание, преди да се пристъпи към писането на редовете. Обичайно трябва да си зададем важни въпроси, преди да започнем работа по кода, казва още Уоткинс. Ето някои от тези въпроси:

• Разбирате ли проблема, който се опитвате да разрешите?
• Този проблем решен ли е вече?
• Разбирате ли последиците от това, което ще напишете в кодовата база?
• Разбирате ли последиците извън кодовата база (за трети страни и т.н.) от промяната, която правите?
• Можете ли да напишете това, без да увеличавате кодовата база?
• Можете ли да го направите възможно най-семпло?
• Трябва ли първо да преосмислите нещо?
• Трябва ли да се пише точно сега?
• Изобщо трябва ли да се пише?

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

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

По-малкото често е повече

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

Как се използват показателите

Показателите за производителност на разработчиците трябва да са впрегнати в развиването на екипите като цяло, за разбиране на динамиката на екипа. Всички тези неща имат значение:  сътрудничеството, времето, прекарано онлайн, личната скорост, времето, прекарано в чакане на отзиви и др. Но метриките не бива да са пръчка, с която мениджърите да „бият“ хората си, а начин за използване на данни в името на нещо по-важно: подхранване на непрекъснато подобрение – както лично, така и на екипа. Мерките не бива да се използват за уволняване на хора или за оценяване представянето на разработчиците.

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