Судячи з лайків, вам сподобалася минула історія. Вечір п'ятниці, отже час нової!

Як кажуть, рефакторинг не можна закінчити, його можна відкласти. Ось сьогодні я розповім про свій найефективніший рефакторинг.

Справа була у той час, коли я ще працював українському аутсорсі. Щоб бути точним, це була модель Team Extension, тобто з нашого боку інженери, які доповнюють існуючу інженерну команду замовника.

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

Під час knowledge sharing архітектор замовника розповів, що інженер реалізує функціонал, який вже був створений як CLI утиліта. Цю утиліту написали і підтримують інженери компанії для інтеграції сервісів. Тобто інженер розбирався в коді утиліти та переписував його на JavaScript. Причому, планів відмовлятися від утиліти не було. Архітектор розумів, що такий підхід руйнує single source of truth, але не знав, що з цим робити. Я запропонував зробити рефакторинг, який включатиме CLI як частину додатку. Тоді код у Node.js просто буде викликати CLI утиліту як дочірній процес та спостерігати за виведенням.

Завдання-рефакторинг було додано у наступний спринт. Я провів сесію парного програмування з інженером і показав йому приклад з документації Node.js щодо child_process. Виявилося, що у утиліти навіть є прапорець --json, тому не потрібно було розбирати формат її відповіді. Ось так понад 1000 рядків коду перетворилися на 50, що не потребували тестування і були готові до змін.