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

← →
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] Причина там.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.п.

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

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

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

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