Show your code Saturday: код-рев’ю #3
Коментар редакції. Нещодавно ми оголосили про початок Show your code Saturday — це інтерактивна рубрика, у якій кожен охочий може поділитися власним проєктом, написавши про нього в коментарях. А ми натомість щосуботи обираємо найцікавіший і розповідатимемо детальніше.
Сьогодні ми хочемо поділитися з вами роботою Віталія Воскобовича. Ось що Віталій каже про свій проєкт:
Я допомагаю волонтерам та волонтерським організаціям моніторити командні збори на потреби ЗСУ. Для цього була створена вебплатформа «Збір». Нею користуються вже з десяток організацій. Платформа дає можливість створити збір, вказати список монобанок учасників і побачити детальну статистику. До кожного збору є лендінг, який дозволяє ділитися статистикою і просувати збір.
Наш активний учасник спільноти Максим Рудний зробив код-рев’ю проєкту! Тож далі передаємо слово Максиму 👇
Дисклеймер: я не є автором коду і не знаю причин реалізації будь-якої частини коду таким чином, як це є. Стиль написання коду без ознайомлення з Code Style та Code Convention проєкту не можу критикувати, може це так було задумано.
Перш за все, дякую автору за чудову платформу, що допомагає збирати кошти для наших захисників. Пропоную кожному протестувати її та закинути кілька гривень.
Сьогодні на розгляді волонтерська вебплатформа «Збір». Точніше, лише частина проєкту. Автор не зміг поділитись усім проєктом, тому важко оцінити структуру, перевикористання компонентів та які інструменти для автоматичного контролю якості використовуються.
Окреме питання — чому волонтерський проєкт, де збираються гроші українців, не можна зробити open-source? Що там такого, що код недоступний в GitHub? Можливо, не хочуть показувати, що там нема юніт тестів? 😊
Робота з зображеннями
В мене виникло питання до організації роботи із зображеннями. Частина зберігається як звичайні SVG зображення, інша частина конвертована в JSX компоненти. Браузер може кешувати окремі файли картинок — це перевага в продуктивності завантаження. JSX ж кладеться в bundle, збільшуючи його розмір.
Навіщо у SVG картинки хардкодити або прокидати клас? Наш код тепер завʼязується на клас в картинці. Якщо якийсь розробник просто вирішить змінити картинку, що трапляється часто в роботі, стилі перестануть застосовуватись.
Також нема консистентності у використанні зображень. Одні лежать поруч з компонентами, інші в окремих папочках, які також по різному називаються.
Занадто складна логіка
Компонент до якого в мене виникло найбільше питань — ButtonLink. Просте посилання що може приймати кілька варіантів стилів та розмірів. Доволі типова задача у веброзробці.
Щоб вибрати потрібні класи, залежно від параметрів, автор використовує 2 if
та один switch
. Зрозуміти, як це працює, дуже важко, а підтримувати його ще важче.
Детальніше показую у відео. Там же запропонував простіше рішення, зберігаючи інтерфейс компонента. Хоча, по правильному, його треба було б більше переписати.
Цей компонент чудовий приклад поганої реалізації простої задачі. Забагато умов і складна підтримка.
Корисні інструменти
Для пришвидшення перевірки коду, цей проєкт я додатково перевірив за допомогою Google Lighthout та SonarQube. Якщо раніше не використовували дані інструменти — пропоную додати їх у свій арсенал. Кожен кваліфікований розробник повинен ними володіти, ну або хоча б чути про них. Більше про ці інструменти можна дізнатися в моїй телеграм-групі.
Немає коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів