Як розуміти чужий код

Перш ніж перейти до купи тексту , подивіться на код і зрозумійте, що він робить :

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

Коли ми змушені читати чужий код?

1 . Код дістається у спадок.Коли ви дописуєте за кимось, і вам потрібно оцінити, скільки часу займе доробка .
2 . Ваш код , дописанийкимось, в який вносили зміни інші розробники, і вам необхідно зрозуміти, що вони там дописали .
3 . Code review .Відрізняється від перших двох тим, що його потрібно проводити до того, як код потрапляє в репозитарій/продакшн .

Що потрібно для розуміння чужого коду ?

- Знання предметної області , щоб читати код , розуміти , як це було реалізовано за вимогами, і продумати стратегію як його змінювати в майбутньому.
- Особливості мови . Наприклад, в JavaScript є свої приведення типів , і деякі перевірки типів/умов будуть не завжди істинними або помилковими , як ви цього хочете. Потрібно розуміти , до чого призводять вирази, які ви прописуєте .
- Можливості підключених бібліотек. Якщо ви розробляєте , грунтуючись на якомусь фреймворку , потрібно знати його можливості. Дивлячись на код , ви повинні чітко розуміти , де яка функція використовується .

Проблеми

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

Як знайти потрібне місце в коді ?

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

Знайшли потрібне місце , але як зрозуміти логіку ?

Є у нас ось такий код: Маємо ініціалізацію масиву, який називається « їжа» , потім створюємо об'єкт « кішка » , а потім чомусь прирівнюємо кішку до їжі і заносимо її в масив їжі. Ця логіка зрозуміла тільки якщо наш сайт продає шаурму . Навіть якщо ваше завдання - створити ще одного кота , ви його додасте , але він знову буде занесений в масив їжі. І чому так - залишиться загадкою. Хороша практика - перечитати вимоги , бути в курсі предметної області і зрозуміти, чому було реалізовано саме так. Приклад складний з початку статті : Ніяких коментарів, змінні називаються незрозуміло як , чомусь 4 вкладених циклу, код складний , і ми не можемо сказати, що конкретно він робить. Це шматок коду з алгоритму md5 . І я сам не знаю, що він робить. Єдиний спосіб його зрозуміти - знати сам алгоритм md5 , вміти в розумі розраховувати md5 і пройти код покроково , зіставляючи з тим, що виконується в самому алгоритмі . Ніхто не скасовував старий добрий debugger і покрокове виконання , але знання предметної області все одно потрібно .

Причини виникнення складного коду

- Розробники не дотримуються Code Conventions . По-нашому - відсутність правил і домовленостей.
- JsDocs . Це формат коментування джаваскріптових методів . Розробник думає « назову функцію по -зрозумілому - getDocument , мене зрозуміють » і реалізовує складну логіку всередині методу, про яку ми не знаємо. Ми сподіваємося отримати документ , використовуємо цей метод, а він робить ще купу всього , що варто було б описати в коментарях.
- Ключові моменти бізнес- логіки. Як у попередньому прикладі з getDocument , складні операції з масивами , цикли , умови - все повинно бути прокоментовано .
- Code Review , а саме його відсутність . Джуніор теж можуть Рев'ю сеньйорів.

Як ми називаємо поганий код?

- « Спагеті -код ».Чи не найпоширеніший варіант . Три методи , кожен з яких щось робить. У тілі функції йдуть виклики інших методів, і навіть очима неможливо простежити ланцюжок, що звідки викликається . Код переплутано , як спагеті в мисці. - « Милиці ». Такого в коді дуже багато. Розробник написав цикл , в якому він щось робить з елементами масиву, за яким йде цей цикл . І попереджає, що виклик методу doSomething при певному значенні вивалює помилку. І він просто пише, що якщо значення масиву - 4 , треба пропустити його і перейти до наступного. Він передбачив цю ситуацію і зробив « підпірку » , щоб не валилася помилка . Але цим він створив інші ситуації , які створять інші виняткові ситуації, коли щось не здасться або здасться зайве. Розробник ж продовжить дописувати інші милиці , перекриваючи створені помилки. - « Велосипед » Це - бульбашкова сортування масивів. Коли розробник пише такий код , він не замислюється, що на JavaScript є власна сортування масивів, яка викликається елементарно .sort ( ) . Він заново придумав код , який вже десь є . Таке часто буває в роботі в команді, коли один розробник вже написав метод, а ви не знаєте про це і пишете ще один такий метод . І код розростається однаковими методами.

Як далі жити ?

Способи проведення Code Review виробляються у кожного індивідуально з досвідом. Потрібно читати і аналізувати чужий код для вироблення власних способів Code Review , з часом по коду починаєш дізнаватися автора. Code Conventions і коментарі економлять нерви і час . GodLevel читання чужого коду - github.com/torvalds/linux Читати Джуніор перед сном :
- Стандарт оформлення коду
- Коментарі
- Рефакторинг

Опубліковано: 23/02/15 @ 06:51
Розділ Різне

SEO Блог