Как вы пишете ПО?

← →
Ega23 © (2006-02-07 13:53) [0]

Сначала реализуете функциональность, тестируете, и только потом "оборачиваете" красивым GUI? Или делаете сразу?

← →
Sergey13 © (2006-02-07 13:57) [1]

А какой он - "красивый GUI"? 8-)
Я лично предпочитаю стандартный.

← →
Crem (2006-02-07 13:57) [2]

> Ega23 © (07.02.06 13:53)

ООП оно придумано не для того чтобы книги писать. А чтобы оборачивание было оборачиванием. Функциональное - оно было функциональным без оборачивания. И тестирование где-то тут.
Если ООП поставлено на уровне неплохом, то все вопросы на уровне сабжа - просто отваливаются.
Да и то вприведенной постановке - это уровень начинающих или слабых компаний.

← →
Юрий Зотов © (2006-02-07 14:03) [3]

Сначала проектирование (по ходу уточняются требования к функциональности).

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

Потом прикладная часть (по ходу уточняется GUI - где и какие вообще нужны контролы).

Потом дизайн.

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

← →
Ega23 © (2006-02-07 14:04) [4]

> ООП оно придумано не для того чтобы книги писать. А чтобы
> оборачивание было оборачиванием. Функциональное - оно было
> функциональным без оборачивания. И тестирование где-то тут.
>
> Если ООП поставлено на уровне неплохом, то все вопросы на
> уровне сабжа - просто отваливаются.
> Да и то вприведенной постановке - это уровень начинающих
> или слабых компаний.
>

Ничего не понял.

← →
Crem (2006-02-07 14:07) [5]

> Ega23 © (07.02.06 14:04) [4]

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

← →
Ega23 © (2006-02-07 14:08) [6]

> Юрий Зотов © (07.02.06 14:03) [3]

Ну, в общем, у нас то же самое.
Кстати, Юрий, а дизайном сами занимаетесь? Или сторонние люди?
Просто мы тут с коллегами вообще замахнулись на то, что пользователь сам может полностью поменять дизайн продукта. Т.е. мы предоставляем несколько стандартных шаблонов + "конструктор внешнего вида", а дальше заказчик сам уже думает - пользоваться готовым или самому что-нибудь "навертеть".

← →
Crem (2006-02-07 14:10) [7]

> Ega23 © (07.02.06 14:08) [6]

Вы с Аксаптой не работали? Многое потеряли.

← →
Ega23 © (2006-02-07 14:12) [8]

> Верю. Если все с первого раза понимать, то и рождаться не
> стоит.
> Проектировать надо просто. И ООП в этом сильно помогает.
>
> И если вы чего-то не поняли. кричать об этом не обязательно.
> потому что кто в конечном итоге невнятный - еще под вопросом.
>
>

Не откажет ли Многоуважаемый Господин Гуру в любезности пояснить ничтожному: каким образом понимание концепции объектно-ориентированого программирования помогает в создании удобного пользовательского интерфейса?

← →
evvcom © (2006-02-07 14:12) [9]

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

Скины? Видать у вас времени свободного навалом. Я функционал не успеваю делать.

← →
Rouse_ © (2006-02-07 14:14) [10]

Сначала проектировка. Потом разработка отдельных компонентов системы, как визуальных так и не очень :). Потом начинается сборка.
ГУИ слегка накидываю вначале, чтобы было удобно тестировать внутренности, ну а когда ядрышко отточено - начинаю прикручивать всякие там финтифлюшки :)

← →
Crem (2006-02-07 14:14) [11]

> Ega23 © (07.02.06 14:12) [8]

Элементарно. Принцип простой. Мухи отдельно от котлет. Про что вам и прописал Юрий Зотов. Его вы вроде как поняли. А меня вроде как нет.

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

Будь проще. Не хами.

← →
ANB © (2006-02-07 14:15) [12]

> Скины?

Думаю, это не скины. А именно конструктор. Видел такие системы (та же 1С). Как правило, пользователи все равно пользуются только готовым, а все доделки заказывают.

