«Хто написав це лайно?», запитав СТО, дивлячись на свій старий код. Або як працювати над «кульгавою» кодовою базою і не вигоріти

На Medium вийшов філософський блог про складнощі рефакторингу, розпач, пориви переписати «говнокод» з нуля та інші супутні труднощі, а також практичні поради, як привести кодову базу в порядок. Публікуємо переклад.

Хто написав це лайно?

СТО та розробник вивчають застарілу кодову базу, щоб виправити помилку. Муки вже прагнуть нескінченності, вони готові здатися.

“Хто написав це лайно?”, — запитав технічний директор. Схвильований, він перевірив, хто цей мерзотник. Ним виявився він сам.

***

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

Після перших двох годин Джейк вичерпав весь свій ентузіазм. Він загруз у павутинні розчарування, намагаючись розібратися у всіх змішаних ієрархіях — складніших, ніж королівське фамільне дерево в середньовічній Європі, довгих методах, які роблять багато різних речей, і іmplicits, захованих у темних кутах.

Він люто боровся з усім цим геніально нагромадженим сміттєзвалищем коду, але марно. Сумнів і тривога покрили його, як ранкова роса, чи це був піт? Той, хто це написав, геній чи просто мудак? Джейку зовсім не подобався цей код. Кодова база не відповідала його стилю коду.

“Це жахливо. Потрібно переписати це негайно”, — вирішив Джейк.

Всі ми трохи Джейк

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

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

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

Що ще може бути причиною? Чиясь самовпевненість і бажання зіпсувати настрій тому розробнику, який у майбутньому копатиметься в цьому коді? Як не сумно, не зарозумілість є загальною причиною «кульгавої» кодової бази. Розробники просто не знали виходу краще. Це ж не гріх. Кожен пише найкращий код, який може зараз, враховуючи всі обставини.

Чи врятує переписування ситуацію?

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

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

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

Чеклист при роботі з кодовою базою

Отже, що ви можете зробити для покращення ситуації?

• Для початку: не скаржтеся. Ніхто довкола не хоче це слухати, як і розробники не хочуть слухати, що вони влаштували бардак у базі. Вам це теж не сподобалося б.
• Візьміть за правило залишати по собі порядок після кожного відвідування. Полагодьте «розбите вікно», коли є час, навчіть це робити інших.
• Додайте тест перед виправленням помилки, і через якийсь час ви будете впевненіше щось змінювати або рефакторити. Покажіть усім приклад, що ось так по крихтах, але ви всі можете зробити свій внесок і зробити кодову базу краще, охайніше. Це не станеться відразу, але через якийсь результат стане помітнішим.
• Мотивуйте колег — поясніть, що це спростить вам подальшу роботу, буде корисніше для бізнесу загалом і т.д.
• Складіть короткостроковий та довгостроковий план того, що ви могли б покращити у базі.
• «Пожежа» на проекті, коли терміново потрібно щось зарелізтити і для цього потрібно «зрізати шлях», може статися будь-коли. Поставте перед собою (і командою) завдання повернутись і навести в коді порядок після того, як «пожежа» закінчиться.

Що думають айтівці

Розробники на Reddit зізналися, що всі мали такі моменти, коли дивишся на свій код і розумієш — «ну єресь якась». Однак, коли його писали, він не здавався таким дивним і незрозумілим. А тепер навіть підказки, залишені собі майбутньому, не допомагають.

Вони почали активно ділитися історіями зі свого досвіду.