Когда следует устранить сложность?

Преждевременное введение сложности путем реализации шаблонов проектирования до того, как они необходимы, не является хорошей практикой.

Но если вы будете следовать всем (или даже большинству) принципам SOLID и использовать общие шаблоны проектирования, вы внесете некоторую сложность, так как функции и требования будут добавлены или изменены, чтобы сохранить ваш дизайн как обслуживаемый и гибкий по мере необходимости.

Однако, когда эта сложность введена и работает как чемпион, когда вы ее убрали?

Пример. У меня есть заявление, написанное для клиента. При первоначальном создании там, где несколько способов повышения ставок для сотрудников. Я использовал шаблон стратегии и фабрику, чтобы весь процесс был красивым и чистым. Со временем определенные методы повышения были добавлены или удалены владельцем приложения.

Время идет, и новый владелец вступает во владение. Этот новый владелец тверд, у него все просто и у него есть только один способ поднять ставку.

Сложность, необходимая для паттерна стратегии, больше не нужна. Если бы я где-то кодировал это из требований, как они есть сейчас, я бы не стал вводить эту дополнительную сложность (но позаботился бы о том, чтобы я мог представить ее практически без каких-либо усилий в случае необходимости).

Так я должен удалить реализацию стратегии сейчас? Я не думаю, что этот новый владелец когда-либо изменит способ повышения. Но само приложение продемонстрировало, что это может произойти.

Конечно, это только один пример в приложении, где новый владелец вступает во владение и упрощает многие процессы. Я мог бы удалить десятки классов, интерфейсов и фабрик и сделать все приложение намного проще. Обратите внимание, что текущая реализация работает просто отлично, и владелец доволен этим (и удивлен и даже счастлив, что я смог осуществить ее изменения так быстро из-за обсуждаемой сложности).

Я признаю, что небольшая часть этого сомнения заключается в том, что, скорее всего, новый владелец больше не будет меня использовать. Мне действительно все равно, что кто-то другой возьмет это на себя, поскольку это не было генератором большого дохода.

Но я забочусь о 2 (связанных) вещах

1. Я немного беспокоюсь о том, что новый сопровождающий должен будет подумать немного усерднее, пытаясь понять код. Сложность - это сложность, и я не хочу злить психоманьяка, преследующего меня.

2. Но еще больше я беспокоюсь о том, что конкурент видит эту сложность и думает, что я просто внедряю шаблоны проектирования, чтобы затрачивать время на работу. Затем распространять этот слух, чтобы навредить другим моим делам. (Я слышал это упомянутое.)

Так...

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

Даже если на вышеприведенный вопрос обычно отвечают «нет», имеет ли смысл убрать эту «ненужную» сложность, если передать проект конкуренту (или незнакомцу)?

В некотором смысле, я думаю, что это в значительной степени бизнес-решение и не обязательно основано на самом коде. Некоторые вещи для рассмотрения:

• Вам платят за внесение изменений?
• Работает ли код в настоящее время так, как ожидается?
• Есть ли какие-либо проблемы безопасности или производительности с кодом как есть?
• Перевешивает ли сумма технического долга стоимость его исправления?
• Что реально произойдет, если вы оставите код как есть?
• Какие будущие проблемы могут возникнуть с рефакторингом или без него?
• Какую ответственность несет кодекс для вас и вашего бизнеса?

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

Короче говоря, проведите анализ затрат и выгод и оценку рисков по обоим путям и выберите наиболее безопасный, эффективный и наиболее прибыльный способ действий.

Разве удаление этого кода и его замена чем-то простым для будущей простоты кодирования - это функция, которую клиент должен рассмотреть и оплатить?

У вас может быть что-то полезное, чему другой разработчик мог бы поучиться, но шансы найти приложение другого клиента для подключения к нему, маловероятны.

Сплетни о коде конкурента - это не то, что вы можете предотвратить. Они будут выглядеть глупо, пытаясь нанять клиентов негативно.

Распространенное высказывание гласит: «Если оно не сломано, не чините его».

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

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

Прежде всего, если приложение уже однажды было передано новому владельцу, это может произойти снова. И следующий владелец может снова начать использовать ту сложность, от которой сейчас нет пользы.