← →
Ega23 © (2006-02-07 14:15) [13]

> Скины? Видать у вас времени свободного навалом. Я функционал
> не успеваю делать.

Нет, не скины. Скажем, нечто вроде IDE у Delphi - хочешь - вот тебе Object Inspector, хочешь - вот тут же и Class Browser, "придоканый" к Object Inspector и т.п.

← →
Ega23 © (2006-02-07 14:17) [14]

> Будь проще. Не хами.

"Не говорите мне, что делать, и я не буду говорить Вам, куда идти" (с)

← →
Crem (2006-02-07 14:19) [15]

> Ega23 © (07.02.06 14:17) [14]

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

← →
Ega23 © (2006-02-07 14:22) [16]

> Rouse_ © (07.02.06 14:14) [10]
>
> Сначала проектировка. Потом разработка отдельных компонентов
> системы, как визуальных так и не очень :). Потом начинается
> сборка.
> ГУИ слегка накидываю вначале, чтобы было удобно тестировать
> внутренности, ну а когда ядрышко отточено - начинаю прикручивать
> всякие там финтифлюшки :)

Ну вот в большей степени именно этот вопрос интересует. Допустим, знаю, что тут будет DBGrid лежать. На этапе написания функциональности это просто грид, смотрящий на какой-то там НД. А уже при докручивании GUI - всякие Column"ы с названиями, отцентровкой и т.п.

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

← →
Sandman29 © (2006-02-07 14:30) [17]

Ega23 © (07.02.06 14:22) [16]

А я наоборот предпочитаю. Вот и поспорили.

Оба правы :)
Делай так, как удобно в конкретном случае. Иногда отлаживать "ядро" легче, если есть удобный интерфейс, позволяющий выбирать параметры из комбобоксов, а не писать идентификаторы (параметры в методе сервера приложений) ручками.

← →
Eraser © (2006-02-07 14:32) [18]

Вообще Action"ы спасают..., т.к. необязательно для какой-то операции присутствие конкретного элемента интерфейса.

Вцелом получается как говорит Rouse_ © (07.02.06 14:14) [10].

← →
Ega23 © (2006-02-07 14:33) [19]

> Делай так, как удобно в конкретном случае. Иногда отлаживать
> "ядро" легче, если есть удобный интерфейс, позволяющий выбирать
> параметры из комбобоксов, а не писать идентификаторы (параметры
> в методе сервера приложений) ручками.
>

Безусловно легче. Но одно дело накидать комбиков, выставить им TabOrder и отлаживать функционал, а другое дело подбирать при этом полдня иконки, подбирать цвет и т.п.

← →
Ega23 © (2006-02-07 14:33) [20]

> Вообще Action"ы спасают..., т.к. необязательно для какой-
> то операции присутствие конкретного элемента интерфейса.
>

Угу. ActionList - убойная вестч.

← →
Юрий Зотов © (2006-02-07 14:35) [21]

> Ega23 © (07.02.06 14:08) [6]

> а дизайном сами занимаетесь?

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

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

Реализовано в мае 2000-го года (та самая "маленькая Delphi", о которой как-то уже рассказывал). Поддерживает как изменение пользователем внешнего вида форм (включая даже и главную форму), так и изменение им же прикладной функциональности - юзер пишет код обработчиков событий (на том же самом Object Pascal) и этот код исполняется.

← →
Sandman29 © (2006-02-07 14:37) [22]

Ega23 © (07.02.06 14:33) [19]

Иконки и цвета подбираются в самом конце. Точнее, перед созданием скриншотов для вставки в инструкцию по эксплуатации :)

← →
Crem (2006-02-07 14:40) [23]

Ну вот. Все к той же Аксапте и пришло. Принципиально нового - ничего.

← →
КиТаЯц © (2006-02-07 14:44) [24]

