Code Calligraph VS Code Курячі подряпини

За останні 17 років я працював над 90 проектами з багатьма командами. Але лише коли я натрапив на blameфункцію Git , я дізнався про “почерк” кожного кодера. Ця проста цікавість незабаром увійшла у звичку. Щоразу, коли я бачив новий код, я намагався вгадати, хто його написав. Тоді я перевірив би моє припущення за допомогою git blame.

(До речі, якщо ви ще не знайомі з git, це популярний спосіб для розробників співпрацювати над кодом, а його функція "звинувачення" показує, хто є автором даного рядкового вихідного коду.)

Через пару років я почав бачити закономірності, подібно до того, як експерт з рукописного вводу може виявити соціопата з того, як вони малюють свої Ш. Почерк коду розкриває багато про програміста, який його написав.

Ви можете дізнатись про що завгодно з рукописного вводу програміста: скільки досвіду вони мають, наскільки вони дбають про читаність свого коду (і, розширюючись, наскільки вони дбають про своїх товаришів по команді).

Кодекс переговорів. Поганий код кричить! То чи код коду, який ви читаєте, є кодом каліграфії чи це код курячого нуля?

Швидке застереження: те, що ви збираєтеся прочитати, ґрунтується виключно на моїй суб’єктивній інтуїції. Наскільки мені відомо, жодного рецензованого академічного дослідження не було. Мої навички аналізу рукописного вводу коду добре мені допомогли в минулому, і, можливо, допоможуть і вам, але - як і в усьому, що ви читали в Інтернеті - ваш пробіг може відрізнятися.

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

Зазвичай, коли я виявляю код, який став роздутим і набагато більшим, ніж він повинен бути, він показує програмісту, який намагався виконати завдання, яке перевищувало їхні можливості. Вони або не мали знань, ані часу, щоб закінчити роботу належним чином.

У реальному житті люди, які роблять менше, схильні більше говорити . Те ж саме відбувається в коді: ті, хто не може елегантно виконати роботу, прагнуть писати багато коду.

На жаль, помилки ласують кодом, і чим більше положень коду, тим більше середовище існування помилок.

«Я ненавиджу код, і я хочу якомога менше його в нашому продукті» - Джек Дідеріх

Статистика # 2: Мертвий код = неохайність

Ви коли-небудь бачили величезні блоки коментованого коду, присвячені репо? Або ще гірше: код, який не робить нічого особливого, але є з історичних причин?

Цікаво, що це має пряму кореляцію з безладдям робочого столу програміста, який його написав. Ви коли-небудь бачили застарілі коментарі чи тести? Так, ти знайшов недбайливого програміста.

3. Складний код = дурість або жадібність

Мені подобається ця цитата Шумахера:

“Будь-який розумний дурень може зробити речі більшими, складнішими та жорстокішими. Потрібні нотки геніальності - і багато сміливості, щоб рухатись у зворотному напрямку ". - Фріц Шумахер

Якщо ви знайшли код, за яким важко слідувати або зрозуміти, будьте впевнені, що його написав або той, хто не має уявлення про те, що робить, або той, хто шукає безпеку роботи, приймаючи "право власності" на цю частину коду.

Статистика # 4: Коментарі = командний гравець (якщо…)

Усі мови високого рівня дозволяють писати код, який є достатньо читабельним, і вам не потрібні коментарі. Але іноді складність неминуча через брак знань, часу чи елегантних рамок.

Мені дуже подобається, коли програмісти розміщують посилання на посилання на API або відповідне запитання щодо переповнення стека, коли вони усвідомлюють, що їх однолітки (або їх майбутній власний персонал) поставлять під сумнів певний рядок коду.

З огляду на це, надмірне використання коментарів свідчить про відсутність самооцінки (або, як я вже згадував раніше, намагаючись пояснити "роздутий код").

Статистика # 5: Імена = навик спілкування

Імена змінних, імена функцій, імена параметрів, імена класів. Це базовий рівень спілкування з розробниками коду.

Якщо ви стикаєтесь з однобуквеними іменами (за винятком i, що є типовим у forциклах), ви виявили програміста з відсутністю навичок спілкування чи співпереживання з іншими.

