Статьи

    Рассуждения на тему code reuse возникают в любом более-менее большом проекте, начинающем разваливаться под собственной тяжестью. Вдруг неожиданно выясняется, что в программе есть десять мест, работающие практически идентично, но не оформленные в одну нормальную функцию/класс, потому что сначала по-быстрому скопипастили, потом сделать нормально было некогда, потом все забыли об этом фронте работ как о страшном сне и так далее. Все эти отмазки и так хорошо всем известны, лишний раз их перечислять не требуется. Проблемы начинаются в момент внесения изменений в дублирующиеся участки кода. Десять раз опрометчиво нажали ctrl-v, значит нужно менять в десяти разных местах. В двух местах из десяти забыли/не доглядели/накосячили. В итоге получили два возврата от тестировщиков (дай бог от тестировщиков, а не от клиентов, или, ещё хуже, принимающей организации). Как правило в ваших программах будет таких мест гораздо больше. Помнится рефакторил одну подсистему в некой программе. После рефакторинга количество кода уменьшилось в 100 раз. Для тех кто не понял с первого раза — на два порядка. Матёрый копипастер прогу ваял.

    Неумелый копипаст не единственный источник проблем. «Велосипедисты» со стажем тоже не дадут заскучать. Причем в некоторых случаях создателей велосипедов по-человечески можно понять. Потому что, когда ради небольшой функции тебе предлагают воткнуть в свою программу жупел нереальных размеров и нереальной же корявости. Тут по-неволе начнешь задумываться, может действительно проще... того... ну вы поняли.

    Решений два — одно простое, другое правильное.

    Простое решение заключается в том, что до поры до времени все усиленно делают вид будто бы ничего криминального не происходит. Длится это ровно до того момента, когда программа в результате безудержного копипаста разрастается в размерах и тупо начинает разваливаться под собственной тяжестью. Сам был свидетелем того как софтинка, являющаяся по сути почтовым сервером, разрослась до размеров незатейливой операционной системы. При этом постоянно глючила, тормозила и несмотря на размеры функциональности имела «шиш да маленько».

    Как только проблема плохого code reuse становится очевидна даже топ-менеджерам, сразу начинаются поиски решений. Он традиционно ведётся в ключе «чтобы такого сделать, чтобы ничего не делать, но всё само собой разрешилось». У особо пытливых граждан даже появляется иллюзия, что такая изначально порочная цель достижима. Достигать её предлагается различными модными шаманствами. Типа тимбилдинга, частыми совещаниями и вебдванольными тулзами вроде вики или прочего. Всё это имеет кратковременный эффект, который как правило заключается в том что несколько недоумков сцепятся во время кофедрейка, выясняя чья реализация вектора лучше. Потом всё возвращается на круги своя, пока высокое начальство не начнёт опять кровь сворачивать.

    Причина подобного развития событий для многих тайна ибо не каждому дано понять, что code reuse в частности и качество кода (что бы под этим не понимали) в общем является такой же фичей проекта как и эргономичный интерфейс или гламурные иконки (я страсть как люблю гламурные иконки поэтому пихаю их везде где надо и где не надо)) ). А следовательно на реализацию этой фичи требуются ресурсы. И чем программисты бестолковее тем больше ресурсов надо. Простого решения не существует ещё и потому, что высокое качество кода требует постоянной работы в этом направлении. Стоит забить на это хоть на чуть-чуть как всё снова приходит в упадок и нужно начинать сначала.