Прихоти заказчика и структура приложения
От: Amon-RA  
Дата: 18.11.03 13:37
Оценка:
Вот поскажите как быть.
Ситуёвина такая. Есть заказчик. Когда-то конкретно поставил задачу отображения данных в окне. Идет дофига всякой обработки и визуализации. Но все крутится вокруг отображения этих данных. Было сделано много классов, завязанных на окне с видом (не Doc/View). ОК. Все нормально. "А давайте-ка мы еще другой вид информации отображать будем"-сказал заказчик. ОК. Начали приделывать диалоги, которые обращаются к данным. Но чем больше диалогов, тем кривее стало все работать. Стали переделывать под Закладки. ОК. Все работает. "А давай-те, чтобы другой файл можно было зачитывать.". И все заново — перелопачивание структуры приложения.
Только не надо ругать и говорить, что нормальные люди так не пишут. Но невозможно предусмотреть все прихоти заказчика. Как же организовывать структуры и классы, чтобы в дальнейшем было как можно меньше переделок при любой прихоти заказчика. Поделитесь опытом.
Спасибо.
Re: Прихоти заказчика и структура приложения
От: Kh_Oleg  
Дата: 18.11.03 14:05
Оценка: 1 (1) +1
Здравствуйте, Amon-RA, Вы писали:

AR>Вот поскажите как быть.

AR>Ситуёвина такая. Есть заказчик. Когда-то конкретно поставил задачу отображения данных в окне. Идет дофига всякой обработки и визуализации. Но все крутится вокруг отображения этих данных. Было сделано много классов, завязанных на окне с видом (не Doc/View). ОК. Все нормально. "А давайте-ка мы еще другой вид информации отображать будем"-сказал заказчик. ОК. Начали приделывать диалоги, которые обращаются к данным. Но чем больше диалогов, тем кривее стало все работать. Стали переделывать под Закладки. ОК. Все работает. "А давай-те, чтобы другой файл можно было зачитывать.". И все заново — перелопачивание структуры приложения.
AR>Только не надо ругать и говорить, что нормальные люди так не пишут. Но невозможно предусмотреть все прихоти заказчика. Как же организовывать структуры и классы, чтобы в дальнейшем было как можно меньше переделок при любой прихоти заказчика. Поделитесь опытом.
AR>Спасибо.

Ну тут можно сказать следующее:
1. Я никогда не считаю заказчиков глупыми, но реализовывать КАЖДУЮ прихоть тоже не всегда правильно. Иногда случается так, что заказчик сам не знает, как сделать лучше. Тогда лучше самому предложить свое решение.
2. Насчет перелопачивания. Систему надо всегда развивать (я не сказал проектировать) так, чтобы она всегда была расширяема. Все прихоти предусмотреть невозможно, просто надо идти на шаг впереди заказчика, предвосхищая то, что он может захотеть иметь в системе. Ну и, естесвенно, наладить с заказчиком нормальный диалог, когда общение будет на в стиле: "Сделай так, как я сказал", а "Давай подумаем, как лучше решить такую-то проблему".
Я бы сказал, что нужно поставить себя на место заказчика и постараться понять что ему нужно, а не ждать пока об этом явно попросят.

AR> Но чем больше диалогов, тем кривее стало все работать.

Это говорит о том, что настало время пересмотра архитектуры системы, рефакторига, то бишь.
Re: Прихоти заказчика и структура приложения
От: airatsa Россия  
Дата: 18.11.03 15:10
Оценка: 1 (1) +1
Здравствуйте, Amon-RA, Вы писали:

AR>Вот поскажите как быть.