> Ega23 © (07.02.06 14:22) [16]
>
> ...
> Просто схватились тут с коллегой. У него стиль такой - пишет
> какой-нибудь диалог настройки справочной таблицы - так это
> у него всегда полностью законченный диалог. Со всеми выравниваниями,
> иконками, картинками, подсказками и прочим. А я наоборот
> предпочитаю. Вот и поспорили.
> И стало интересно, что коллеги по цеху об этом думают.

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

← →
iZEN © (2006-02-07 14:44) [25]

Если начинать разработку с модели и заканчивать UI, то получается уродливо.
Если начинать разработку с UI и заканчивать моделью, то получается узко, монолитно и нерасширяемо.

Поэтому принимается два потока, идущие навстречу друг другу: одновременно пишется модель и уточняется UI. Оба потока разработки постоянно взаимодействуют друг с другом, приходят к взаимной "утряске", взаимодополняют друг друга. Резонируют - вот подходящая метафора.

← →
Ega23 © (2006-02-07 14:49) [26]

> Ну вот. Все к той же Аксапте и пришло. Принципиально нового
> - ничего.

Да задолбало то, что один заказчик хочет видеть справа - дерево, слева - графику, а внизу - протокол событий. А другой хочет справа - графику, слева - дерево, а вот протокол событий - отдельной модальной формой.
И что, для каждого из заказчиков (а их не два и не десять) отдельный exe компилить?
Вот и сделали такой конструктор. В первую очередь для себя. Ну а уж потом идея появилась - а не выдать ли этот конструктор заказчику как отдельную фичу ПО? Хочет - пусть сам пользуется. Не хочет разбираться - мы за отдельную денюшку ему соберём так, как ему хочется.

← →
Курдль © (2006-02-07 14:49) [27]

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

