„Правилно ли правя това?“

Въпросът възниква, защото чувствам добре, а това означава, че съм добре.

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

Разходи за обсъждане

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

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

Разходи за осиновяване

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

Съвет: Осигурете прогнози за приемане и проследете задачи като писане на документация и споделяне на знания с по-голямата група. Програмирането по двойки също е чудесен начин да получите повече осиновители и да свършите работа едновременно.

Цената на сложността

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

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

Разходи за включване

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

Съвет: Когато оценявате компромисите, покажете потенциални пристрастия и обсъдете с групата дали това може да има ефект върху предложението. Избягвайте да използвате език като „чувства се естествено“ или „просто се чувства правилно“. Опитайте се да поискате обратна връзка от всички нива на инженерство, а не само от старши инженери. Не мисля, че има едно-единствено решение за решаване на проблемите с включването в една организация, но честната комуникация е добро място за начало.

Цената на грешката

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

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

Надявам се, че тази статия ще помогне за разширяване на перспективата за инженерните компромиси. Ако имате някакви предложения или отзиви, аз съм @kaylie_alexa в Twitter.

Също така благодаря на Бен Илегбоду и Мария Казанджиева за идеите и предложенията!