AR>Ситуёвина такая. Есть заказчик. Когда-то конкретно поставил задачу отображения данных в окне. Идет дофига всякой обработки и визуализации. Но все крутится вокруг отображения этих данных. Было сделано много классов, завязанных на окне с видом (не Doc/View). ОК. Все нормально. "А давайте-ка мы еще другой вид информации отображать будем"-сказал заказчик. ОК. Начали приделывать диалоги, которые обращаются к данным. Но чем больше диалогов, тем кривее стало все работать. Стали переделывать под Закладки. ОК. Все работает. "А давай-те, чтобы другой файл можно было зачитывать.". И все заново — перелопачивание структуры приложения.
AR>Только не надо ругать и говорить, что нормальные люди так не пишут. Но невозможно предусмотреть все прихоти заказчика. Как же организовывать структуры и классы, чтобы в дальнейшем было как можно меньше переделок при любой прихоти заказчика. Поделитесь опытом.
AR>Спасибо.

Не очень понятно, где именно баги — в обработке данных или в GUI. На мой взгляд, программа должна состоять из двух частей.
1. Ядро, которое представляет предметную область приложения, т.е. отвечает за данные.
2. Внешние интерфейсы — все, что отвечает за ввод-вывод, в т.ч. GUI и всевозможный импорт/экспорт.

Требования к ядру, т.е. к предметной области, нужно тщательно выяснить на этапе проектирования и дать понять заказчику, что все существенные изменения ядра — по сути, разработка новой программы (или новой версии, как минимум). И требовать на это время и деньги.

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

Этакий клиент-сервер в миниатюре.
Re: Прихоти заказчика и структура приложения
От: jaj  
Дата: 19.11.03 12:47
Оценка:
Здравствуйте, Amon-RA, Вы писали:

AR>Вот поскажите как быть.


Есть хорошая книга: "Приемы объектно-ориентированного программирования. Паттерны проектирования" Э. Гамма.
Лично мне она сильно помогла.
... << RSDN@Home 1.1.0 stable >>
Re[2]: Прихоти заказчика и структура приложения
От: Артем1 Россия  
Дата: 19.11.03 13:45
Оценка:
Здравствуйте, jaj, Вы писали:

jaj>Есть хорошая книга: "Приемы объектно-ориентированного программирования. Паттерны проектирования" Э. Гамма.

jaj>Лично мне она сильно помогла.

А в электронном виде нету этой книги? Хотя-бы пару глав? Для оценки
Re: Прихоти заказчика и структура приложения
От: Igor Trofimov  
Дата: 19.11.03 14:36
Оценка: 8 (2)
Вообще знакомая проблема. Хоть как-то ее можно обуздать более формальным взаимодействием с заказчиком.
Хочет дополнительную фичу — оформляйте дополнение к ТЗ, оценивайте затраченное время и, как следствие — стоимость Причем так, чтобы вам по-прежнему было выгодно всем этим заниматься. Только тогда заказчик будет думать над тем, что ему действительно необходимо.
Re[3]: Прихоти заказчика и структура приложения
От: jaj  
Дата: 20.11.03 12:00
Оценка:
Здравствуйте, Артем1, Вы писали:

А>Здравствуйте, jaj, Вы писали:


jaj>>Есть хорошая книга: "Приемы объектно-ориентированного программирования. Паттерны проектирования" Э. Гамма.

jaj>>Лично мне она сильно помогла.

А>А в электронном виде нету этой книги? Хотя-бы пару глав? Для оценки

Нету В ней описан ряд паттернов, которые моно применять как на стадии проектирования, так и для исправления ситуации, подобной описанной выше.
... << RSDN@Home 1.1.0 stable >>
Re[3]: Прихоти заказчика и структура приложения
От: s.ts  
Дата: 21.11.03 08:19
Оценка:
Здравствуйте, Артем1, Вы писали:

А>Здравствуйте, jaj, Вы писали:


jaj>>Есть хорошая книга: "Приемы объектно-ориентированного программирования. Паттерны проектирования" Э. Гамма.

jaj>>Лично мне она сильно помогла.

А>А в электронном виде нету этой книги? Хотя-бы пару глав? Для оценки


покупай — не ошибешься
Re[4]: Прихоти заказчика и структура приложения
От: Артем1 Россия  
Дата: 21.11.03 09:06
Оценка:
Здравствуйте, s.ts, Вы писали:

ST>>покупай — не ошибешься

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

А примеры в ней на чем?
Re[2]: Прихоти заказчика и структура приложения
От: Blazkowicz Россия  
Дата: 29.11.03 11:55
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:

iT>Вообще знакомая проблема. Хоть как-то ее можно обуздать более формальным взаимодействием с заказчиком.

iT>Хочет дополнительную фичу — оформляйте дополнение к ТЗ, оценивайте затраченное время и, как следствие — стоимость Причем так, чтобы вам по-прежнему было выгодно всем этим заниматься. Только тогда заказчик будет думать над тем, что ему действительно необходимо.

При такой постановке вопроса можно легко потерять заказчика. Он просто найдет фирму в которой у него не будут требовать ТЗ. А будут делать легко модифицируемый код.

ИМХО проблемы описываемые Amon-RA возникают при элементарном не следовании идеи MVC. У нас, например, точно такие же заказчики с точно такими же регулярными требованиями новых фич. И нормально написанные проекты при этом нормально выростают из прототипов в законченые программные продукты.

Так что не стоит на заказчика пенять, коль...
Re[3]: Прихоти заказчика и структура приложения
От: Igor Trofimov  
Дата: 29.11.03 14:05
Оценка:
B>При такой постановке вопроса можно легко потерять заказчика. Он просто найдет фирму в которой у него не будут требовать ТЗ.

Все может быть.

B>А будут делать легко модифицируемый код.


Вообще-то об этом речь не шла, насколько я понимаю. Разработчку не сложно все в сотый раз взять и переделать.
Но если эти новые желания заказчика раз за разом по чуть-чуть увеличивают срок проекта, а денег заказчик больше платит не собирается — то наверное все-таки есть повод задуматься, как считаешь?
Re[3]: Прихоти заказчика и структура приложения
От: Кирилл Осенков Украина
Дата: 29.11.03 23:06
Оценка:
А>А в электронном виде нету этой книги? Хотя-бы пару глав? Для оценки
Погляди здесь на RSDN в списке ссылок (меню Ресурсы) — Object Oriented
Re[5]: Прихоти заказчика и структура приложения
От: Зверёк Харьковский  
Дата: 30.11.03 11:37
Оценка:
Здравствуйте, Артем1, Вы писали:

А>Здравствуйте, s.ts, Вы писали:


ST>>>покупай — не ошибешься

А>Точно?
точно-точно. третий глаз открывается

А>А примеры в ней на чем?

на Сях с плюсами
А ты думал на чем? На ассемблере машины MIX?
FAQ — це мiй ай-кью!
Re: Прихоти заказчика и структура приложения
От: Framer  
Дата: 13.02.04 09:40
Оценка:
Здравствуйте, Amon-RA, Вы писали:

AR>Вот поскажите как быть.

AR>Ситуёвина такая. Есть заказчик. Когда-то конкретно поставил задачу отображения данных в окне. Идет дофига всякой обработки и визуализации. Но все крутится вокруг отображения этих данных. Было сделано много классов, завязанных на окне с видом (не Doc/View). ОК. Все нормально. "А давайте-ка мы еще другой вид информации отображать будем"-сказал заказчик. ОК. Начали приделывать диалоги, которые обращаются к данным. Но чем больше диалогов, тем кривее стало все работать. Стали переделывать под Закладки. ОК. Все работает. "А давай-те, чтобы другой файл можно было зачитывать.". И все заново — перелопачивание структуры приложения.
AR>Только не надо ругать и говорить, что нормальные люди так не пишут. Но невозможно предусмотреть все прихоти заказчика. Как же организовывать структуры и классы, чтобы в дальнейшем было как можно меньше переделок при любой прихоти заказчика. Поделитесь опытом.
AR>Спасибо.
Есть способ RUP называется. Заказчик подписывает кучу документов детально описывающих свойства и функционал будущей системы.
А затем при любом изменении производится доп согласование и проплата деньгами.
... << RSDN@Home 1.1 beta 1 >>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.