Написание Великого программного обеспечения

Я сейчас читаю Объектный ориентированный анализ и дизайн главы First. В книге говорится, что написать большое программное обеспечение (то есть программное обеспечение, которое хорошо продуманные, хорошо закодированы, просты в обслуживании, повторное использование и расширяющие) вам нужно сделать три вещи:Написание Великого программного обеспечения

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

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

источник

2010-05-08 Anthony

Я бы большинство людей не делал 1), а затем делал столько же 2 и 3, пока там босс не ударил там ** за не соблюдение крайнего срока !!! –

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

Я прочитал эту книгу. Я думаю, что во всем есть некоторая неверная интерпретация.

Во-первых, убедитесь, что программное обеспечение делает все, что клиент хочет, чтобы это сделать

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

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

Используйте шаблон дизайна.

источник

2010-05-08 14:37:57 jimueller

+1 Большое спасибо за ваш ответ jrm82. Ваш первый шаг имеет смысл для меня, но в главе 1, стр. 14, в книге говорится: «Как только ваше программное обеспечение работает, вы можете искать любой дублированный код, который мог бы проскользнуть, и убедитесь, что вы используете хорошие методы программирования OO ». Я предположил, что когда они говорят, что «программное обеспечение работает», они подразумевают, что буквально, значение, скомпилировано и работает. Во-вторых, не следует ли делать шаг 3 до 2? Я имею в виду, если вы делаете OO в рамках шаблона? – Anthony

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

источник

2010-05-08 12:41:53

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

Подождите, вы говорите * только * способ получить программное обеспечение, чтобы сделать то, что ему нужно для этого, - это скопировать какую-нибудь другую полезную программу? Логично, что это говорит о том, что большое программное обеспечение никогда не существовало (и я не говорю, что вы там не правы), так как отличное программное обеспечение не может быть создано без копирования уже отличного программного обеспечения. – MusiGenesis

@DeadMG, конечно, согласен. Я хочу не вкладывать слишком много средств в то, что хотят клиенты, а точнее, думать, что они хотят. –

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

источник

2010-05-08 12:45:53

+1 Всегда начинайте с твердой теоретической базы - это _allways_ дает лучшие конкретные результаты. –

Вот что я подумал. Я никогда не читал книгу «Начальный старт», но я не могу поверить, что они выступают за то, чтобы бросить туда все, * затем * сделать объектно-ориентированное, а затем * сделать материал ООП соответствующим шаблонам дизайна. – MusiGenesis

+1 Спасибо за ответ Нейл. Я должен был упомянуть, что я только начал читать главу 1, и что это мой первый раз, когда я читаю любую из книг Head First. Однако, перечитав три шага, упомянутые выше, я не мог не опубликовать этот вопрос, потому что я не мог себе представить, как писать программу, которая отвечает всем требованиям клиентов, после чего я бы изменил код, чтобы улучшить его, включив соответствующий дизайн после этого! Теперь, чтобы быть справедливым, как я уже сказал, я только на первой главе, и книга нацелена на новичков, поэтому я подозреваю, что позже в книге они могут пересмотреть эти шаги. – Anthony

Обычно я начинаю с объектно-ориентированного дизайна. Это должно быть довольно быстро грязным/взломать, чтобы не требовать № 2 и № 3. Беда в том, чтобы не передозировать их.

источник

2010-05-08 12:46:13 Puppy

+1 От того, что я читал до сих пор, фокус книги - OOD. В любом случае, я думаю, что в качестве новичков они ожидают, что мы создадим дублирующий код здесь и там, вот, на втором этапе, я думаю. – Anthony

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

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

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

источник

2010-05-08 12:57:20 mdma

+1 Да, они определенно должны были сосредоточиться на том, что клиент хочет в первую очередь и доставить на все, что он хочет, иначе программное обеспечение не будет «отличным». Но я должен признаться, оставив шаблон дизайна для шага 3 меня обеспокоенным, но, честно говоря, я только на первой главе, и я подозреваю, что в этот список будут внесены улучшения в пользу читателей, поскольку читатель перейдет к главе 10. – Anthony

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

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

Хммм ...

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

источник

2010-05-08 13:03:07 APC

Почему решение OO не было бы самым простым? –

+1 Спасибо за полезный ответ APC. Книга нацелена на новичков на OOAD, но позже я подозреваю, что они пересмотрят это как учебный опыт для читателя, но я точно не знаю, пока не закончу его. – Anthony

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

источник

2010-05-08 13:16:54

Написание Великого программного обеспечения

ответ

Смежные вопросы