Не називайте код словом "Продукт"

«Нам важливий готовий продукт — начхати на поганий код»
"Нам важливий підтримуваний продукт - нехай це і буде довго"

Код (наше програмне забезпечення, програмне забезпечення) — це частина продукту. Як і інші частини, вона повинна легко схрещуватися з рештою частин і підлаштовуватися під них. Під поняттям "легко" - я маю на увазі наступний набір: "швидко", "не титанічною працею", "без раптових наслідків".

Багато хто помиляється і кажуть що якість коду тут вирішальний момент. Зазвичай все зводитиметься до того, що «говнокод можна швидко написати і запустити», а «хороший код не має раптових наслідків». Ні. Вирішальний момент - це можливість це змінювати. Адже процес схрещування програмного забезпечення з іншими частинами бізнесу — це і є його зміна.

Коли маркетологи просять зберігати utm-мітки зареєстрованого користувача, коли необхідно відправляти емейли певної верстки, коли необхідно додати у ваш інтернет-магазин фічу «а з цим купують ще» - це і є процес інтеграції ПЗ з іншими сегментами бізнесу. Саме цей процес має відбуватися швидко, просто, без раптових багів. І не потрібно винаходити велосипеда — все вже придумано до нас.

Модульність

Якщо Ви не є прихильником SOA/мікросервісів і пишіть моноліт — зробіть його модульним. Навіщо це потрібно? Ось набір основних пунктів:

1 фіча - 1 модуль. Можна легко та швидко написати з нуля «з бруду та гілок» — те, що потрібно для бізнесу зараз. Коли виникне потреба підтримувати це — можна легко змінити код модуля для більшої читальності, зберігши інтерфейс.
Компонування. Хороший модуль – не річ у собі. Його можна перевикористовувати та компонувати. Згадуємо bash і pipe;-) «cat /etc/passwd grep root tr':''''awk''»— ось він приклад модульності та компонування. Unix-way називається.
Легко викинути/вимкнути. Якщо маркетинг помилився (а середньому 70% дій маркетингу — це спроби, помилки, знову спроби) — можна легко викинути зайвий шматок.

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

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

SOA/мікросервіси

Ця та сама модульність і правила ті ж, тільки більш гнучка. Різниця в тому, що модулі тепер називаються сервіси і взаємодіють не викликом публічних методів, а по мережі передачі даних. Правила ті самі, але з додаванням нового, воно робить життя бізнесу ще легшим. Ось повний список:

Розробити та продумати SOA архітектуру, вибрати протоколи та формати складніше ніж розробити модульний моноліт, але великий плюс SOA – це те, що всі велосипедипридумані до нас — треба лише вибрати.

Яке це стосується слова «Продукт»?

Насправді одне єдине — проста та гнучка архітектура допомагає будувати продукт і робить з IT надійну частину бізнесу, а не «слабку ланку компанії».

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

"Кому потрібна архітектурочка"?

Відповідь така проста як і питання — не треба плутати поняття архітектури та «красивого коду». Гарний код потрібен розробникам, щоб його легко правити, можна було їм мірятися з колегами. Проста та гнучка архітектура – замовнику, щоб його вимоги до розробки виконувались.

Архітектура - це як набір сірникових коробок. У них можна покласти сірники, можна траву. Можна наколінний код, можна гарний. Вона нічого не зобов'язує. Якщо ви такий сірниковий коробок зробите, що нічого крім сірника в нього не засунути, то, звичайно, цей коробок - фігня повна.

Те, як нам «передавати дані в шаблони з контролерів» — у вигляді масивів або об'єктів-колекцій — здебільшого не має взагалі жодного відношення до архітектури ПЗ.

Так само не потрібно відносити до архітектури вибір мови якою ви пишите — будь-якою повноцінною мовою програмування можна створити хорошу архітектуру, а можна і погану.

Як створювати хорошу архітектуру?

Робота з продумування взаємодії та компонування модулів/сервісів - здебільшого заснована на виборі. Щоб вибирати, потрібно знати стек технологій з якими ви працюєте. Вибирати найпростіші.

Знати стек технологійце не означає «я знаю кунг-фу, карате та інші круті слова». Знати стек потрібно з початку, а не з кінця - багато речей народилися 30 років тому і працюють відмінно, виконуючи свої функції досі. Звичайно, завжди хочеться взяти щось нове і спробувати, повчитися — але «пробувати і вчитися» — це для Junior/Middle розробника, не для архітектора.

Знати стек технологій потрібно детально та зсередини. Завжди поставте собі запитання — «чому я вибрав це?». Якщо ви відповіли на це запитання «я з цим знайомий більше» — отже, у вас недостатньо досвіду для тверезого вибору рішення, потрібно вивчати технології.

Якщо ви відповіли «крім цього рішення — альтернатив немає», є два варіанти:

Що робити якщо вам дістався вже готовий проект із п'ятнадцятирічним legacy? У ньому немає модульності, немає сервісів, а ті, що є, далеко не мікро. Ідіть за стратегією розбиття моноліту. Від великого старого моноліту зручно йти до мікросервісів. Виносьте атомарні частини поза. Почніть із винесення технічно складних речей — це одразу мінімізує баги та дасть час на позитивну розробку.

Мікросервіс – це як функціональне програмування. Тільки не функція, а обслуговування. Він простий, атомарний. Коли в мікросервісі є тільки одна функція — наприклад, надавати OAuth — він тільки це і повинен робити, БД має бути поза ним. Або сервіс для ресайзу картинок - лише ресайзит їх. Не треба ж у ньому їх зберігати.

Підсумок напевно у тому, що холівар «красивий код»/«швидке рішення» загалом ні про що. Базується він зазвичай на архітектурі, що не розширюється.

Архітектура - не найважливіше у ПЗ. Її не потрібно розвивати та розробляти – це робота на 3-5 днів. Сісти, подумати, описати. І ще на півроку-рік для керівника навчити всіх її дотримуватися.

Архітектура – не срібнакуля. Вона не робить ні фічі, але може зробити баги. Грамотна архітектура - дозволяє робити фічі швидко на коліні поруч із рештою красивого коду і не псувати загальну картину. Компонувати, перевикористовувати. Неписьменна — призводить до раптових проблем та довгої розробки. Її відсутність — зазвичай ще й неписьменна.

А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»