10 порад щодо JavaScript проектів, які ви зрештою засвоїте

JavaScript — пригода і, я вважаю, кожен погодиться з цим твердженням.

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

Пройшовши крізь проекти на jQuery, require.js, Angulars, React, ExtJs, та, можливо, десяток інших, яких я міг не згадати (або не хотів згадувати), я бачив речі, неймовірні для фронтенду у 2018.

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

Сподіваюсь, ви знайдете щось нове та корисне для себе, що знадобиться для створення дивовижних проектів! 💪

1. Розділяй та володарюй

Більшість з нас вже чула це десь. Однак правило часто недооцінюється. CommonJS, Webpack, та Node надають можливість розділяти код на декілька файлів. Чому це повинно нас хвилювати?

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

Менеджмент. Поділ кожного експорту в окремий файл дозволяє вам швидко переміщувати його за необхідністю і сприяє розв'язці. (decoupling — практика, коли кожна частина вашого коду повністю незалежна, а будь-які залежності передаються через аргументи чи ін'єкції. У разі застосування значно спрощує тестування та покращує доступність коду). Коли ваша допоміжна функція необхідна в іншій частині застосунку, ви можете просто створити директорію /shared та перемістити функцію туди, відкриваючи доступ з інших частин коду.

2. Робіть усе очевидним

Давайте імена змінним, функціям, файлам так само відповідально, наче ви називаєте дитину. Ви можете зекономити 0.3 секунди сьогодні, назвавши змінну «x», але через місяць ви витратите 2 дні, намагаючись відгадати що це означає, а потім 4 дні на рефакторинг. Думайте наперед та не уникайте довгих назв.