Якщо це не тимчасовий проект, який не збирається демонструвати комусь іншому або підтримувати, кожна секунда, вибрана для підбору відповідного імені, призводить до доброї карми.

І якщо функціональність сутності змінюється, важливо відповідним чином переформатувати її назву.

Деякі програмісти стверджують, що імена не важливі, оскільки машинам все одно. Ну, якщо ви не пишете код буквально нулями та одиницями, ви пишете код і для людей!

Статистика # 6: Погана читабельність = відсутність вільності

Іноді програмісти вільно володіють однією мовою, але вони намагаються скрутити та зігнути іншу мову, щоб поводитись як улюблена мова.

JavaScript - одна з тих поганих цільових мов.

Більшість програмних розробників мають розкіш, щоб вибрати свою "рідну мову". І багато з них сміливі, щоб зламати кілька рядків інтерфейсного коду. Але оскільки браузер - це переважно JavaScript (що є гнучкою мовою), вони намагаються імітувати те, що коли-небудь знайоме їм з їхньої “рідної мови”.

Це все добре і добре, поки справжній програміст JavaScript не побачить код і не вирве їх за волосся!

Статистика # 7: Хаки = неглибока особистість або відсутність дисципліни

Ви коли-небудь витрачали багато часу на приведення в порядок кодової бази, лише щоб засвідчити, як ваш колега розливає бензин по всьому гарному коду, використовуючи його як платформу для швидких і брудних виправлень?

Вітаємо: ти зустрів хакера!

Хакери чудово роблять швидкі виправлення, не турбуючись цілісно зрозуміти архітектуру (як правило, суєтою з налагоджувачем або шляхом спроб і помилок).

Отже, в чому улов? Вони виправляють одну проблему, а створюють 10 інших.

Консультанти схильні демонструвати таку поведінку (оскільки їхній час дорогий, і вони не збираються жити з наслідками своїх змін). Крім того, вони можуть отримати гроші, щоб виправити ці 10 інших проблем і посіяти безпеку роботи, зробивши 100 нових.

Тим не менше, я був свідком внутрішніх програмістів, які роблять навіть найохайніших консультантів схожими на рок-зірки. Ви коли-небудь вважали, що проблема займає 8 годин, але якийсь менеджер із продуктів скорочує вашу оцінку лише до 1 години? Зазвичай це коли народжуються хаки.

Зважаючи на це, іноді вам потрібна швидка доставка (наприклад, на етапі створення прототипу в стартапі для перевірки ідеї), і прийнято скорочувати ситуацію через обмежені ресурси. Нікого не хвилює гарний код, який не вирішить жодної проблеми. Але все-таки є різниця між різанням ножицями або рубанням мачете!

Інсайт 8: Непослідовність = гордість і фанатизм

Перебуваючи в Римі, робіть так, як роблять римляни. - прислів'я

Існує так багато конвенцій про кодування. Насправді не має значення, який із них обраний. Але коли ваша команда дотримується певних умов, дуже важливо дотримуватися їх.

Якщо співавтори ігнорують деякі або всі конвенції, вони або зламаються, або занадто пишаються тим, що змінюють свій стиль відповідно до вашої кодової бази.

Найгірше - це те, коли вони домагаються власних конвенцій. Це чистий фанатизм. І ви можете бути впевнені, що програміст також обмежений в інших питаннях.

Статистика # 9 WET код = погана пам'ять

Протилежність Dry («Не повторюйся») - це WET («Ми насолоджуємось набором тексту» або «Напиши все двічі»).

Ну, помилки розмножуються через безладний процес, який називається "скопіювати" та "вставити".

Існує напрочуд багато типів WET-коду. Наприклад:

  1. Функція або клас, написаний двічі, лише з незначними відмінностями
  2. Змінна, що містить значення іншої змінної
  3. Набір повторюваних інструкцій, які можуть міститися у функції

Це відрізняється від роздутого коду, оскільки WET-код, а не просто складний або скручений, буквально повторюється.

Зазвичай повторюваний код - це ознака того, що програміст не може згадати (або ще гірше - не бачив) іншого подібного коду. Одним з головних завдань людського мозку є виявлення закономірностей. Коли програміст не може виявити подібний код, це ознака недосвідченості або неуважності до деталей.

