Кожен проект розробки SPA є унікальним по-своєму. Застосунок може мати унікальний дизайн, складну бізнес-логіку, дуже специфічну цільову аудиторію. Проте, незважаючи на цю унікальність, значна частина процесу розробки може бути узагальнена, і її загальні принципи можуть бути визначені для більш ефективної роботи. Далі ми поговоримо про принципи розробки односторінкових застосунків, які роблять їх більш просунутими і водночас швидшими.
Кожен проект починається з обговорення завдання з клієнтом та розуміння того, що потрібно зробити. Якщо клієнт не знає, яка мета застосунку, хто його цільова аудиторія і для чого потрібне рішення, працювати буде важко. Більше того, проект, найімовірніше, затримається, оскільки ідеї з'являтимуться хаотично, що заважатиме команді точно оцінити проект і спланувати його.
Саме тому перший і один з найважливіших пунктів у нашому списку — чітке і точне уявлення про продукт і його цільову аудиторію, тобто майбутніх користувачів застосунку.
Наступний етап — вибір способу реалізації проекту. Для розробки ІТ-продуктів найкраще підходить методологія Agile та її принципи, зокрема фреймворк Scrum.
Scrum
Фреймворк Scrum полегшує планування завдань і координацію команди, крім того, позитивно впливає на швидкість проекту. Основні принципи цієї методології:
- Малі команди. Команда повинна складатися з 3 до 9 осіб, кожен з яких є професіоналом у певній сфері, здатним вирішувати поставлені завдання. Суть у тому, що така команда не потребує зовнішньої допомоги і може автономно впоратися з усіма завданнями.
- Щоденні наради. Команда проводить щоденну зустріч, щоб визначити проблемні питання, проінформувати інших учасників про хід проекту та допомогти один одному впоратися з труднощами.
- Спринт. Це 1-2-тижневий інкремент діяльності з розробки програмного забезпечення, в рамках якого виконується певний обсяг роботи. Завдання плануються командою до початку спринту, і не рекомендується додавати або видаляти діяльність під час спринту. Такий підхід допомагає зосередитися на завданнях і не відволікатися.
- Ретроспектива. Після завершення кожного спринту команда робить висновки щодо процесів розробки та їх можливої оптимізації в подальшій роботі.
Більше інформації про Scrum ви можете прочитати тут.
Співпраця з менеджером проекту
Використання Scrum передбачає попереднє планування завдань, їх складності та оцінки часу разом з менеджером проекту. Менеджер зазвичай спілкується з клієнтом і має загальне уявлення про проект. Саме тому важливо дотримуватись своєї ролі в проекті і адресувати питання, що виникають, менеджеру, щоб він міг включити їх у список завдань.
Пряме спілкування між розробником і клієнтом може затримувати проект, оскільки часто призводить до непередбачених коригувань, які не завжди покращують функціональність застосунку, але забирають багато часу.
Співпраця з дизайнером
Краще дотримуватись наступних принципів у взаємодії розробника та дизайнера.
- Проект слід детально обговорити з командою перед початком етапу дизайну.
- Необхідно прийняти рішення щодо UI-бібліотеки (і якої саме, якщо така є).
- Слід визначити CSS-решітку з урахуванням крос-платформності та крос-браузерної сумісності.
- Результати створення макету застосунку слід регулярно демонструвати дизайнеру, щоб переконатися, що вони відповідають принципам дизайну для розробки програмного забезпечення, а також виявити критичні моменти і способи їх вирішення.
Вищезазначені кроки дозволять розпочати фронтенд-розробку проекту навіть коли дизайн ще не завершено або не затверджено клієнтом. Однак важливо усвідомлювати, що етап дизайну має бути завершено перед початком фронтенд-розробки.
Співпраця з бекенд-розробником
Ідеально, щоб бекенд-розробка була на кілька спринтів попереду фронтенду.
Так само, як і в попередніх пунктах, контракти (або ендпоінти) слід обговорити з бекенд-командою заздалегідь, перед початком проекту. У такому випадку на початковому етапі проекту використовуються Mocks. Це фейкові дані, які замінюються реальними після реалізації бекенду.
Також варто зазначити, що перевагою SPA є те, що взаємодія з бекендом стала надзвичайно простою завдяки REST. Після завершення переговорів щодо контрактів, розробка займає небагато часу.
Фреймворки та бібліотеки
Основні завдання сучасних javascript-фреймворків можна сформулювати наступним чином: спростити роботу з даними, використовувати готові рішення (компоненти застосунків) і не копіювати логіку, яка присутня практично в кожному проекті, наприклад, валідацію форм, з одного проекту в інший.
Для вирішення цих проблем використовуються не лише javascript-фреймворки, але й додаткові бібліотеки, наприклад, Element UI або Bootstrap.
Стилі
Для швидкої та ефективної розробки CSS необхідно:
- Обговорити UI-елементи та медіа-брейкпоінти з дизайнером,
- Використовувати готові рішення з бібліотек.
Наступні кроки також можуть пришвидшити розробку:
- Перевизначити стилі за замовчуванням бібліотеки на свої, це дозволить зручно використовувати компоненти бібліотеки.
- Створити свій власний файл з змінними для UI-елементів.
- Використовувати препроцесори.
- Дотримуватись принципів BEM-найменування.
Правильно організований робочий процес — це заощаджені кошти клієнта. Ось чому вищезазначені пункти опосередковано впливають на вартість продукту. Чим менше проблем у розробників, тим менше часу витрачається на виконання проекту, а отже, менше робочих годин потрібно для створення односторінкового застосунку.
YAGNI
YAGNI ("Вам не знадобиться це") — процес і принцип розробки IT-рішення, в якому відмова від непотрібної функціональності проголошується основною метою та цінністю. Це означає, що не слід додавати функції, які не мають термінової необхідності.
Цей принцип можна використовувати як на початковому етапі обговорення проєкту з клієнтом, так і під час етапу розробки коду.
Якщо, наприклад, це інтернет-магазин, що складається з одного продукту, клієнту навряд чи знадобляться функції каталогу та кошика.
При застосуванні цього принципу до розробки коду важливо зберігати розумний баланс між мінімально працездатним продуктом і ідеальним кодуванням.
Тестування
Юніт-тестування — це процес програмування, який дозволяє тестувати окремі модулі вихідного коду на узгодженість. Основна ідея такого тестування полягає в тому, щоб переконатися, що зміна коду не призвела до проблем в роботі додатку.
Однак іноді краще не включати тестування. Якщо бюджет проєкту обмежений, а функціональність велика, це економить кошти клієнта. Проте від тестування повністю відмовлятися не слід. Тоді можна використовувати лінтер, typescript, код-рев'ю та QA як альтернативу тестуванню.
Очевидно, що це стосується відносно малих проєктів, які тривають до 6 місяців. Великі проєкти не можуть бути реалізовані без тестування.
Vue.js
Важливо вибрати правильний фреймворк. Швидкість і зручність розробки на Vue зазвичай вищі, ніж на інших фреймворках. Це відбувається через те, що Vue об'єднав найкращі функції React і Angular.
Другим важливим аспектом є те, що крива навчання на Vue нижча, що означає, що верстальник або молодший розробник можуть швидко навчитися використовувати Vue. Це зазвичай позитивно впливає на вартість проєкту.
У прагненні до швидкості та економії надзвичайно важливо не жертвувати якістю. На щастя, цього легко досягти, якщо не забувати про ключові етапи розробки.
Можна подумати, що наступні пункти роблять процес розробки довшим, але насправді вони допомагають запобігти поганій якості коду або критичним помилкам у додатку. Це дійсно економить час, гроші та нерви в подальшому.
Забезпечення якості
Розробка — це не легке завдання, особливо коли йдеться про забезпечення якості власної роботи. Іноді додаток може здаватися ідеальним для розробника, але свіжий погляд все ж необхідний.
Забезпечення якості (QA) відповідає за весь процес розробки, тому його слід інтегрувати на кожному етапі процесу розробки: від опису проєкту до його запуску і навіть подальшого супроводу. Спеціалісти QA створюють і впроваджують різноманітні методології для підвищення якості на кожному етапі виробництва додатку, знаходять помилки та проблеми логіки додатку і допомагають знаходити способи їх виправлення.
Не слід забувати про підхід бета-тестування — це метод тестування, коли сам розробник перевіряє бізнес-логіку додатку та його стиль.
Код-рев'ю
Перевірка правильності та точності коду також є частиною QA, але використовується для належного процесу розробки коду. Цю процедуру проводить кожна компанія, яка піклується про якість. На цьому етапі важливо впевнитися, що код зрозумілий іншим розробникам і що в майбутньому можна буде додати нові функції або змінити існуючі. Цей етап дозволяє використовувати «громадську» інтелектуальність, яка значно потужніша за «індивідуальну».
Резюме
Підсумовуючи, визнаємо, що вищезгадані принципи були обрані як основа для якісної розробки в нашій компанії.
Однак також слід пам'ятати, що комунікація є важливим принципом роботи. Саме завдяки їй можна визначити необхідний набір практик і методологій, щоб відповідати вимогам конкретного проекту та конкретного замовника.
