Обща грешка на начинаещите разработчици на софтуер и как да го избегнем

Снимка от Fancycrave на Unsplash

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

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

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

Това е гадно !!!

Юк, тук има двеста линия линия.

Кой написа тази глупост!

О, Боже, има if-else блок в рамките на if-else блок.

Този код е голяма космати каша! еф.

Това трябва да се пренапише от нулата.

Бях бесен. Докато имах тези мисли, част от мен се чудеше, може ли да има начин да осмисля всичко това? Имаше ли някои неща, които не знаех, че тези старши момчета от моя екип, които написаха повечето от този код. Започнах да откривам.

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

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

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

Кодът е написан по различна причина

Повечето нови хора в разработката на софтуер, включително и аз, мислят, че кодът е написан за машини. Грешен. Нада. Написано е за хора. Машината дори не вижда JavaScript кода, който пишете, всичко, което виждат, е последователност от 0 и 1. И тъй като услугата за моя екип се изграждаше, имаше реални срокове с резултати, които трябваше да бъдат доставени. Софтуерните разработчици вече са много психически данъчни. Някъде в напрежението да се достави, придвижването на кода има предимство пред писането на супер естетически приятен код.

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

Производственият код е тестван битката

Моят екип получава много съобщения за инциденти, които понякога водят до критични корекции на грешки в кода. Грешка при обработката на клаузата if-else тук, опит за улов там и изведнъж цялата кодова база нарасна косми. Ето как кодовата база започва да получава месие въпреки най-добрите намерения.

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

Това, което работи е начинът

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

Антидотът

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

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

Станете любопитни

Започнете да питате защо!

Защо този код беше написан по този начин? Кой го е написал? Дали този човек все още е наоколо и мога ли да го попитам това / него. Какво знаят тези момчета, които аз не знам? Какъв е проблемът, който решава тази функция?

Повечето пъти ще бъдете изненадани от отговора.

Развивайте смирение

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

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

заключение

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

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