Як ми проєкт для ЗСУ писали і що з цього вийшло

Хто я?
Розпочнемо з того, хто я. Звати мене Віктор. Працюю я Node.js (MERN) розробником на одного з найбільших автодиллерів Північної Америки. Займаюсь програмуванням з 2018го року та зараз обіймаю посаду старшого розробника. Свою карєру розпочнав як Java розробик, але волею випадку перейшов на JS та опинився у Північній Америці.
Свою роботу я люблю, та ходжу на неї із задоволенням. Останні роки не відчуваю, що на роботі, так як команда та клієнт мене цінують і від цього зажди є стимул приходити в офіс. А я в свою чергу ціную їх.

Як все починалось?
Почалося все з того, що знайомий мого знайомого який несе службу у ЗСУ звернувся до нас з проханням написати для одного з підрозділів сайт, через який можна зробити збори у гарній обкладинці та мати всі збори бригади в одному місці, а не так, як воно було до цього, що кожен збирає у інстаграмі для свого чоловіка/брата/однокласника.

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

Одного дня нас всіх зібрали на дзвінок з «замовником». Чоловік нам все детально пояснив на словах і задача здавалась зрозумілою. Хтось з бригади, або довірені люди (адміни) можуть зробити проект, додати опис, фоточку та лінки на соціалки. Питання оплати відпало само собою, так як у нас є чудовий функціонал банок від Монобанку. До збору просто додавалось посилання на банку і на тому питання оплати закривалось. Людина може зайти на сайт, вибрати збір, який їй подобається, перейти на банку і кинути свої чесно зароблені 10грн.
Звучить максимально просто. Пригода на 20хв, зайшли, вийшли


Команда
Команда складался з 5ти людей, двоє з яких були замовниками додатку, які нарізали нам задачі, та троє безпосередніх розробників.

Я, на стороні бекенду разом з Р, який є джуніор розробником та студентом одного з вузів. Він також пише на Node.js та використовує фрейморк Nest на своєму проекті.
Є молодим, енергійним, амбітним. Напевно, як і ми всі у 19 років, чи не так?
Досвід: 1рік.

На стороні фронтенду був дуже досвідчений Ю, який займає посаду архітекта на одній з команій, яка входить до «великої пятірки» українського ІТ. Надзвичайно розумний, досвідчений та стриманий. Знає, здається, всі фреймворки, які придумав світ.
Досвід: 10+ років



Процес розробки
І тут уже виникає перша проблема. (це я вже зрозумів потім)
Ми послухали нашого замовника і подумали, що це реально все, що він хоче, так як перше правило розробки: «Завжди слухай замовника». Хоча друге правило «Ніколи не слухай замовника» дасть про себе знати трошки потім.

Покумекали, що проект доволі простий, дедлайн у нас майже 2 місяці, а отже можна взяти те, з чим ми хотіли попрацювати, але на основних проектах цього немає.
Обрали ми Nest.js на базі Postrge з ORM Sequalize.

З Nest особисто я працював лиш на відео з ютубу, а з PostgreSQL останній раз мав справу близько 5 років тому. Ідеальний початок, чи не так?
Накидавши базову струкутуру проекту на PostgreSQL і працюючи над документацією для фронтенд розробника, нам порадили перейти на круту нову модну ORM від українських розробників під назвою Drizzle. «Це ж прекрасна ідея. Підтримаємо наших!», подумали ми і вирішили переписати вже готові наші 5 табличок зі всіма звязками на нову ORM. Це зайняло нам доволі багато часу, так як уявлення про Drizzle ніхто з нас не мав, а документація там доволі посередня, як на мене (хай вибачать мене розробники даного проекту).

Після того у нас був ще один кол з замовником, який вирішив побрейнштормити нас ідеями, які йому накидали його колеги. Там уже почали зявлятися перші паростки думок, що ми не вкладемося в 1,5 місяці, які залишились, так як зявилися команди, статистика та ще деякі речі, які звучать «А було б круто мати ****», але реалізувати це не так просто, як сказати. На слова, що це не так просто і швидко, як можна здатися, клієнт казав шось типу «Так отут кнопку нажав і воно показало». Іноді ми проводили майже по 2 години в спробі пояснити, що це трошки не так працює, за що я дякую пану Ю. з його сталевою витримкою.

Більше проблем
Поскільки на початку ніхто нам таких задач не ставив ми зрозуміли, що та структура бази даних, яка у нас є зараз нам підходить мало, або не підходить майже зовсім. І почався процес перебудовування таблиць. Там забрати, там додати, там нова таблиця і так пройшло ще майже 2 тижні.
Тут в дію вступило правило розробки номер 2 — ніколи не слухай свого клієнта.
Ми, як розробники, які бачать картину глибше, та мають більше досвіду в розробці мали б передбачити, що не все так просто, як описує замовник і потрібно готувати архітектуру під умовний блокчейн з АІ інтегрований з Резерв+ і логіном через Дію, а не те, як зробили це ми.

