Річард Фейнман залишив на своїй дошці слова «Те, що я не можу створити, я не розумію». Для мене це корисний тест на розуміння: чи можу я почати з того, що знаю, і самостійно відновити результат?

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

Однак є проблема — де ви знайдете такі знання? У швидкоплинному світі, в якому ми зараз живемо, автори технологій майже не мають часу на написання документів, що містять уявлення про основи. Так яка ж відповідь? Що ж, я виступаю за зворотне проектування.

Я відомий реверс-проектуванням Angular. Але Angular — не єдиний фреймворк, який я детально розглянув. Я дослідив Vue.js, Webpack, jQuery та багато інших веб-бібліотек і фреймворків. Зараз я проходжу через React. І я вважаю, що отримав достатньо інформації, щоб поділитися з вами та допомогти вам розпочати зворотне проектування.

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

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

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

ЧОМУ

Погодьтеся правді в очі, реверс-інжиніринг — важка робота. Це займає багато часу та зазвичай потребує значної бази знань. То навіщо турбуватися?

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

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

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

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

І якщо ви вирішите поділитися своїми висновками зі спільнотою, це допоможе створити ваш публічний профіль. Це безпрограшна ситуація, оскільки, допомагаючи іншим, ви допомагаєте собі. Моя історія успіху почалася з Angular-In-Depth (AiD), коли я вирішив почати писати про свої відкриття. З того часу AiD перетворився на найбільше видання Angular і значно допоміг мені почати виступати на конференціях і знайти ідеальну роботу в ag-Grid. Витрачаючи час і поглиблено вивчаючи технологію, ви також демонструєте свої навички вирішення проблем, рішучість і допитливість. Це ті якості, які інноваційні компанії шукають у кандидатах.

Ви також навчитеся читати існуючий код і досліджувати нові бази коду. Роберт С. Мартін, більш відомий як дядько Боб, вважає, що співвідношення часу, витраченого на читання та написання, значно перевищує 10 до 1. Ми постійно читаємо старий код, щоб написати новий код. Це те, з чого починають усі розробники, коли починають працювати над існуючим проектом. І через практику зворотного проектування ви матимете тут перевагу.

Як бачите, зворотне проектування зробить вас кращим інженером.

Необхідні знання для допомоги у зворотному проектуванні

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

Тверде знання базової платформи

Першою вимогою до успішного зворотного проектування є знання базових API платформи. Якщо ми говоримо про фреймворки та бібліотеки, які працюють в Інтернеті, ось те, що вам потрібно добре зрозуміти: JavaScript, DOM API та API браузера.

Тверде розуміння JavaScript не означає, що ви знаєте, що таке закриття або як вирішується this. Тверде розуміння означає, що ви повинні знати більшість складних речей, таких як дескриптори властивостей (використовуються Vue.js), проксі-об’єкти або бітові маски (використовуються Angular).

Говорячи про DOM і API браузера, недостатньо знати, як створити та додати вузол DOM або асинхронно виконати зворотний виклик. Вам потрібно знати, що станеться, якщо ви повторно додасте існуючий дочірній вузол або як браузери працюють з невідомими елементами. Дізнайтеся про існуючі API для створення HTTP-запиту та його тонкощі, наприклад, коли виконується зворотний виклик XHR fail.

Щоб освоїти JavaScript, рекомендую книги Акселя Раушмаєра. Щоб освоїти DOM і API браузерів, я рекомендую веб-документи MDN і веб-оновлення розробників Google. І, якщо ви можете навчитися читати специфікації, це, звичайно, ідеальне джерело: EcmaScript для JavaScript і WHATWG для середовища браузера.

Інструменти налагодження

Дуже важливо знати інструменти розробника вашого улюбленого браузера зсередини. Мій улюблений браузер Chrome. Отже, перебуваючи в Chrome, ви повинні знати:

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

Найкращий ресурс із інструментів Chrome Dev – це, звичайно, інструменти Google для веб-розробників.

Загальні шаблони проектування та загальні архітектурні концепції

