Як Новомосковскть код 8 принципів, які варто запам’ятати - блог

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

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

1. Вчіться копати

Коли ви вперше знайомитеся з серйозною кодової базою, можливо, ви не будете відчувати себе розробником. Швидше ви будете себе почувати археологом, приватним сищиком, або дослідником релігійних книг. Це цілком нормально, адже у вашому розпорядженні є кілька інструментів для «розкопок». Якщо вам пощастило, і ваші попередники використовували контроль версій, це варто відсвяткувати! У вас є доступ до багатства метаданих, і це дуже сильно полегшить вам розуміння контексту, в якому створювався код. Далі я виходжу з того, що ви використовуєте Git, але у випадку з SVN, все буде приблизно так само.

Використовуйте цю команду, щоб побачити історію коммітов по всьому сховища. Ця команда виводить повідомлення коммітов, і команда grep допоможе вам знайти в коммітов конкретний текст, наприклад назву функції someFunction: git log | grep someFunction -C 3 (останні прапори покажуть вам знайдені вирази з трьома рядками навколишнього контексту.)

2. Поверніться в минуле

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

Якщо проект зберігається на GitHub або подібному сервісі, ви можете отримати купу інформації, Новомосковський тікети, пулл-реквести і код-рев'ю. Звертайте увагу на тікети, в яких було найбільше обговорень. Там можуть бути «больові точки», з якими ви можете зіткнутися в майбутньому, тому добре б заздалегідь мати про них уявлення.

5. Знайдіть Main

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

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

Виконайте git blame на цьому файлі і подивіться, які частини основного файлу було змінено нещодавно. Нещодавно змінений код може підказати вам, над якими проблемами працювала команда останнім часом. Можливо, вони представили нову бібліотеку, або довго намагалися налагодити бібліотеку, яка не дуже добре працювала. А може бути, там просто якийсь бойлерплейт код, який потрібно регулярно оновлювати.

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

6. Звертайте увагу на стиль.

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

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

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

7. Чекайте зустріти сміття

8. Не впадайте у відчай

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