Статистика No10. Тимчасові обхідні шляхи = відсутність дисципліни

Іноді розробники вводять швидке і брудне рішення як тимчасове рішення, сподіваючись, що одного дня вони зможуть його рефакторингувати. Зазвичай це відбувається через близький термін або відсутність знань. Але, як ми всі знаємо, тимчасові обхідні шляхи можуть залишитися.

Тимчасові обхідні шляхи вказують на прагматичного інженера, якому не вистачає смаку чи гордості за свою роботу. Вони також можуть бути ознакою низької самооцінки, оскільки вони не хочуть розчаровувати когось іншого (начальника, клієнта тощо).

Тимчасовий обхідний шлях є прийнятним лише для навчального проекту чи створення прототипів (доказ концепції). І навіть у цих випадках найкраще переробляти його, як тільки ви знаєте, як це зробити правильно.

Статистика # 11: Багато залежностей = необережність щодо майбутнього проекту

Залежності потрібно постійно оновлювати. Коли проект має занадто багато залежностей, це ознака неохайності.

Важко сказати, що "занадто багато", але основне правило таке: якщо проект може легко вижити без залежності, він зайвий.

Іншим заходом є те, що якщо немає необхідної вимоги до основної проблеми, яку вирішує залежність, це, мабуть, непотрібно.

Існує три мотиви для непотрібних залежностей:

Причина №1: Розробник занадто прагне вивчати нові речі.

Імпортуючи нові залежності, вони отримують можливість навчатись у реальному проекті.

Допитливість - це добре, але для навчання повинні бути інші платформи, такі як побічні проекти, короткострокові завдання чи хакатони.

Ви не хочете втратити хорошого розробника, тому що вони думають, що не можуть рости на своїй роботі, але ви також не хочете, щоб вони поводились з вашим продуктом, як зі своїм домашнім проектом.

Причина 2: Це робить надмірно амбіційний молодший розробник.

Новачки в будь-якій галузі, як правило, перевантажені новими модними словами, і з розчарування чи незнання (або рекомендації "професіонала") вони можуть вирішити "стрибнути в пул" і навчитися всьому одразу. Не дозволяйте їм. Виберіть свою технологію.

Причина №3: ​​Розробник має багаж з іншої роботи (або допоміжного проекту)

Вони хочуть мати перевагу над своїми однолітками, приносячи щось, що тільки вони дуже добре знають.

На жаль, цього простого рішення немає, але м’які навички: команда повинна поставити під сумнів вибір кожного з залежностей, і якщо існує належний процес перегляду коду та злиття, це ускладнює вкрадання жахливого коду, не помічаючи цього.

Іноді ковбой, про якого йде мова, може здійснити масивний рефакторинг, а потім поставити команду в положення прийняти всю зміну, оскільки це вже зроблено. Ну, не треба! Попросіть їх розбити свій запит на вилучення на менші частини і скептично ставитись до нових залежностей. Так, це більше роботи, але це заощадить набагато більше часу та енергії в довгостроковій перспективі.

Хороші розробники піклуються про майбутнє свого проекту, тому що вони витратили на його створення найбільш обмежений і цінний ресурс - свій час!

До речі, безліч залежностей та модних модних слів також може бути ознакою того, що розробник створює резюме і вже готується до своєї наступної роботи.

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

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

Деякі навіть кажуть, що "код - це поезія".

Вихідний код для jQuery або lodash - чудові приклади, але майже всі популярні бібліотеки на Github, що багато учасників з часом сходяться на красі. Це, мої друзі, дивовижна кодова каліграфія .

По суті, чудовий код:

  1. Легко читати, слідкувати та налагоджувати
  2. Гнучка, конфігурується та розширюється
  3. Розумний з використанням ресурсів
  4. Висока продуктивність

Зверніть увагу, що деякі проекти вимагають іншого порядку. Наприклад, вихідний код Linux може бути не дуже легким для читання, оскільки продуктивність важливіша для операційної системи. Або скромний вбудований додаток IoT може пожертвувати конфігурацією на користь оптимізації ресурсів.

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

Сподобалось прочитане? Слідуйте за мною, щоб отримувати повідомлення, коли я пишу щось нове.

Крім того, ви можете перевірити, чому програмування - найкраща робота за всю історію.