ВСТУП
Я не можу порахувати скільки разів за всі роки роботи я думав: «А можна простіше?», розгрібаючи код, який хтось колись вирішив написати «по-дорослому» там, де це не треба було робити. Я думаю, я не один був у такій ситуації.
МОВА ТУТ ПІДЕ ПРО СУМНОЗВІСНИЙ OVERENGINEERING
У світі розробки нерідко стаються ситуації, коли хочеться зробити все ідеально. Наприклад, коли потрібно просто розв'язати задачу, а хтось бере і створює нову задачу з її розв'язанням.
Overengineering народжується саме в той момент, коли ви берете екскаватор, щоб перекопати маленьку клумбу.
Можливо, ви помічали в LinkedIn, або на форумах, де сидять одні лише розробники, суперечки про те, що краще Java чи Go, Tailwind чи просто звичайний CSS, моноліт чи мікросервіси? Найцікавіший момент у цьому всьому — це те, що у всіх цих питань є спільна проблема: а саме використання інструменту, який просто не відповідає контексту, або більший за сам контекст.
Оверінжиніринг — ситуація, в якій для вирішення простої проблеми використовується надмірно складний підхід, або надмірно складні інструменти/технології.
Якщо пояснювати з погляду абсолюту — ви створюєте пет-проєкт, але розгортаєте сервер на приблизно пʼяти інстансах AWS, вирішуєте зробити CI/CD на GitHub Actions, а ще додати Prometheus, Kafka, GraphQL, а ще систему авторизації на OpenID, бо так же роблять на крутих проєктах типу Netflix. Занадто, правда?
ІНСТРУКЦІЯ, ЩОБ НЕ ЗІЙТИ З ГЛУЗДУ
Не здуріти, пишучи код, можна тільки розуміючи до якого типу належить ваш проєкт. Ми зараз трохи модернізуємо вже наявну класифікацію — acute, business, casual.
ПРОЄКТИ ТИПУ A: «ЯКЩО ЗЛАМАЄТЬСЯ — БУДЕ КІНЕЦЬ СВІТУ»
Простими словами це розробка критично важливих систем: медичне обладнання, авіація, енергетика, військова справа і тому подібне. Тут потрібен максимальний рівень безпеки й такого поняття, як overengineering у проєктах такого типу майже не існує, бо все має бути на 100% перевірене, протестоване і застраховане від усіх можливих неприємних ситуацій, або нещасних випадків.
Пріоритети: надійність, а не бюджет і швидкість. Має бути все точно і правильно.
ПРОЄКТИ ТИПУ B: «ЦЕ ПРОСТО СОФТ ДЛЯ БІЗНЕСУ»
До цього типу відносяться більшість комерційних застосунків, всякі e-commerce, SaaS, CRM і всяке таке. Тут уже поломки не смертельні, але лінуватися і робити щось «аби було» точно не варто, бо можна втратити роботу і клієнтів. На таких проєктах без тестування точно не обійтись. І тестувати потрібно повністю, 100% покриття тестами. Тут важливі вартість і час.
Пріоритети: баланс між якістю, вартістю і швидкістю.
ПРОЄКТИ ТИПУ C: «ЦЕЙ ПРОЄКТ — МОЄ ПОРТФОЛІО І ТЕ, ЧОГО ДУША ХОЧЕ»
Сюди можна приписати будь-які пет-проєкти, експерименти зі свіжими технологіями й таке інше. Тут можна все (окрім того, що незаконно, само собою). Серед помилкових суджень часто можна зустріти думку, що пет-проєкт має мати таку саму архітектуру, як проєкти NASA, через що ці самі пет-проєкти часто не дописуються до своєї фінальної точки.
Пріоритети: це має бути по фану, має бути швидкий результат і бонусом нові знання.
КАЖУТЬ, ЩО OVERENGINEERING ЗАЛИШАЄ ШРАМИ
Не справжні, звісно, але вони таки іноді залишаються. І вони доволі неприємні. Іноді проблема не тільки в витраченому часі або грошах, а в тому, що якщо використовувати якийсь класний інструмент там, де його забагато, то дуже легко спотворюється правильне уявлення про цю технологію, або інструмент.
З цієї причини розробники потім не повертаються до вивчення цього інструменту і втрачають можливість використати його там, де він дійсно буде пасувати. Іноді важко зрозуміти, що проблема була не в технології.
ЯК НЕ ПОТРАПИТИ В ЦЮ ПАСТКУ
Перше, що завжди потрібно робити перед тим, як починаєте роботу з новим проєктом — це проаналізувати контекст. Тут просто потрібно поставити собі запитання:
- «Що треба зробити?», «Для кого/чого це потрібно зробити?», «Які терміни і який бюджет?».
- «А що буде, якщо я вирішу це простіше?». Якщо відповідь — «нічого», то ви зекономите собі час, зусилля, а компанії гроші.
Як би це не звучало, але технології потрібно поважати та враховувати, що кожна з них має своє застосування і своє місце. Іноді це місце — не в вашому проєкті. Далі — ревізія стека. Іноді варто передивитися весь стек і, якщо побачили щось складне, то спитати себе чи колег:
- «Навіщо воно тут?».
Нерідко стається ситуація, коли проєкт розростається, і замість чіткого функціоналу там вже живе якийсь невідомий страшний звір, якого всі бояться чіпати, бо без нього все може посипатись. І все дійсно може, але це не причина його не чіпати.
Якщо ніхто не зможе нормально пояснити навіщо він там, то це явний знак, що все можна зробити без нього.
Якщо відповідь на запитання «це дуже потужна enterprise штука», то цього, скоріше за все, потрібно позбутися, якщо не прозвучать нормальні аргументи.
Також іноді краще вчитися не тільки на своєму досвіді, а ще і на чужому. Досвід інших людей для вас — завжди безкоштовний і через це неоціненний. І ним потрібно користуватися. Тільки не користуйтеся думкою «Команда Uber зробила так і в них все вийшло — значить і нам так треба». Бо, найімовірніше, вам воно насправді не треба.
Але потрібно бути обережним, бо так можна замкнутися в одному стекові й майже забути, що таке розвиток себе як спеціаліста.
ВИСНОВОК
Іноді люди думають, що бути синьйором — це використовувати найкращі, найновіші й найскладніші технології. Вражати всіх абревіатурами в резюме, будувати мікросервіси поверх мікросервісів, але часто це все ілюзія.
Бути синьйором — це знати, де не потрібно використовувати зайвого.
Завжди потрібно думати, навіщо щось додається у проєкт, як і хто буде працювати з цим після тебе, як це вплине на користувацький досвід і тому подібне. Світ розробки й так непростий, тож не додавайте собі зайвих труднощів тільки заради справленого враження.
Програмуйте розумно, вибирайте технології з холодною головою і памʼятайте, що найкращі рішення — не завжди найскладніші.
А ми з вами, як завжди, зустрінемося в цьому ж місці і в цей же час.
