Нефункціональні вимоги, про які всі забувають і провалюють проєкт

Це пункти, які потрібно не просто обговорити з розробниками на словах. Це - частина Вашого договору з ними! Важливо підібрати й розписати їх саме під Ваш проєкт. Наприклад, якщо проєкт є стартапом або MVP для тестів і має бюджет близько 20-30 тисяч доларів на розробку - то вимоги, позначені "$$$", будуть для Вас недоречними, але є методи їх часткового дотримання. Компроміси. Наприкінці статті я також поділюся коротким списком вимог, який підійде для створення прототипу - спрощеної версії застосунку, непридатної для використання в реальних умовах, але достатньої для аналізу й подальшої розробки. Там усе практично навпаки, потрібно порушувати деякі вимоги й використовувати спеціальні принципи.

Без зайвих слів ділюся з Вами деякими найважливішими нефункціональними вимогами.

Нефункціональні вимоги

(вимоги до системної якості)

$$$ Відповідність мові предметної області

Система іменування в програмному коді має збігатися з термінологією мови предметної області. (на версії MVP ця мова міститиметься у схемі даних).

Це неочевидна вимога. Програмісти часто пишуть програму, розуміючи, що від них вимагається, у процесі роботи, і так само в процесі роботи називають звичні бізнесу речі СВОЇМИ іменами. А потім додатковим завданням клієнта буде вивчити ці фантазії на вільні теми. Не кажучи вже про те, що будь-які нові програмісти на проєкті не стануть принципово вникати в усю цю справу й знайдуть аргументи, щоб переписати весь проєкт заново. Як перевірити цю єдину мову, або так зване "ядро предметної області" - тема, гідна окремої статті. Зараз лише залишу посилання на предметно-орієнтоване проєктування і скажу, що це робота архітектора програмного забезпечення (у зв’язці з бізнес-аналітиком у великих компаніях).

Читабельність

Якщо коротко - це вимога, за якою розробники зобов’язуються писати код, який може прочитати хтось, крім них. Так, ось так просто, але надважливо. Для дотримання цього пункту буде достатньо дотримання рекомендацій зі стилю кодування щодо оформлення коду та рекомендацій обраного фреймворку щодо організації файлової системи. Для будь-якої мови програмування вже існує такий набір правил, наприклад у php є PSR. Читабельність коду, звісно, не вплине на те, як працюватиме ПЗ. Але програма - це не статична штука, вона постійно змінюється й підтримується. Тож можна стверджувати, що від такої простої вимоги залежатиме, скільки буде багів у Вашій системі й скільки коштуватиме їх виправлення. Особливо нечитабельний код ніхто не захоче правити й навіть дивитися. З мого досвіду у більшості проєктів саме такий код, і його власники переплачують за до смішного прості правки - часто дорожче, ніж їм обійшлася початкова розробка. Це не дуже дорога вимога, але часто вона залежить від совісті програміста і тому часто порушується. Вона має стати частиною договору!

Документація до API серверного застосунку

Система має містити документацію серверних моделей даних, а також документацію всіх URL-ресурсів сервера з можливістю виконати тестовий запит, побачити його параметри, а також побачити реальну відповідь серверного API.

Цей пункт критично важливий для приймального тестування. Якщо у Вас сучасний проєкт з окремим фронтендом - без дотримання цього пункту бекенд-розробники матимуть можливість здати Вам пустушку або дуже заплутане API, яке Ви не зможете застосувати, що ще гірше, адже перед тим як це з’ясувати, на це витратять час інші наймані співробітники!

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

Документація до ключових алгоритмів системи

Усі ключові вузли й алгоритми системи, а також блоки коду, що не відповідають самодокументованому коду, повинні мати наочний і помітний коментар (у коді) або файл з назвою README.md у папці модуля\застосунку. Тут ключове слово - "ключові". Документація кожного рядка коду призведе до сильного підвищення вартості продукту. Тому особливо для стартапів або невеликих компаній важливо, щоб архітектор визначив найважливіші алгоритми в системі, до яких має постачатися документація. Її мають розуміти не лише програмісти, а й нетехнічні фахівці.

$$$ Розподіленість

