Show your code Saturday: код-рев’ю #15

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Коментар редакції. Show your code Saturday — це інтерактивна рубрика, у якій кожен охочий може поділитися власним проєктом, написавши про нього в коментарях. А ми натомість щосуботи обираємо найцікавіший і розповідатимемо детальніше.

Сьогодні ми хочемо поділитися з вами роботою користувачи sangens.

Наш активний учасник спільноти Максим Рудний зробив код-рев’ю проєкту! Тож далі передаємо слово Максиму 👇

Дисклеймер: я не є автором коду і не знаю причин реалізації будь-якої частини коду таким чином, як це є. Стиль написання коду без ознайомлення з Code Style та Code Convention проєкту не можу критикувати, може це так було задумано.

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

Подивимось на пакет react-query-manager, який є надбудовою над популярним @tanstack/react-query. Код там доволі складний, а часу обмаль, тому не варто розраховувати на глибоке занурення і розуміння всього, що там написано, особливо якщо немає попереднього досвіду використання @tanstack/react-query.

Документація

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

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

Unit-тести

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

Цей проєкт — інша справа. Тисячі розробників будуть ним користуватися. Потрібно бути впевненим, що все працює коректно і код протестований. Найпростішим та досить ефективним способом є юніт-тести. У цьому випадку вони must have.

Автор згадував, що планує їх додати, отже, розуміє важливість.

Висновок

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

Автору дякую за те, що поділився кодом. Бажаю успіхів у розвитку проєкту.

Сподобався огляд? Підписуйтеся на мій YouTube-канал та приєднуйтесь до нашої спільноти в Telegram! Там на вас чекає ще більше корисних матеріалів і цікавих обговорень. Долучайтеся зараз і будьте в курсі найновіших ІТ-трендів!