Іноді технології використовують загальні шаблони проектування. Тому знати їх корисно. Наприклад, Webpack покладається на шаблони виконання асинхронного JS, реалізованого асинхронною бібліотекою. До модулів ES бібліотеки використовували такі формати, як CommonJS, AMD і UMD; Обгортки UMD спрямовані на підтримку кількох середовищ завантаження. Коли ви досліджуєте все більше і більше фреймворків і бібліотек, ви почнете розпізнавати загальні шаблони, і це допоможе вам швидше рухатися по коду.

Концепції, що стосуються конкретної технології

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

Вказівки щодо вивчення джерел

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

Визначте частину технології, на якій слід зосередитися

Найпоширеніше запитання, яке мені задають, це з чого почати, де розмістити оператор відладчика в базі коду. Що ж, ви можете зрозуміти це зі своєї мети. Перш ніж почати реверс-проектування, ви завжди повинні мати уявлення про те, яку частину технології ви хочете зрозуміти. Наприклад, під час зворотного проектування Angular або React я спочатку хотів зрозуміти виявлення змін. Це була частина структури, на якій мені потрібно було зосередитися. Завдяки моїм знанням сучасного процесу виявлення змін я знав, що виявлення змін — це синхронізація змін від примірника компонента до вузлів DOM. Тому мені потрібно було знайти, де ці фреймворки зберігають посилання на створені вузли DOM. Це була мета.

Думайте як вчений

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

1. Зробіть спостереження та сформулюйте гіпотезу.
2. Зробіть прогноз на основі гіпотези.
3. Перевірте передбачення.

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

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

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

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

Реверс-проектування полягає не лише в читанні джерел. Насправді я витрачаю лише близько 20% свого часу на перевірку конкретної деталі реалізації у вихідному коді. Я витрачаю близько 70% часу на налагодження зразка програми. Ось чому я вважаю, що хороше володіння інструментами налагодження є необхідним, щоб зробити процес зворотного проектування ефективним. Решту 10% часу я витрачаю на читання коментарів у вихідному коді або пояснення понять, виявлених у коді. Зазвичай коментарі набагато корисніші, ніж будь-що, що ви можете знайти в Інтернеті, тому ніколи не нехтуйте ними як неважливими.

Використовуйте стек викликів для створення потоку програми

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

Не впадайте у відчай, якщо висунути свою гіпотезу неправильно

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

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

Дайте собі час подумати про те, що ви знайшли

У книзі «Розум для чисел» Барбара Оуклі розповідає про два стани розуму, що змінюються — зосереджений режим і розсіяний режим. Обидва підходи необхідні для вивчення чогось нового. Сфокусований режим передбачає прямий підхід до вирішення проблем за допомогою раціонального, послідовного та аналітичного підходів. Дифузний режим дозволяє нам раптово отримати нове уявлення про проблему, з якою ми боремося, і пов’язане з перспективами «великої картини». Дифузний режим – це те, що відбувається, коли ви розслабляєте свою увагу і просто дозволяєте своєму розуму блукати. Тож не сидіть годинами перед комп’ютером, а регулярно робіть короткі перерви та обмірковуйте те, що ви відкрили. Я просто ходжу по квартирі. І я роблю це, коли виконую будь-яку творчу роботу, наприклад пишу, а не просто реверс-проектування.

Почніть із отримання джерел і налаштування прикладної програми

Для зворотного проектування фреймворку або бібліотеки вам знадобляться їхні джерела та зразок програми з цією технологією. Зараз більшість фреймворків і бібліотек розміщені на Github, тож просто клонуйте репозиторій. Ви завжди хочете вивчити певну версію, тому перейдіть на вкладку «релізи» у сховищі та перевірте останній випуск. Тепер, коли ви отримаєте клонований репозиторій, перевірте цей випуск, запустивши git checkout tags/[version].

Другим кроком є створення зразка програми. Завжди намагайтеся створювати найпростіші налаштування. Уникайте збирачів коду, таких як інструменти webpack і CLI, які надаються сучасними фреймворками. З мого досвіду вони значно ускладнюють процес налагодження. Ідеальним варіантом налаштування є звичайна HTML-сторінка з кодом, завантаженим із CDN, наприклад, unpkg.com. Просто переконайтеся, що версія фреймворку або бібліотеки відповідає версії, перевіреній у джерелах.

Слово про удачу

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