Кінець епохи Clean Code

Якщо почати читати книгу «Clean Code» Роберта Мартіна (Robert Martin) будучи вже розробником зі стажем, то навіть якщо ігнорувати думки про те, що чистота коду — достатньо суб’єктивне поняття, в книзі можна помітити багато спірних практик або принаймні таких, які неможливо застосувати до всіх сценаріїв розробки.

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

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

Однак, один досвідчений розробник Кейсі Мураторі (Casey Muratori) наприкінці 2023 року вирішив детальніше дослідити — чи дійсно принципи, викладені в «Clean Code», підвищують продуктивність, адже саме продуктивність розробки — першочергова ціль підходів, викладених у книзі. В процесі дослідження Кейсі прийшов до неочікуваних висновків.

В своєму відео «Clean» Code, Horrible Performance він бере з книги Боба Мартіна всім відомий приклад, де є базовий клас — фігура, від нього наслідуються круги та квадрати, в яких обчислюється їх площина.

Кейсі виміряв швидкість роботи цього ідеального прикладу, взявши його результати за основу. Потім він порушив принцип поліморфізму, використавши замість нього if/switch, і швидкість коду виросла в 1,5 рази. Далі він знехтував вимогою ігнорувати те, як все працює зсередини, трохи змінив код, додав константу, і швидкість роботи коду виросла в 11 разів! Продовжуючи оптимізовувати код, викидаючи з нього принципи, які в книзі подаються як фундаментальні, Кейсі досяг x21 performance, але при цьому кількість чи складність коду суб’єктивно не збільшилась.

Кейсі Мураторі підкреслює думку про те, що останні 12 років розвитку заліза, розробники просто помножили на нуль, бездумно використовуючи принципи «Clean Code». І важко не погодитися з тим, що збільшення споживання ресурсів простими, здавалось би, програмами корелює з експансією ідей, викладених у «Clean Code».

Одразу виникає цікаве питання у вакуумі — наскільки світу потрібно було б менше хмар, якби ми використовували інший фундамент замість Clean Code? І чи справді, розробка була б значно дорожчою та довшою?

Кейсі щиро вважає, що читабельність, підтримуваність та все інше, про що говорить «Clean Code», можна досягнути іншими методами.

Я пам’ятаю, як у якості звичайного користувача, на топовому смартфоні у 2016 році відкривав карти, і вони працювали швидко. З тих пір карти наповнилися функціоналом досить мінорно, але на тому ж телефоні ними користуватися тепер боляче. Звичайно, справа тут не тільки у застосунку, а й у всій операційній системі, яка теж змінилася мінорно, але чомусь помітно сповільнилася. Чотири ядра вже не вивозять показати прості статичні інтерфейси з парою кнопок, і потрібно мати 12 турбо ядер лише для того, щоб отримати той самий користувацький досвід, який ми мали в 2016-му.

Само собою виникає питання, а чи не має оптимізація споживання ресурсів, бути частиною фундаментальної бази розробки? Чи потрібно почати вважати неоптимальними всі практики, що помітно сповільнюють код?

В якийсь момент між творцем концепції «Clean Code» та Кейсі Мураторі зав’язалась дискусія. Її лог викладено на GitHub: cmuratori-discussion.

В діалозі між Бобом та Кейсі, перший вказує на те, що він в першу чергу експерт в тайм-менеджменті, а не в залізі, але на його думку performance можна ігнорувати, бо це якийсь 1% від потужностей сучасних процесорів. У відповідь Кейсі надсилає Бобу пруфи того, що коли він просто пише йому у відповідь текстове повідомлення — все лагає, хоча здавалось би, що може бути простіше за написання тексту?

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

У цій розмові Кейсі стверджує, що if та switch не менш читабельні за поліморфічні методи, але кратно швидші. Розмова завершується на пропозиції Боба, що їх має розсудити спільнота.

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

Для себе я вже давно зробив висновок, що у випадку невеликих команд та продуктів дотримуватися всіх принципів, викладених у «Clean Code», недоцільно, а тут ще приходить розуміння, що навіть шкідливо.

У книзі Боба Мартіна озвучено багато цікавих та корисних ідей, але вони всі разом не можуть трактуватися мною як база та стандарт. Хіба що частина з них, але прогалин лишається багато.

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

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

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