Кроме того, нетривиальные изменения в рабочем коде всегда сопряжены с риском, поэтому (как отмечали другие) клиент должен согласиться (и заплатить) за них. Если текущая «дополнительная» сложность не вызывает каких-либо заметных, измеримых недостатков (таких как проблемы с производительностью), нет веских причин для ее устранения.

(Потенциальные) клиенты, которые (не) нанимают вас на основании исключительно слухов конкурентов, ИМХО не стоит иметь в любом случае, если только вам не нужен отчаянный доход. У вас есть веские и логичные причины, по которым вы внедрили приложение так, как вы это сделали, и любой серьезный клиент, вероятно, это поймет. Тот, кто не (или даже не удосужился вас спросить), скорее всего, доставит вам больше хлопот по пути, чем работа в любом случае.

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

Нет.

Даже если на приведенный выше вопрос обычно отвечают «нет», разумно ли устранить эту «ненужную» сложность, если передать проект конкуренту (или незнакомцу)

Нет. Зачем тратить свое время на исправление таких работ с низким приоритетом? Никакого вреда для кода, оставшегося там.

Что касается вашего вопроса: когда следует устранить сложность?

Мое мнение: если оно не сломано, не чините его .

Чтобы иметь возможность удалить сложность, должно быть верно следующее:

1. Удаленная часть должна быть независимой от программы. Если есть какие-либо зависимости от окружающей программы от рассматриваемого кода, простое удаление сложности не будет работать
2. К сожалению, если это выглядит как сложность, то весьма вероятно, что части не являются независимыми, и зависимости будут нарушать вашу программу, когда вы удаляете часть
3. Удаление всех зависимостей займет время, поэтому необходимо учитывать время, когда вы оцените, стоит ли операция
4. Большую часть времени это не стоит усилий, но вы просто решите не заставлять новый код использовать старый

Я думаю, что здесь есть что-то большее ... Масштабируемость

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

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

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

Там есть усилия и риск, чтобы удалить сложность. Если это выше, чем дополнительные усилия и риск обслуживания слишком сложного кода, то вы сохраните его. В противном случае вы удалите его. Однако трудно оценить эти риски.

Я хотел бы добавить, что вы можете снизить риск более сложного обслуживания, документировав, почему вы в первую очередь использовали код шаблона проектирования в коде. Я лично считаю, что любой шаблон проектирования должен быть прослежен до явного требования (функционального или нефункционального).

Даже если на вышеприведенный вопрос обычно отвечают «нет», имеет ли смысл убрать эту «ненужную» сложность, если передать проект конкуренту (или незнакомцу)?

Ваш сценарий отклонения от соревнования за дополнительные часы - это как раз та причина, по которой вам следует документировать сложность. Если вы документируете и обосновываете (с конкретным требованием заказчика) использование какого-либо паттерна, то вы застрахованы. Если вы не можете обосновать шаблон с требованием клиента, то это выглядит как чрезмерный дизайн или шаблонит.

Если требования изменятся, то вы можете оправдать отказ от него из-за риска того, что вы можете взломать код (или из-за объема работ по хирургическому удалению шаблона).

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

То есть, ваше требование поддерживать различные алгоритмы для определения рейза является существенной сложностью (часть проблемы, которую нужно решить). Обслуживание Вашего кода стало проще по узору стратегии, но жестко , если / то альтернатива стратегии будет продолжать работать. Я делал упражнения на магистерских курсах, где студенты находят возможности применять Стратегию в проектах с открытым исходным кодом. Сложность не обязательно лучше / хуже при применении Стратегии (потому что это существенная сложность). Иногда понять стратегию может быть еще сложнее, потому что код разбит на несколько классов с полиморфизмом, а не на один большой блок if / then / else.

В идеале шаблон работает, когда его преимущества перевешивают стоимость его недостатков. Опять же, количественно оценить эти вещи сложно. Часто шаблон делает разработчика счастливым (не только потому, что он облегчает добавление новой стратегии повышения, но и дает разработчикам теплые размышления о том, что шаблон был применен). Сложно показать клиентам, как это им выгодно.

Клиент не заботится и даже не понимает деталей. В случае, когда новый владелец применяет KISS в своих процессах, именно она уменьшает существенную сложность, что также должно повлиять на программное решение.