Парадигми, ідіоми мов, фреймворки, Domain Specific Languages, Domain Driven Design, Clean Architecture, Hexagonal Architecture, Onion Architecture, монади та моноіди, найкращі практики та методології, Test Driven Development, Behaviour Driven Development, SOLID: Single Responsibility Principle, Open/Closed Principle, [Barbara] Liskov’s Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle, AntiCorruption Layer, Model View Controller, Model View Viewmodel, Model View *Whatever, low-coupling, high-cohesion, 12 factor application, 5 lines per method, 100 lines per class, GoF patterns, DevOps, DevSecOps, SCRUM, Kanban, Team Topology, … – це все, коротко кажучи, лайно.
Досвід
Коли я ще працював молодшим розробником, то був значно ефективніше за цілу сучасну команду старших розробників, а потім почай вивчати усе те лайно, що продають консультанти і …
Я працював у команді з іншими мало досвідченими розробниками і це було весело і цікаво. Ми не писали тестів, а тестували усе самостійно, вручно. Ми просто розгортали код на production, спочатку на декілької машинах і якщо пару днів не було ніяких проблем, то розгортали оновлення на усі 1300 машин.
Я дивився на той примітивний код, що писали інші і він був мені зрозумілим. Він був послідовним та простим як п’ять копійок. Звісно, там були методи у сотні строк, там були класи у тисячі строк, але безліч задач потребувала просто додавання нових строк у те спагетті із коду. Ми просувалися швидко. Дуже швидко. Наша компанія збрала клієнта у Microsoft, SAP, Oracle з їх надскладними рішеннями, через нас звільнили команду 1C розробників на боці клієнта, оскільки ми за рік переробили усю функціонаьність, що була на боці 1C під потреби замовника і це було значно ефективніше та дешевше, аніж те, що було. Клієнту потрібно було запустити маркетингову акцію за місяць – один джун реалізовував це за тиждень. Microsoft, SAP, Oracle, точніше їх інтеграційні партнери говорили про терміни у щонайменше півроку та вартість у сотні тисяч американських зелених долларів. Один джуніор робив це за $250.
Потім ми почали покращувати якість, писати тести, налагоджувати складні процесси, винайняли менеджера проєктів, як роблять усі дорослі, почали впроваджувати SOLID та відмовлятися від товстих конроллерів у Ruby on Rails на користь товстих моделей, але й товсті моделі швидко почали не влаштовувати нас. Ми почали витрачати багато часу на те, що вважали якістю кода, а не на побажання замовників. Замість того, аби просто виконати завдання ми почали до 90% часу на вирішення задачі витрачати на рефакторинг.
Зі зміною компаній та проєктів я багато чому вчився, виступав на конференціях та мітапах, почав погано ставитися до Ruby on Rails, вивчати безліч інших мов програмування, парадигм та підходів аби знайте те саме, але так і не знайшов. Я починав з команди умовних джунів, які не знали ні за які паттерни, а потім пропрацював у близько десяти компаній як розробник, team/tech leader, консультант, архітектор, де використовувались передові підходи і технології та усі можливі найкращі практики і що я помітив, то це те, що якість коду з використанням усього цього багажу знань ставала лише гірше. Під якістю коду я маю на увазі те, як легко його можна зрозуміти та викинути.
Усі використання паттернів та підходів лише генерували більше коду, який до того ж було важче читати. Так я прийшов до висновку, що нічого з цього не працює, а на мені лише наживаються консультанти, книжки та курси яких я купував. Не так шкода тисяч доларів витрачених на учбові матеріали для підвищення кваліфікації, як витраченого часу, хоча варто зазначити і позитивний момент – проходити співбесіди та знаходити роботу стало значно легше.
Культ вантажу
Патерни GoF – це документування типових рішень до яких розробники з різних сторін світу приходили самостійно, чи ділючись досвідом. Ними користувалися задовго до власне формулювання GoF патернів, а зараз стоїть реальна вимога, принаймні на співбесідах, не вміти вирішити ту чи іншу проблему, а тупо завчити та переповісти GoF. Наше дебільна освітня система відтворила себе серед таких просунутих АйТівців.
Більшість розробників не розуміють, що використання патернів не є обов’язковим тільки через те, що той чи інший патерн можуть бути використані. Патерни змушують писати більше більш складного коду. Їх використання не є безкоштовним. Навіть якщо Вам подарували книжку – Ви маєте витратити на її читання час.
Багато хто просто бере на озброєння будь-який новий підхід чи технологію, якими користуються компанії FAANG. З одного боку, ніхто не звільнить за використання IBM, а з іншого, це можна назвати Resume Driven Development. Коли ж технологія чи підхід знаходяться на вершині хайпу, то велика частка розробників вже має адаптуватися. Усе це дійсно надає переваг у пошуку роботи, але на якість рішень радше впливає негативно.
Так стан справ нагадує анекдот про рабина:
Одного разу в одного фермера почали дохнути кури і той вирішив звернутися до рабина за порадою. На зустрічі рабин порадив фермеру повісити над курником зелений квадрат. Фермер зробив усе як порадив рабин, але це не допомогло, то ж фермер вирішив звернутися до рабина вдруге через тиждень. На наступну зустріч рабин порадив фермеру повішати над курником червоний трикутник. Фермер зробив все як йому було сказано, але кури продовжили мерти. Тоді фермер вирішив піти до рабина ще раз. І наступного разу рабин порадив фермеру повішати над курником жовле коло. Фермер повернувся до дому, одразу ж повісив жовте коло, але минуло два дні і всі кури померли.
Тоді фермер знову звернувся до рабина, та й каже: “Ребе, я все зробив, що ти мені говорив, не оминув жодної, навіть найдрібнішої деталі, але це не допомогло і всі кури здохли”. На це рабин почухав потилицю і мовив: “Шкода, що так вийшло. В мене ще так багато було ідей”.
Так і розробники виконують різноманітні ритуали без жодної доведеної ефективності, а “кури” продовжують дохнути.
Що з цим робити?
Проблеми майже завжди треба вирішувати на зовсім іншому рівні, на якому розробники зазвичай не мають жодних повноважень. Вже потім, коли є бажана онтологія та структура, проблему необхідно вирішувати в лоба, бо необхідні рішення прийняті, а гнучкість – це компроміс з дияволом.
Гнучкість (Manifesto of Agile Software Development) існує лише тому, що жоден замовник не хоче приймати рішень та брати за них відповідальність, адже у більшості випадків замовник – це лише менеджер. Я працював у декількох аутсорсингових компаніях і знаю як сильно відрізняється замовник – засновкик від замовника – менеджера.
Замовник не бажає витрачати купу часу та грошей просто на те, аби зібрати вимоги та продумати структури власного бізнесу, які до цих пір не були продумані. “Зробіть мені те, що я хочу (але я чітко не розумію чого хочу), а не розповідайте мені як в мене все погано”. Інформаційні системи лише відображають власних розробників та замовників. Якщо там повний хаос, то і інформаційна система перетвориться на лайно і жодні патерни, парадигми, лінтери, методології не допоможуть із цим. Найбільш якісні зразки інформаційних систем створені розробниками самими для себе ще до виникнення такої кількості підходів, патернів, практик та відповідних учбових матеріалів.
Якщо немає рішень, то немає і архітектури і якоїсь одноманітності яка ультимативно зменшує складність, оскільки архітектура – це найбільш важливі і вартісні рішення. Бізнес не знає майбутнього, але й не здатен поставити експерименту, адже кожен експеримент – це canary test нової бізнес-моделі, фактично нового бізнесу під парасолькою старого. Це складно, дорого та повільно, а хочеться просто, дешево та швидко. Так не буває! У результаті маємо хаос на вході (структура компанії та структура коммунікацій у компанії) і його відображення на виході (інформаційна система).
На цей момент уважний читач мав би зрозуміти, що розробник насправді не може значною мірою вплинути на якість, оскільки не може вплинути на складність, але є один простий прийом, який все ж таки здатен суттево вплинути і на якість і на швидкість розробки, а саме: Необхідно писати код як чайник/нуб.
Справа у тому, що будь який код – то складне лайно і не існує способів цього уникнути, а отже необхідно створювати складне лайно у максимально простий, лінійний спосіб. Я ще не бачив, як підходи, патерни, методології дозволяли уникнути чи принаймні затримати необхідність переписування застарілої, переускладненої, неповороткої інформаційної системи.
Пишіть як нуби. Пишіть наче нічого не знаєте. Не витрачайте час на вивчення нового лайна. Вирішуйте проблеми в лоба, без створення зайвих абстракцій.
Додатково
- Write Code Like You Just Learned How to Program
- The Grug Brained Developer. A layman’s guide to thinking like the self-aware smol brained
- Data is not the problem domain section from the Data Oriented Design Book by Richard Fabian.
Залишити відповідь