Уникайте лайфхаків та речей, що змусять вас звернутися до MIT одразу ж. Ваше рішення може бути розумним і складним, але одного разу ви або хтось з вашої команди витрачатиме велику кількість часу, намагаючись зрозуміти що відбувається у коді. Зосередьтеся на простоті речей: без необхідності коментарів чи документації. (Ви завжди можете спростити проблеми, використовуючи пакети з відкритим сирцевим кодом з npm. Витратьте хвилинку для пошуку — можливо, вже існує пакет для розв'язання проблеми.)

3. Розберіться з магічними числами та рядками

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

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

4. Боротьба зі вкладеннями

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

Складність умовних виразів можна усунути, розділивши код у глибоко вкладених if-операторах на окремі функції, проміси або об'єкти Observable. Якщо ви використовуєте багато асинхронних викликів, async/await також може значно спростити ваш код.

5. Створюйте файли конфігурацій

Якщо ваш застосунок використовує глобальні значення, API endpoints, ротацію функцій або облікові дані — розміщуйте їх в окремому config-файлі. (Не забувайте, що не варто комітити ваші облікові дані. Якщо ви використовуєте Jenkins, CircleCI або подібні, встановіть облікові дані як змінні середовища. Якщо ви розгортаєте застосунок лише локально, зберігайте облікові дані у безпечному місці)

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

6. Фреймворки можуть допомогти

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

Не поспішайте та осмисліть чи потребуєте ви фреймворк для вашого проекту та який саме використати. Кінцевому користувачеві все одно чи буде ваш сайт або застосунок створено за допомогою фреймворку з 100 000 зірками на Github чи ні. Покладаючись на досвід, я б розділив фреймворки та бібліотеки таким чином:

• React: якщо вам необхідний повний контроль над архітектурою, але лише для веб-застосунків з компонентами. Екосистема React потребує багато часу та планування наперед. React усе компенсує, але лише якщо ви знаєте що робите.

• Angular / VueJS / Ember: коли вам необхідний веб-застосунок швидко і надійно, в обмін на великий чорний ящик замість архітектури. Ці фреймворки багато роблять для вас, позбавляючи як плюсів, так і мінусів планування архітектури. Їх сувора структура також пробачить більше помилок, ніж свобода, характерна для React.

• jQuery / lodash / або подібні. (Існує багато сліпої ненависті навколо jQuery, lodash та подібних бібліотек, тому що більшість з їхніх функцій можуть бути створені, використовуючи стандартні засоби ECMAScript. Але якщо ви добре знайомі з архітектурою jQuery, та хочете лише створити веб-сторінку, то, на мій погляд, слід продовжити використовувати бібліотеку. Я з'ясував, що набагато швидше та чистіше використовувати ці бібліотеки для простих проектів та прототипів.) : якщо вам необхідна веб-сторінка швидко, і ви можете витратити декілька зайвих kB. Вони можуть значно скоротити час розробки, але вимагають обережності, тому що дозволяють написання непідтримуваного коду. Використовуйте їх як помічників, а не як фундамент.

• Vanilla / Без фреймворку: для веб-сторінок та веб-застосунків, коли ви можете витратити багато часу на розробку і планування. Чистий JavaScript є хорошим вибором, якщо ваш проект робить щось експериментальне — вводить WebGL, Workers, поглиблену оптимізацію чи анімацію у браузері. Ви, в кінцевому підсумку, створите власний вид фреймворку. З транспіляторами він також може використовуватись як легша та краща альтернатива для jQuery.

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

7. Якщо це не прототип — пишіть тести

Юніт тести. Smoke-тести. End-to-end тести. Санітарне тестування. Якщо ваш проект не є прототипом, який скоро буде переписаний, пишіть тести. Зі збільшенням складності, вашу кодову базу буде складніше підтримувати й контролювати — тести зроблять це для вас.

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

8. Використовуйте контроль версій

Незалежно від того, чи працюєте ви над прототипом, великомасштабним корпоративним веб-застосунком чи невеликим стороннім проектом — використовуйте git чи інший контроль версій з моменту написання першого рядка коду. Робіть коміти кожного дня, використовуйте гілки, навчіться робити мержі, розв'язувати конфлікти та повертати попередні коміти. Давайте зрозумілі коментарі до комітів.

Контроль версій дозволяє вам подорожувати часом, зберігати зламані речі та бачити зміни, впроваджені у минулому. Якщо ви засвоїте щось з цієї статті, то нехай це буде вивчення основ контролю версій та його щоденне використання. Чому? Тому що навіть якщо ви проігноруєте інше та випадково зіб'єтеся зі шляху, з контролем версій ви зможете виправити це. Без — ви, зазвичай, приречені почати спочатку.

9. Керуйте станом відповідально

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

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

Зберігання даних, тобто управління станом — це складно. Наші застосунки, зазвичай, повинні залишатися синхронізованими як з тим, що бачить клієнт на екрані, так і з тим, що зберігається на сервері у БД. Нашою метою є уникнення ускладнення у середині — нашій JavaScript структурі. Компоненти повинні доставляти такий самий набір даних, синхронізувати зміни, зроблені користувачем та реагувати на будь-які зміни на сервері. Як можна розв'язати ці проблеми?

• З того часу, як React має дуже відкриту екосистему, існує безліч рішень — Redux для Flux архітектури, Mobx - для заснованої на observable. Кожна з них має свої переваги та недоліки. Переконайтеся, що ви засвоїли основи бібліотеки перед її використанням.

• Angular, Ember, та VueJS обслуговують власні рішення для управління станом, засновані на ідеї використання об'єктів Observable. Якщо нема потреби, існують додаткові бібліотеки, на зразок ngRx, Akita та Vuex. (Зауважте, що ви можете також використовувати з цією метою Redux, тому що він незалежний. Хоча у довгостроковій перспективі він може створити додаткові складнощі через сувору архітектуру та моделі Observable)

• Для будь-якого іншого фреймворку або Vanilla JavaScript, ви можете використовувати Redux, Mobx або власне рішення для управління станом. Головна мета — упевнитись, що увесь застосунок має одне й те ж джерело істинності: сервер, бібліотеку чи простий стан Observable.

10. Щодо трендів

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

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