Дяка)

Скоро просунемо nodejs на бек, і на беку також все стане просто XD

Дякую автору за статтю. Дійсно підхід розшарування проекту являється правильним вектором, втім дозвольте додати декілька коментарів які стосуються деталей реалізації:
1. В статті зазначалось питання композиції шарів, але я б хотів звернути увагу на їх ізольованості. Скажімо я б хотів з шару StateLayer викликати шар ServiceLayer, що мені завадить це зробити? Сподіваюсь відповіддю буде не «код ревью», і сподіваюсь в наступній статті автор трішки зачепить цю тему, і можливо, навіть, з використанням IoC.
2. Чи варто виносити «утіліти» в окремий шар? Як було зазначено вони — просто шматки чистих функцій які можуть знадобитись будь-де на проекті. Враховуючи їх... глобальність, чи варто взагалі до них відноситись як до шару накладаючи додаткову когнитивну складність для розуміння цих фунцій? P.S. якщо програміст створює хелпер — значить десь на проекті є косяк. Бо навіть функції форматування дати можна знайти краще місце)
3. В статті описаний дуже архаічний погляд на роботу з стором, особливо в контексті vue3. Я обожнюю те як автор пропонує працювати зі стором, але реалії такі що від такого підходу багато хто вже давно відмовився і тенденція іде саме в цю сторону. Ну і знову, якщо брати чистий redux або flux, то там архітектурно закладені обмеження які не дадуть напряму мутувати стору... у vue в цьому плані все куди гірше ((
4. З того що очікував, але не побачив — якийсь middleware прошарок для опису бізнес-логіки. Тобто ось потрібно нам оновити сторінку з продуктами на якій є пошук, фільтри і інше. До того ж є бізнес-правило що фільтрувати продукти можна лише тоді коли луна знаходиться в 3ій фазі. І ось куди запхнути код який формує payload для запиту і описує бізнес-правило? В action? Не дай боже, але кудись в utils? Залишити в компоненті? Як на мене всі перераховані варіанти погані, але в статті я не знайшов опису альтернативи, і сподіваюсь автор наступного разу також зверне на це увагу)

Тобто я говорив за аттребути загалом, як перелік якостей, а не за якісь конкретні)

Якщо ми говоримо за фронтенд, то я дуже легко можу уявити як мануальщики пропустили який рідкий випадок і на проді n користувачів зловить бажину типу «can’t get name from undefined». І ось зробити так що б ця бажина не поклала апку — досить доцільно, адже навіть на 100% (утопія) покритий тестами проект не гарантує що таке не трапиться на проді )

Втім якщо овнер вважає що краще найняти n розробників для мануального парсингу лгів — для мене це був би червоний флаг для відкриття свого резюме на джинни))))

Але про овнерів і манагерів в 2ій частинні статті, сподіваюсь скоро вийде ))

Так, я їх обрав для прикладу і тільки. Кожен розробник має вирішувати що для проекту пріоритетне, а чим можна пожертвувати.

Мабуть варто цю фразу «для прикладу» додати в статтю )

Доречі також кейс)))

Були в моїй кар’єрі проекти які просто залишали помирати на «підтримці» доки вони приносять дохід, з розумінням що відрефакторити неможливо, а вдосконалювати — задорого )

btw якби я працював на проекті який ви навели як приклад — я б думав в таку сторону:
1. Якщо софт для брокерів — він перш за все має бути відомовостійким. Якщо апка регулярно крашиться після релізів це буде бісити клієнтів які не змогли вчасно щось продати і такі проблеми буде не раціонально виявляти шляхом тестування на проді. Перш за все через те що страждає бренд ))
2. Якщо все вирішувати баблом, воно буде швидше закінчуватись. В часи в компанії дохід рахують в вагонах таке рішення може й буде працювати, а ось при першій же кризі буде дуже тяжко. Тому якщо сказати що півтора вагона бабла на місяць можна буде економити якщо витратити 3 вагона на те що б зробити оцю штуку краще — для майже будь-якого менеджера це буде раціональна пропозиція)

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

Мені здалось що ви подумали що я пропоную спочатку розробляти проекти як-небуть, а потім думати про аттребути і планувати архітектуру. Ні, це не так))
Я також думаю що краще спочатку спланувати — потім зробити, і планування повинно враховувати потреби проекту.

Втім, якщо так сталось що проект вже написаний. Ви бачите що на ньому багато проблем і хочете це виправити, з чого взагалі починати? Гасити пожежі, або ж рефакторити що доведеться і коли буде час? Гадаю це програшна стратегія.
Для мене планування рефакторингу проекту — перший і найважливіший крок. І ось коли сідаєш перед порожнім листком конфлюєнса чи ноушина, дуже складно трансформувати думку «спалити все і переписати заново» в щось корисне. І, як на мене, як перший крок в розробці такого плану\дизайну має бути визначення тих самих аттребутів. Так як проект вже деякий час існує і його бізнес-модель настоялась, такі аттребути мають бути більш-менш зрозумілими, а досвід роботи з кодовою базою дасть змогу ще точніше їх визначити за тими проблемами які існують і найбільше заважають.
Далі, після їх визначення, операючись на них, можна приймати подальші рішення )

Ви з цим не згодні?)

Уточнюючи 3ій пункт:

Тобто я пропоную використовувати ці аттребути і визначати їх саме для формування вектору розвитку проекту і для створення підґрунття для прийняття рішень при рефакторінгу. Да і їх пріоритетність легше визначити коли проект уже деякий час живе і його бізнес-модель більш-менш сформована)

Дякую за комент. Дуже правильні твердження з якими важко не погодитись. Дозвольте відповісти по пунктах:
1. Навів саме цифру в 12 що б бути консистентним з статтею за посиланням. Згоден що їх кількість ніде не затверджена і перелік різниця в залежності від джерела... певно було б не зайвим це прописати)
2. Нічим. Просто мені сподобалась подача матеріалу у них. А в рамках цієї статті гадаю їх компетенція достатня )
3. Підтримую це визначення. Зайшов я в статті саме з боку виявлення цих аттребутів на проекті бо набагато легше визначати проблемні місця (а значить і косяки при проектуванні, якщо воно було) коли проект вже готовий і коли ці місця всім очевидні. Але не маючи відомостей про такі аттребути досить важко сформулювати ці «визначення слабких місць» в щось більш-менш конкретне ніж «наітіє». Да і відомості про основні аттребути можуть допомогти побачити проблему на проекті. Тому гадаю оперування цими термінами для виявлення проблемних місць і закладання вектору для масштабного рефакторингу також доречним. Хоча 100% згоден що їх призначення — це бути визначеними саме при проектуванні архітектури )

Згоден що вручну обфускований код краще переписати заново, ніж рефакторити)

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