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

минимум наклонная черта (' / ') и ПУСТОЙ УКАЗАТЕЛЬ ('\0')

11
задан Lundin 28 September 2015 в 08:57
поделиться

18 ответов

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

39
ответ дан 3 December 2019 в 00:37
поделиться

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

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

Если вы четко указываете проблему, которую решаете,

-1
ответ дан 3 December 2019 в 00:37
поделиться

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

0
ответ дан 3 December 2019 в 00:37
поделиться

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

0
ответ дан 3 December 2019 в 00:37
поделиться

Довольно часто я использую "

0
ответ дан 3 December 2019 в 00:37
поделиться

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

Когда вам приходит в голову сделать подобное изменение, спросите себя: «Если бы я сделал клиент понимает, в чем проблема, захочет ли он, чтобы я потратил на это время? ». Гораздо чаще ответ отрицательный. Зачем им все равно, работает ли это?

0
ответ дан 3 December 2019 в 00:37
поделиться

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

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

0
ответ дан 3 December 2019 в 00:37
поделиться

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

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

1
ответ дан 3 December 2019 в 00:37
поделиться

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

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

1
ответ дан 3 December 2019 в 00:37
поделиться

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

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

2
ответ дан 3 December 2019 в 00:37
поделиться

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

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

3
ответ дан 3 December 2019 в 00:37
поделиться

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

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

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

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

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

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

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

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

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

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

5
ответ дан 3 December 2019 в 00:37
поделиться

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

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

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

7
ответ дан 3 December 2019 в 00:37
поделиться

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

7
ответ дан 3 December 2019 в 00:37
поделиться

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

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

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

12
ответ дан 3 December 2019 в 00:37
поделиться

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

8
ответ дан 3 December 2019 в 00:37
поделиться

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

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

За комментарий:

24
ответ дан 3 December 2019 в 00:37
поделиться

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

7
ответ дан 3 December 2019 в 00:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: