Софтуерният разработчик е стойностен не когато пише много редове код,

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

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

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

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

Когато ограниченията престанат да бъдат потребни

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

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

Гениалните неща са елементарни

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

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

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

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

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

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

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

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

Как се употребяват индикаторите

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

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