Запись большого [закрытого] программного обеспечения

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

Я не согласен с #1, потому что большинству великих программ требуется несколько крупных итераций, чтобы стать действительно великими. Единственный другой способ достичь №1 (с первой попытки) - это скопировать какую-то другую уже великую программу. Но чтобы придумать что-то новое и уникальное (как я сделал с ClipMate в 1991 году), вы прилагаете максимум усилий, а затем выпускаете его в свет, чтобы посмотреть, что скажут о нем покупатели. Через повторяющиеся циклы переоценки продукта в результате участия и взаимодействия с клиентами вы в конечном итоге получаете отличное программное обеспечение".

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

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

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

Отличное программное обеспечение основано на хорошем дизайне и чистом программировании с одобренным шаблоном проектирования (MVC, компонент процесса ...).

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

Что касается двух других пунктов, они кажутся немного запутанными. Избегание дублирования является принципом проектирования, но только одним из многих. Зачем выделять его для особого рассмотрения? Вместо (скажем) Программирование на интерфейсы? Или Скажите, не спрашивайте? Или Избегайте разбитых окон?

Хм...

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

Я обычно начинаю с объектно-ориентированного дизайна. Это должен быть довольно быстрый «грязный» метод, чтобы не нуждаться в №2 и №3. Проблема в том, чтобы не передозировать ими.