Нам бы ваши проблемы :(

← →
Ega23 © (2006-02-07 14:52) [28]

> Нам бы ваши проблемы :(
>

См. [26] Причина там.

← →
Игорь Шевченко © (2006-02-07 15:01) [29]

← →
Ega23 © (2006-02-07 15:14) [30]

> Нам бы ваши проблемы
>

Ну, кому - как. Для нас это серьёзная проблема.

← →
seg (2006-02-07 15:15) [31]

Да задолбало то, что один заказчик хочет видеть справа - дерево, слева - графику, а внизу - протокол событий. А другой хочет справа - графику, слева - дерево, а вот протокол событий - отдельной модальной формой

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

← →
Gero © (2006-02-07 15:16) [32]

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

← →
seg (2006-02-07 15:17) [33]

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

Здравая мысль. Поддерживаю.

← →
Gero © (2006-02-07 15:21) [34]

> Нам бы ваши проблемы

Почему же, если заказчик готов платить за свои прихоти, то все замечательно.

← →
Fay © (2006-02-07 15:24) [35]

Заказчик, который платить не готов - это просто посторонний человек

← →
TStas © (2006-02-07 15:25) [36]

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

← →
ZeroDivide © (2006-02-07 15:27) [37]

> Как вы пишете ПО?
>
> Ega23 © (07.02.06 13:53)
>
> Сначала реализуете функциональность, тестируете, и только
> потом "оборачиваете" красивым GUI? Или делаете сразу?

GUI уже написан давно, этому весьма способствовала возможность визуального наследования форм :)

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

...repeat проектируем, пишем и тестируем until в экстремальном стиле... до 10 версий за день... Т.к. в этом случае заказчик получает все именно так как он хочет (правда очень часто, ему приходится объяснять, что ему будет удобнее "так", а не как в старой программе было... в последствии он ВСЕГДА доволен оказывается) и готовый продукт появляется гораздо быстрее.
Потом продукт отдается в отдел сопровождения... и совсем усё...

← →
seg (2006-02-07 15:31) [38]

Я бы по-другому ставил вопрос - Как получить от заказчика максимальную выгоду?

← →
Ega23 © (2006-02-07 15:42) [39]

>
> Это говорит о том, что заказчик сам не знает какой функционал
> ему нужен,
> но очень озабочен мелочами.

Отнюдь. Функционал описан соответствующим ГОСТ-ом. А вот интерфейс - нет. Есть некие стандарты на цвет (красный - "тревога", синий - "неисправность" и т.п.). Даже, скорее, не стандарты, а рекомендации.
И есть общие требования, типа
1. Оператор должен иметь возможность просмотра протокола тревожных событий
2. Администратор должен иметь возможность просмотра действий оператора

и т.п.

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

← →
ZeroDivide © (2006-02-07 15:42) [40]

> Да задолбало то, что один заказчик хочет видеть справа -
> дерево, слева - графику, а внизу - протокол событий. А
> другой хочет справа - графику, слева - дерево, а вот протокол
> событий - отдельной модальной формой.
> И что, для каждого из заказчиков (а их не два и не десять)
> отдельный exe компилить?
> Вот и сделали такой конструктор. В первую очередь для себя.
> Ну а уж потом идея появилась - а не выдать ли этот конструктор
> заказчику как отдельную фичу ПО? Хочет - пусть сам пользуется.
> Не хочет разбираться - мы за отдельную денюшку ему соберём
> так, как ему хочется.

Если ваш интерфейс, который вы РАЗРАБАТЫВАЛИ, действительно удобен, то сумейте это УБЕДИТЕЛЬНО ОБЪЯСНИТЬ и все... ни каких проблем.
Если заказчику не нравится зеленая кнопочка и он хочет ее видеть красной и это действительно не принципиально, то упирайтесь... имейте гордость в конце концов.
У нас один пользователь приципился, что обычные кнопки со стрелками навигации по набору данных, ему напоминают, как он выразился: "Это... че...? че... за магнитофон тут... вперед-назад-перемотка???". Ему ВНЯТНО объяснили, что так обычно выглядят кнопки навигации и мы придерживаемся такого стандарта... и во всех наших программах... и вообще в большинстве, они выглядят точно так же. Он уперся, мы уперлись... в итоге он программой пользуется и теперь, спустя значительное количество времени, он стал с нами согласен.

← →
evvcom © (2006-02-07 15:44) [41]

О как. Мне пришлось написать свою маленькую библиотечку-наследников от devExpress, ODAC и TAction. Эти наследники знают друг о друге и активно взаимодействуют. На формах они и присутствуют. Кликаешь по кнопке GridProperty, запускается TGridPropertyAction, вызывает форму настройки отображаемых столбцов и других свойств. Тыкаешь по кнопке Filter, запускается TFilterAction, по прикрученному TMyOraStoredProc вычисляет первый Grid или TreeList (а больше и не надо) и рядом с ним показывает Инспектора, унаследованного от devExpress, тот определяет параметры и тексты, все это показывает, по вводу меняет параметры в TMyOraStoredProc и по TRefreshAction все обновляется. Ну и так далее. Если инспектора надо будет отобразить в модальном окне, я просто добавлю соответствующий пункт во всплывающее меню инспектора и напишу соответствующие обработчики этого. Т.е. там где требуется какая-то гибкость, пишешь наследников и их и используешь. Корректировкой кода наследника добиваешься изменения поведения программы (интерфейса) в целом.

← →
seg (2006-02-07 15:49) [42]

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

Ну и что начинается? Платежи от заказчика поступают?
Если поступают, то шароварщики были бы в восторге от такого заказчика.

← →
seg (2006-02-07 15:51) [43]

обычные кнопки со стрелками навигации по набору данных

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

← →
Карелин Артем © (2006-02-07 15:52) [44]

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

← →
Ega23 © (2006-02-07 15:52) [45]

> Ну и что начинается? Платежи от заказчика поступают?
> Если поступают, то шароварщики были бы в восторге от такого
> заказчика.

Платежи-то поступают. Но получается, что для одного заказчика проект надо вот с такими фреймами собирать, для другого - с другими, для ... и т.п.
А зачем? Если можно один раз описать это всё в БД?

← →
Ega23 © (2006-02-07 15:54) [46]

>
> Платежи-то поступают. Но получается, что для одного заказчика
> проект надо вот с такими фреймами собирать, для другого
> - с другими, для ... и т.п.
> А зачем? Если можно один раз описать это всё в БД?

В дополнение:

Если заказчик хочет изменить внешний вид, то в данном случае не требуется ребилд проекта. Просто некоторые настройки в БД поменял и всё. Можно, кстати, прямо на объекте делать.

← →
seg (2006-02-07 15:57) [47]

Если можно один раз описать это всё в БД?

Один раз опишете и что дальше - зубы на полку?

> Один раз опишете и что дальше - зубы на полку?

А, ну если с ТАКОЙ позиции на это глядеть, то такая архитектура просто вредная... :о)

