Мой блог

Давайте создадим модуль, который будет отвечать за все, а потом будем дописывать его.

Я не встречал еще команды разработчиков, которые бы не согласились со мной, что избыточная ответственность на любой из модулей при разработке программного обеспечения это плохо.
Но я, порой, удивляюсь, как часто при анализе кода я вижу модули из 2000, 5000 или даже 10000 и более строк. Модуль, который отвечает, например, за отображение всех таблиц во всех интерфейсах приложения, либо за расчет всех коэффициентов во всех состояниях, либо еще за что-нибудь необходимое во всех возможных случаях.
При редактировании такого модуля, как правило, никто уже не понимает, зачем нужна конкретно эта функция и почему она такая. Проще дописать еще 500 строк кода нового функционала в таком модуле, чем разобраться со старым. Его невероятно тяжело тестировать, а попытка изменять существующий код приводит к падениям в самых неожиданных частях программы. Возникает проблема избыточной сложности продукта.
Именно избыточная сложность продукта чаще всего является причиной срыва сроков разработки.

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

Об этом легко говорить, когда модулей с избыточной ответственностью нет. Но что делать, когда такие модули есть и проект уже трещит по швам? Порой кажется, что если взять себя в руки и переписать весь модуль, разбив его на множество маленьких, параллельно переписав практически весь продукт, то проблема решится. Но, как правило, это не так. Перерасход уже ограниченного ресурса на переписывание большей части проекта приведет лишь к еще большему негативу от участников команды и ухудшению взаимодействия с руководством, а подобные модули появятся снова, только уже в других местах.
Увы, единственный метод, избежания подобных проблем – не допускать создания таких модулей. Можно попробовать договориться с командой, чтобы каждый взял на себя один из таких модулей. С руководством можно согласовать порядок изменений. Его можно вплести в основной план работ.
Если команда и руководство не желает обсуждать проблемные части проекта, то это серьезное основание из такого проекта выходить.

Если вы все же оказались на поддержке такого проекта, а предыдущие разработчики, радостно хихикая, убежали пилить средующий, то можно выбрать следующую тактику:

  • Старый модуль с избыточной ответственностью исключается из разработки нового функционала. Только поддержка.
  • Из него выделяются участки кода, которые можно использовать как отдельные маленькие модули. Код старого модуля не изменяется. Модули создаются, частично или полностью дублируя старый функционал, но более мелкие и выполняющие только локальные задачи.
  • Новый функционал создается с зависимостями от новых модулей. Это приводит к избыточности, но так как общая сложность фронта работ снижается, на его поддержку и дальнейшую разработку можно выделить специалиста более низкой квалификации, разгрузив опытных участников команды.
  • Старый, работающий функционал не нужно трогать. При естественном развитии продукта рано или поздно встанет задача, которая потребует кардинального пересмотра какой-то давно написанной части продукта. И это можно будет сделать с учетом новых, уже устоявшихся архитектурных решений.
На рисунке слева представлена, сильно упрощенная, схема взаимодействия большого модуля с тремя интерфейсами, зависимыми от него. Ввиду высокой сложности поддержки больших модулей, нередки ситуации, когда большая часть функций модуля, вместо универсальности, обеспечивает работоспособность лишь какого-то одного интерфейса. На рисунке справа показан пример, того как этот модуль можно разбить. И наоборот. Если функционал слишком специфичен для интерфейса, нет смысла оформлять его отдельным модулем.
06 мар.2018