Когда мне нужно прекратить использование шаблонов проектирования?

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

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

Ответ 1

Если код работает и не требует внимания - не тратьте время/деньги на его обновление. Пока это не будет финансово - необходимо сделать это. Просто убедитесь, что весь ваш новый код превосходный, и медленно удаляйте эту проблему с этого момента.

Ответ 2

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

Представьте, что ваш босс приглашает вас в свой офис и спрашивает вас: "Почему вы внесли это изменение, когда не было проблем с кодом?" У вас будет хороший ответ?

За комментарий: Я предоставляю некоторые полезные ресурсы для стоимости качества (COQ) и стоимости некачественного (CNQ) в этом SO-ответе.

Ответ 3

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

Редактирование, чтобы добавить: ОК, пришлось пойти и получить книгу, чтобы найти точную цитату. Это в конце введения на стр. 31, по крайней мере, в издании, которое у меня есть:

Образцы дизайна не должны применяться без разбора. Часто они достигают гибкость и введение дополнительных уровней косвенности, и это может усложнить дизайн и/или стоить вам представление. Схема проектирования должна применяется только тогда, когда гибкость это действительно необходимо.

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

Если бы ты был моим коллегой, я тоже схожу с ума. Шаблоны проектирования - это всего лишь некоторые общие идеи о том, как решать проблемы. Это не слово Господа, посланное с горной вершины на глиняных табличках.

Ответ 8

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

Похоже, у вас есть классические признаки наркомании, теперь настало время отступить и изучить вашу жизнь кодирования и спросить такие вещи, как это влияет на моих коллег? Из-за моей привычки страдает моя компания?

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

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

Наконец, вы можете попробовать поэкспериментировать, полностью отпустив и посмотрев, какие естественные "шаблоны" появляются из написанного вами кода, а не пытались заставить код адаптироваться к вашим представлениям о том, как это должно быть. Вы можете открыть свои собственные "шаблоны" таким образом.

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

Ответ 9

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

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

Ответ 10

для личных проектов, выбейте себя.

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

Ответ 11

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

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

Ответ 12

Джоэл Спольский обсудил это довольно разумно на своем блоге.

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

Ответ 13

Я иду с методом "деньги". Переписывание существующего кода оплачивает деньги вашего работодателя (ваша зарплата и т.д.). Можете ли вы честно сказать, что ваш перевод будет стоить вашему работодателю меньше, чем оставить его таким, каким он есть? По моему опыту, ответ почти всегда "нет".

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

Ответ 14

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

Когда вам придётся сделать такое изменение, спросите себя: "Если бы я заставил клиента понять связанные с этим проблемы, он бы хотел, чтобы я потратил на это время?". Гораздо чаще, чем нет, ответ - нет. Почему им все равно, если это работает?

Ответ 15

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

Ответ 16

Довольно часто я нахожу себя "всегда оставляю кусок кода в лучшем состоянии, чем тот, который вы нашли".

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

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

И затем, в конце концов, у вас есть лучшее из обоих миров... один счастливый клиент и одна счастливая кодовая база.

Ответ 17

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

Ответ 18

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

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

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