seg (07.02.06 15:57) [47]

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

← →
seg (2006-02-07 16:13) [50]

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

← →
seg (2006-02-07 16:16) [51]

Недавно читал в новостях историю о том, как практически здоровому мужику сделали кучу ненужных платных операций,

Поговорка современных врачей: здоровых людей нет, есть недообследованные...

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

> то нужен индивидуальный подход

Я как-то слышал такую историю. Разработчик писал в базу количество обращений/чтений/вызовов, короче чего-то из этого, на клиенте читал и делал холостые циклы в зависимости от текущего количества. Через какое-то время (месяц-два) пользователь уже не мог работать с программой и вызывал разработчика, чтобы тот чего-то там "подкрутил"/"подчистил" и т.п. Тот приезжал, обнулял счетчик, снимал с клиента денюжку за "поддержку", а пользователь радостно продолжал работать дальше. :)

А кто видел продукты, сделанные на "оракл формз" или сап р/3?
Сильно там об UI позаботились? :)

сап р/3 - интерфейс, конечно, убогий. Частично они заменили его на стандартный виндовый, хотя последнюю версию я не видел.

← →
seg (2006-02-07 16:25) [55]

А кто видел продукты, сделанные на "оракл формз" ?
Сильно там об UI позаботились? :)

Там конечно сделано примитивно.

> сап р/3 - интерфейс, конечно, убогий. Частично они заменили
> его на стандартный виндовый, хотя последнюю версию я не
> видел.
>

Ты почему ещё до сих пор трезвый? :о)

У клиентов SAP R3 покупатели не являются пользователями. Этим ВСЕ сказано.

У SAP R3 покупатели не являются пользователями.

Курдль © (07.02.06 16:20) [53]

> А кто видел продукты, сделанные на "оракл формз" или сап
> р/3?
> Сильно там об UI позаботились? :)

Там умные люди писали, которые знают, с какой стороны на бутерброде масло намазано.

>Ega23 © (07.02.06 14:49) [26]
>Да задолбало то, что один заказчик хочет видеть справа - дерево, слева - графику, а внизу - протокол событий. А другой хочет справа - графику, слева - дерево, а вот протокол событий - отдельной модальной формой.

Мало водки..

← →
seg (2006-02-07 16:49) [61]

Там умные люди писали, которые знают, с какой стороны на бутерброде масло намазано.

Разработчикам - масло, а пользователям - черный хлеб.

seg (07.02.06 16:49) [61]

Если не трудно, обойдемся без сказок о том, что Oracle свои Forms разработали специально, чтобы загнобить пользователей убогим интерфейсом.

← →
seg (2006-02-07 16:56) [63]

обойдемся без сказок о том, что Oracle свои Forms разработали специально, чтобы загнобить пользователей убогим интерфейсом.

Конечно не специально, это стиль...

seg (07.02.06 16:56) [63]

> Конечно не специально, это стиль...

Тут кто-то про платящего заказчика несколькими постами выше говорил ?
Так в чем проблема - заказчик платит за результат oracle forms, а что еще надо ?

← →
seg (2006-02-07 17:07) [65]

Тут кто-то про платящего заказчика несколькими постами выше говорил ?

Я говорил, что желания платящего заказчика надо удовлетворять, а не посылать его со словами "вы не понимаете".

seg (07.02.06 17:07) [65]

> Я говорил, что желания платящего заказчика надо удовлетворять

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

Как вы пишете ПО? Найти похожие ветки