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

← →
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]

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

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

← →
Ega23 © (2006-02-07 15:59) [48]

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

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

← →
Sandman29 © (2006-02-07 16:11) [49]

seg (07.02.06 15:57) [47]

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

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

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

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

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

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

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

← →
evvcom © (2006-02-07 16:20) [52]

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

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

← →
Курдль © (2006-02-07 16:20) [53]

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

← →
evvcom © (2006-02-07 16:22) [54]

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

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

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

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

← →
Ega23 © (2006-02-07 16:26) [56]

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

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

← →
ZeroDivide © (2006-02-07 16:29) [57]

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

← →
ZeroDivide © (2006-02-07 16:29) [58]

У 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, впрочем, все зависит от заказчика, если он большой и толстый и готов быть вечным заказчиком, тогда можно и поудовлетворять. А если одному нравится дерево справа, а другому слева, то одного лучше послать в пешее путешествие, и вместо того, чтобы тратить время на перестановку деревьев, лучше за это время функционал нарастить.

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