За той час, поки ми розробляли нову структуру бази даних у нас ставало все більше і більше пролем з Drizzle і питання зміни ORM стало ребром. Як реалізувати деякі речі ми просто не могли знайти в документації. ORM постійно видала не зрозумілі помилки і відмовлялась робити деякі звязки або ж типи для TypeScript. В свою чергу люди, які трошки більше працювали з ним, з якими ми консультувалися відповідали просто «Та там десь має бути, пошукай».
У мене навіть були думки переписати це на Express та Mongo, з яким ми працюємо на основному проекті і за відносно короткий проміжок часу здати проект. Але від такої ідеї мене відмовив мій колега, пан Р.

Потім настав ще один дзвінок з клієнтом, на який ми прийшли майже не готові, так як по суті ми лише боролися з створеною нами самими проблемою з посередньою архітектурою, не готовою до такої кількості нових фіч та погано вибраною ORM в спарці з Nest.js.
Але замовник не розгубився і почав нам накидати нових фіч. Тепер там зявилися сповіщення в телеграмі і керуванням всім проектом через Excel замість панелі адміністратора на сайті.
Сказати, що це нас вбило — не сказати нічого.

І ми вирішили поміняти ORM ... знову.
На цей раз ми обрали просте і зрозуміле рішення, з яким мав справу мій юний колега, який дуже багато зробив на стороні бекенду в часи змін, за що йому подяка. Вибір наш припав на Prisma.
Дякую Р., який переписав все самостійно на нову ORM і знову переробив структуру бази даних. Цей етап нам дався не дуже складно.
До здачі проекту залишається 2 тижні, а у нас з готового лиш CRUD на проекти та юзерів від якого корситі не дуже багато, вроховуючи всі побажання нашого замовника.

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

Зрозумівши, що ми нічого не встигаємо нам клієнт сказав, аби ми зробили хоча б те, про що ми говорили з самого початку, аби мати хоча б щось.


Чим все закінчилось?
Ми здали проект майже вчасно повернувшись туди, звідки ми почали свій шлях.
Проект залишився на Prisma та Nest.js. Але база данних була перероблена ... знову

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

Проект зарелізився. Команда щаслива. Замовник теж. Люди донатять. Підрозділ має кращу фінансову підтримку і нищить ворогів.
Хіба не заради цього все задумувалось?

Зараз проект переживає стадію ренесансу. Ми по трошки реалізуємо всі побажання клієнта, ростемо та розвиваємося.

Я ні в якому разі не хочу відлякати людей від проектів для ЗСУ. Діджиталізація армії дуже важлива. Тільки вона допоможе нам еволіціонувати з Української Паперової Армії в справжню армію сучасності. Якби не даний проект, я б не познайомився з деякими класними людьми, не вивичив би Nest та не спробував би декілька нових, цікавих, або не дуже ORM. А ви б, в свою чергу, не прочитали цю статтю.

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

tylovyky.com/ua


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

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

Але куди ж без уроку для самого себе?
І найголовніше, що я виніс з цього проекту — «Make it work, then make it good» це золоте правило, яке наша команда притримується на проекті і до чого нас підштовхує замовник на основному моєму місці роботи. І звичайно, що ми його порушили на цьому проекті. Маючи в запасі величезний проміжок часу, ми вирішили поексперементувати з технологіями, які були нам зовсім не відомі. Через що ми втратили багато часу, на те, аби зробити найпростіші елементи. Спочатку було необхідно зробити проект на технологіях, які нам були відомі і тоді вже переписати на щось інше.

Другим уроком є правило «Не слухай свого клієнта» (не забуваємо про правило «завжди слухай свого клієнта»). Знову ж таки не допрацювання в тому, що ми не врахували того, що побажання клієнта будуть рости пропорційно часу, яке він проводить в роздумах над проектом. І опис проекту на першому тижні може кардиально відрізняти від опису проекту на другому тижні. Потрібно завжди думати на випередження (або хоча б пробувати це робити), та думати що можна було б додати до цього проекту, та закладати архітектуру одразу.

І останнє на сьогодні, третє праило — завжди розвивайся. Працюючи вже майже 5 років на одному проекті, де все доволі стало і нема кардинальних змін, розумієш, що почав «ржавіти» як розробник. Я ніби вийшов з кріо камери після 100 років без свідомості. Навколо стільки нового! Так багато нових фреймоврків, біблотек, обгорток, надбудов. І ти розумієш, що аби залишатися на ринку потрібно постійно розвиватися, вчитися, читати, писати код.
Навіть якщо у вас нема часу, енергії, сил на свій пет проект, то ви просто змушені вчитися і вирішувати задачі з прогармування в стилі CodeWars / LeetCode. В іншому випадку за 5 років будете відчувати себе як неандерталець в 21му столітті.

P.S
Хочу висловити подяку людям, які пройшли зі мною цей шлях.
— Нашому замовнику пану Б. та пані М. за чудову можливість попрацювати на проекті для однієї з найкращих бригад ЗСУ.
— Фронтенд розробнику Ю. за його неоціненний вклад в розробку проекту та пояснення нам не відомих до цього речей
— Бекенд розробнику Р. за те, що в часи, коли це було необхідно сидів до ранку та писав код та за продуктивну спільну роботу.



Сподіваюсь ця стаття допоможе вам не робити моїх помилок на ваших проектах.