Система має бути розбита на підсистеми з низьким ступенем зв’язаності. Кожна підсистема є окремим вебзастосунком або сервісом, пов’язаним з усіма іншими сервісами системою метаданих або подієвою шиною.

Вебінтерфейс, серверне API, адміністративна зона, CDN-сервер, сервіс повнотекстового пошуку - окремі сервіси.

У майбутньому підсистеми можуть бути розподілені в окремі репозиторії.

Система розгортання

Система має швидко (у кілька кроків) встановлюватися на Ubuntu-системах, на яких попередньо встановлено Docker, docker-compose, git і пакетний менеджер.

Система має містити налаштування доступів до баз даних, підсистем і зовнішніх сервісів (типу гугл-авторизації, сервісу відеозв’язку або поштового клієнта), налаштування безпеки (наприклад, CSRF-токен, сіль, паролі..).

Система розгортання зберігається в репозиторії в СКВ.

Система розгортання містить конфігурації бази даних, вебсерверів та інтерпретаторів.

Система розгортання має створювати конфігурації для інших систем за шаблоном.

$$$ Модульність

Система має підтримувати задану модульність, що відповідає принципам LOW COUPLING і HIGH COHESION. Це принципи з не дуже популярного (порівняно з SOLID) набору рекомендацій GRASP, тема для окремої статті.

Принципи задання модулів залежать від бізнес-вимог до модулів або за принципом “по модулю на агрегат”.

УВАГА: мається на увазі дотримання цих принципів на рівні ГРУП класів (міні-застосунків, програмних модулів). Дотримання цього принципу на рівні класів потребуватиме більше часу на реалізацію, тому не очікується на етапі MVP.

Багаторівнева архітектура

Кожен модуль складається з кількох шарів (рівнів).

Шар не може звертатися до шару, який знаходиться вище цього шару (наприклад, модель не робить запити в сервіс

Використовуємо архітектуру відкритого шару (шар може звертатися до шару нижчого рівня в обхід інших шарів)

Ось основні шари в багаторівневій архітектурі.

Інтерфейс

$$$ React, Angular або Vue застосунок, що складається переважно з вебкомпонентів.

*АЛЬТЕРНАТИВНИЙ ВАРІАНТ: PJAX застосунок, спрощена модель швидкої взаємодії з користувачем.

Шар Контролер

Цей рівень

1. Відповідальний за отримання вхідного запиту за протоколом

2. Має строго визначену URL-адресу

3. Проводить авторизацію запиту

4. Делегує обробку запиту визначеному сервісу.

Відповідає патерну “Контролер” із GRASP і принципу “Тонкий контролер”.

Шар Сервіс

Шар із класами типу “Pure Fabrication”, що є додатковою оболонкою для взаємодії з моделями предметної області. У цьому шарі розміщується логіка, пов’язана з групуванням деяких операцій з моделями для перевикористання, або будь-яка логіка, що не стосується безпосередньо логіки предметної області, але важлива для оптимального функціонування моделей. На цьому рівні може проводитися кешування.

$$$ Шар Модель предметної області

Клас, що містить бізнес-логіку (логіку домену). Дотримуючись ідеї Rich Domain Model, у цьому шарі мають розміщуватися класи моделей відповідно до іменування об’єктів у предметній області застосунку.

$$$ Шар Репозиторій

Група класів, що містять інфраструктурну логіку - логіку пошуку, фільтрації та групування об’єктів через ORM або через базу даних напряму.

Шар ORM

Клас, що є мапером бази даних та об’єктної моделі. Містить валідацію рівня бази даних, реляційну (зв’язну) логіку. Часто надається фреймворком, може бути на основі патерну ActiveRecord, придатного переважно для прототипування, або складнішого патерну DataMapper.

$$$ Безпека

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

Основні типи вразливостей, які неприпустимі в 99% систем, — SQL-ін’єкції, CSRF-атаки, файлові ін’єкції (наприклад під час завантаження фото), DDOS атаки (переважно вимоги до сервера), перебори пароля, злам через "невидимі" файли (наприклад через папку .svn), підміна токена, MITM-атаки прослуховування, XSS-атаки з перегоном трафіку на інший сервер. Докладніше про кожну можна почитати у Вікіпедії або попросити в коментарях