Шаблон стратегии (шаблон дизайна) менее полезен, когда изменение непредвиденно?

Question

Основан ли шаблон стратегии на факте изменения программного обеспечения?

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

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

3) То же самое относится и к программированию по контракту - на 2 месяца или 3 месяца. Не будет ли какой-нибудь программист или предыдущий программист на работе просто игнорировать удобство обслуживания, чтобы сделать это как можно скорее? Неужели менеджеры действительно заботятся о том, что проект на 100% функционален в соответствии со спецификацией, имеет ли он также возможность сопровождения?

Answer 1

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

У Джеффа Этвуда есть предложения по KISS и YAGNI .

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

Вы говорите о разных вещах.

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

ЕСЛИ известно, что изменение произойдет, но вы на самом деле не имеете ни малейшего представления о том, какую форму он примет, тогда попытка излишнего дизайна станет препятствием. Если у менеджера есть возможность получить его в течение двух дней, но вы тратите 2 недели, пытаясь превратить его в шаблон стратегии, тогда неудивительно, что он злится.

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

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

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