Code Calligraph VS Code Пилешко надраскване

През последните 17 години съм работил по над 90 проекта с много екипи. Но едва когато се натъкнах на blameфункцията на Git , научих за „почерка“ на всеки кодер. Това просто любопитство скоро се превърна в навик. Винаги, когато виждах нов код, се опитвах да позная кой го е написал. Тогава щях да проверя предположението си с git blame.

(Между другото, ако все още не сте запознати с git, това е популярен начин за разработчиците да си сътрудничат по код и неговата функция „вина“ ви показва кой е автор на даден ред изходен код.)

След няколко години започнах да виждам модели, точно както експертът по почерк може да открие социопат от начина, по който те нарисуват своите W. Почеркът на кода разкрива много за програмиста, който го е написал.

Можете да научите почти всичко от ръкописния код на програмист: колко опит имат, колко се грижат за четливостта на техния код (и като цяло, колко много се грижат за своите съотборници).

Кодови разговори. Лош код крещи! И така, кодът, който четете, е калиграфия на кода или това е пилешко надраскване?

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

Статистика # 1: Раздут код = борба

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

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

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

„Мразя кода и искам възможно най-малко от него в нашия продукт“ - Джак Дидерих

Статистика # 2: Мъртъв код = небрежност

Виждали ли сте някога огромни блокове коментиран код, ангажирани с репото? Или още по-лошо: код, който не прави нищо особено, но има ли го по исторически причини?

Интересното е, че това има пряка връзка с бъркотията на бюрото на програмиста, който го е написал. Виждали ли сте някога остарели коментари или тестове? Да, намерихте невнимателен програмист.

3. Комплексен код = глупост или алчност

Обичам този цитат от Шумахер:

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

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

Статистика # 4: Коментари = отборен играч (освен ако ...)

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

Наистина ми харесва, когато програмистите поставят връзка към справка за API или съответния въпрос за преливане на стека, когато осъзнаят, че техните връстници (или бъдещото им аз) ще поставят под въпрос определен ред код.

Като се има предвид това, прекаленото използване на коментари показва липса на самочувствие (или както споменах по-рано, опитвайки се да обясня „раздутия код“).

Статистика # 5: Имена = умение за комуникация

Имена на променливи, имена на функции, имена на параметри, имена на класове. Това са основното ниво на комуникация с поддържащите код.

Ако срещнете имена с една буква (с изключение на това i, което е по подразбиране в forциклите), сте намерили програмист с липса на комуникативни умения или съпричастност към другите.

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

И ако функционалността на даден обект се промени, важно е съответно да рефакторирате името му.

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

Статистика # 6: Лоша четливост = липса на плавност

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

JavaScript е един от тези лоши целеви езици.

Повечето програмисти от задния край имат лукса да изберат своя „майчин език“. И мнозина са достатъчно смели, за да хакнат заедно няколко реда преден код. Но тъй като браузърът е предимно JavaScript (който е гъвкав език), те се опитват да имитират онова, което някога им е познато от техния „майчин език“.

Всичко това е добре и добре, докато действителен програмист на JavaScript не види кода и не им извади косите!

Статистика # 7: Хакове = плитка личност или липса на дисциплина

Винаги ли сте прекарвали много време в подреждането на кодова база, само за да станете свидетел на това как вашият връстник излива бензин по целия ви красив код, като го използвате като платформа за бързи и мръсни поправки?

Поздравления: срещнахте хакер!

Хакерите се справят отлично с бързи корекции, без да се притесняват да разберат цялостно архитектурата (обикновено чрез суетата с дебъгер или чрез проби и грешки).

И така, какъв е уловът? Те решават един проблем и създават 10 други.

Консултантите са склонни да показват това поведение (тъй като времето им е скъпо и няма да живеят с последствията от промените си). Освен това те могат да получат пари, за да решат тези 10 други проблема и да посеят сигурност на работното място, като направят 100 нови.

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

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

Прозрение # 8: Непоследователност = гордост и фанатизъм

Когато сте в Рим, правете това, което правят римляните. - поговорка

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

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

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

Insight # 9 WET код = лоша памет

Обратното на Dry („Не се повтаряйте“) е WET („Радваме се да пишете“ или „Напишете всичко два пъти“).

Е, грешките се възпроизвеждат чрез разхвърлян процес, наречен „копиране“ и „поставяне“.

Има изненадващо много видове WET код. Например:

  1. Функция или клас, написани два пъти, само с малки разлики
  2. Променлива, която съдържа стойността на друга променлива
  3. Набор от повтарящи се инструкции, които могат да се намират във функция

Това се различава от раздутия код, тъй като вместо да бъде просто сложен или усукан, WET кодът се повтаря буквално.

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

Статистика # 10. Временни решения = липса на дисциплина

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

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

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

Статистика # 11: Много зависимости = невнимание за бъдещето на проекта

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

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

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

Има три мотивации за ненужни зависимости:

Причина №1: Разработчикът е твърде нетърпелив да научи нови неща.

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

Любопитството е добро, но трябва да има и други платформи за обучение, като странични проекти, краткосрочни задачи или хакатони.

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

Причина №2: Това се прави от прекалено амбициозен младши разработчик.

Новодошлите във всяка област са склонни да бъдат затрупани от всички нови модни думи и поради разочарование или невежество (или препоръката на „професионалист“) те могат да решат да „скочат в басейна“ и да научат всичко наведнъж. Не им позволявайте. Изберете вашата технология.

Причина # 3: Разработчикът има багаж от друга работа (или страничен проект)

Те искат да имат предимство пред връстниците си, като внасят нещо, което само те много добре знаят.

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

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

Добрите разработчици се грижат за бъдещето на своя проект, защото са прекарали най-крайния и ценен ресурс, за да го създадат: своето време!

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

Кодова калиграфия

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

Някои дори казват „кодът е поезия“.

Изходният код за jQuery или lodash са чудесни примери, но почти всички популярни библиотеки на Github, че много участници в крайна сметка ще се сближат с красотата. Това, приятели мои, е чудесна кодова калиграфия .

По същество страхотният код е:

  1. Лесен за четене, следване и отстраняване на грешки
  2. Гъвкав, конфигурируем и разтегателен
  3. Интелигентно с използване на ресурси
  4. Висока производителност

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

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

Хареса ми четеното? Последвайте ме, за да получавам известие, когато пиша нещо ново.

Също така може да искате да проверите защо програмирането е най-добрата работа досега.