Был поздний вечер.
Мой коллега только что записал в репозиторий код, над которым работал целую неделю. Мы делали тогда графический редактор, а в свежем коде были реализованы возможности по изменению фигур, находящихся в рабочем поле. Фигуры, например — прямоугольники и овалы, можно было модифицировать, перемещая небольшие маркеры, расположенные на их краях.
Код работал.
Но в нём было много повторяющихся однотипных конструкций. Каждая фигура (вроде того же прямоугольника или овала) обладала различным набором маркеров. Перемещение этих маркеров в разных направлениях по-разному влияло на позицию и размер фигуры. А если пользователь, двигая маркеры, удерживал нажатой клавишу Shift, нам, кроме того, надо было сохранять пропорции фигуры при изменении её размера. В общем — в коде было много вычислений.
Код, о котором идёт речь, выглядел примерно так:
let Rectangle = {
resizeTopLeft(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeTopRight(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeBottomLeft(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeBottomRight(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
};
let Oval = {
resizeLeft(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeRight(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeTop(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeBottom(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
};
let Header = {
resizeLeft(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeRight(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
}
let TextBlock = {
resizeTopLeft(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeTopRight(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeBottomLeft(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
resizeBottomRight(position, size, preserveAspect, dx, dy) {
// 10 однотипных строк вычислений
},
};Меня все эти вычисления, все эти почти одинаковые строки, сильно зацепили.
Код не был чистым.
Основной объём однотипных строк наблюдался в тех местах, где задавалось перемещение фигур в одном и том же направлении. Например, в методе Oval.resizeLeft() был код, похожий на тот, который можно было найти в Header.resizeLeft(). Дело было в том, что оба эти метода отвечают за изменения фигуры, выполняемые при перемещении маркера влево.
Похожими были и методы фигур, имеющих одну и ту же форму. Например, Oval.resizeLeft() был похож на все остальные методы фигуры Oval. Все эти методы работали с овалами — отсюда и их сходство. Дублирующийся код можно было найти в объектах Rectangle, Header и TextBlock, так как текстовые блоки представляли собой прямоугольники.
У меня появилась идея.
Можно избавиться от дублирующихся конструкций, по-другому сгруппировав код. Например — так:
let Directions = {
top(...) {
// 5 уникальных строк вычислений
},
left(...) {
// 5 уникальных строк вычислений
},
bottom(...) {
// 5 уникальных строк вычислений
},
right(...) {
// 5 уникальных строк вычислений
},
};
let Shapes = {
Oval(...) {
// 5 уникальных строк вычислений
},
Rectangle(...) {
// 5 уникальных строк вычислений
},
}Затем можно прибегнуть к композиции и собрать из этих базовых методов то, что нужно:
let {top, bottom, left, right} = Directions;
function createHandle(directions) {
// 20 строк кода
}
let fourCorners = [
createHandle([top, left]),
createHandle([top, right]),
createHandle([bottom, left]),
createHandle([bottom, right]),
];
let fourSides = [
createHandle([top]),
createHandle([left]),
createHandle([right]),
createHandle([bottom]),
];
let twoSides = [
createHandle([left]),
createHandle([right]),
];
function createBox(shape, handles) {
// 20 строк кода
}
let Rectangle = createBox(Shapes.Rectangle, fourCorners);
let Oval = createBox(Shapes.Oval, fourSides);
let Header = createBox(Shapes.Rectangle, twoSides);
let TextBox = createBox(Shapes.Rectangle, fourCorners);То, что у меня получилось, было в два раза меньше того, что написал коллега. В моём варианте программы полностью отсутствовали повторяющиеся фрагменты! Чистейший код. Если нужно было изменить поведение системы, относящееся к конкретному направлению, или к конкретной фигуре, можно было сделать это в одном месте, а не переписывать несколько методов.
Была уже поздняя ночь (я увлёкся). Я влил результаты рефакторинга в ветку master и отправился спать, гордый тем, как я «причесал» неопрятный код коллеги.
Следующее утро
…прошло не так, как ожидалось.
Руководитель пригласил меня на разговор за закрытыми дверями, в ходе которого вежливо попросил меня откатить мои изменения. Меня это потрясло. Ведь старый код — это же сплошной бардак. А мой код был чистым.
Я нехотя исполнил просьбу, но мне понадобились годы для того, чтобы понять правоту руководителя и коллеги.
Это — одна из ступеней развития программиста
Зацикленность на «чистом коде» и стремление к удалению дубликатов — это одна из ступеней развития программиста, через которую проходили многие из нас. Когда мы не чувствуем уверенности в своём коде, возникает желание привязать наше восприятие самооценки и профессиональной гордости к чему-то такому, что можно измерить. Набор строгих правил линтинга, схема именования сущностей, структура файлов проекта, минимизация дублирующегося кода.
Нельзя автоматизировать борьбу с повторяющимся кодом, но эта борьба, совершенно точно, становится легче с практикой. Обычно после каждого изменения можно сказать о том, больше или меньше одинаковых конструкций стало в проекте. В результате избавление от дублирующихся фрагментов программы воспринимается как улучшение некоего объективного показателя качества кода. И, что хуже, это искажает самосознание программиста: «Я из тех, кто пишет чистый код». Это так же сильно влияет на человека, как и любой другой род самообмана.
Как только программист узнаёт о том, как создавать абстракции, он вполне может этим увлечься. Он, видя дублирующийся код, будет находить абстракции там, где их нет. А после нескольких лет такой практики дублирующийся код будет обнаруживаться абсолютно везде. Абстрагирование станет новым талантом программиста. Если кто-то скажет ему, что абстрагирование — это добродетель, он это примет. И он начнёт осуждать тех, кто не преклоняется перед «чистотой».
Теперь я понимаю, что у моего «рефакторинга», и у того, как я к нему подошёл, было два серьёзных недостатка:
- Во-первых, я не поговорил с тем, кто написал код. Я переписал код и залил его в репозиторий, не обсудив изменения с автором кода. Даже если мои изменения улучшали бы программу (я больше так не считаю), это — демонстрация совершенно неправильного подхода к подобным делам. В основе здоровой команды программистов лежит постоянное укрепление доверия. А если переписать код одного из членов команды и с ним не посоветоваться — это нанесёт удар по возможности эффективной совместной работы над проектом.
- Во-вторых, за всё надо платить. Мой код пожертвовал возможностью менять требования в угоду сокращения объёма дублирования. Цена этой жертвы была слишком высока. Например, позже нам понадобилось обрабатывать множество особых условий и вариантов поведения для различных маркеров разных фигур. Мою абстракцию для поддержки подобных требований пришлось бы основательно усложнить. А вот в исходную «неаккуратную» версию кода подобные изменения вносились легче лёгкого.
Говорю ли я о том, что вам нужно писать «грязный» код? Нет. Я предлагаю лишь хорошо подумать над тем, что имеют в виду под понятиями «чистый» и «грязный». Что-то приводит вас в негодование? Вы чувствуете в чём-то правильность, красоту, изящество? Уверены ли вы в том, что можете применять подобные понятия, описывая конкретные результаты работы программистов? Каким образом эти понятия влияют на то, как пишут и модифицируют код?
Я, конечно, о таких вещах тогда не думал. Я много размышлял о том, как выглядел код — но не о том, как он развивался вместе с командой, состоящей из людей, которым не чуждо ничто человеческое.
Программирование — это путь. Подумайте о том, как далеко вы продвинулись от написанной вами первой строчки кода, до того места, где находитесь сейчас. Я полагаю, что вы, в первый раз извлекая функцию или подвергая класс рефакторингу, с восхищением наблюдали за тем, как эти приёмы упрощают сложный код. Если вы чувствуете гордость за своё дело, то у вас появится стремление к преследованию чистоты кода. Поддайтесь на некоторое время этому стремлению.
Но не останавливайтесь на этом. Не становитесь фанатичным приверженцем чистого кода. Чистый код — это не цель. Это — попытка как-то осмыслить огромную сложность систем, с которыми мы имеем дело. Это защитный механизм, который программист применяет тогда, кода ещё не уверен в том, как некое изменение повлияет на кодовую базу проекта, но ищет ориентиры в море неизвестности.
Пусть идея чистого кода станет вашим ориентиром. А потом — отпустите эту идею.
Уважаемые читатели! Как вы относитесь к «чистому коду»?
Автор: ru_vds
