Версия для печати темы

Автор: Duedev 9:11:2006, 16:00

Вопрос у меня конкретный: существует ли стандарт комментирования кода, написанного на LotusScript?
Но он порадил более общий вопрос: А какие вообще стандарты, связанные с разработкой ПО средствами Lotus существуют???(именно привязанные к специфике лотуса)

Автор: SOFTOBZOR.ru 10:11:2006, 05:22

Наверно тут специфика лотуса ни причем.
Все зависит от специфики разработчика (разработчиков).

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

А если карябыеш один, то это уж зависи от "жопа-часов".
Чем больше этих самых ЖЧ - тем чище код.

Автор: Morpheus 10:11:2006, 06:58

]]>http://forum.codeby.net/go.php?http://www.notesnet.ru/nn/notesnet.nsf/note/01FA839F2BF76D60C3256E9B004E90C3]]>

поискать на сайте, там есть еще интересные вещи

Автор: Duedev 10:11:2006, 08:41

Да, я согласен с этим. Но меня интересуют более конкретные вещи привязанные к разработке корпоративного обеспечения на базе платформы Lotus, нежели что-то вроде MSF, ISO 12207,или IEEE 1074

Я слышал, что существует стандарт комментирования кода LotusScript, поэтому предположил, что есть еще ряд специфичных стандартов, которые мне не известны.



А вот с этим я вообще не согласен.
Считаю, что чистота кода зависит от квалификации разработчика.

Автор: SOFTOBZOR.ru 10:11:2006, 08:53

Хм... а квалификация не от жопачасов ли зависит

Автор: Duedev 10:11:2006, 13:19

Нет....

Автор: Lexa-xa 29:11:2006, 21:37

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

Автор: GROMILA 4:12:2006, 11:02

Вопрос хороший.

Обычно при разарботке на любом средстве или платформе есть два регламента:
1. Регламент разработки и внесения изменений
2. Регламент оформления кода
Интересно было бы почитать конкретные рекомендации разработчиков Лотус.

Из практики и анализа разношерсных баз можно сформулировать основные принципы или правила:

РЕГЛАМЕНТ РАЗРАБОТКИ И ВНЕСЕНИЯ ИЗМЕНЕНИЙ
1. Разработку вести сразу в шаблонах NTF. Релиз формируется путем копирования и удаления ненужных документов. (в литературе рекомендуют наобоорот - делать NTF из NSF)
2. Все обращения к базам должны быть сведены в настройки
3. Общие библиотеки, поля, формы обязательно наследовать из какого-то одного шаблона
4. Должны быть организованы 3 версии или экземляра баз:
- Работа - реальная эксплуатация релизов
- Тест - промежутточное тестирование версии с привлечением ключевых пользователей и тестеров
- Разработка - шаблоны - программирование новых версий

РЕГЛАМЕНТ ОФОРМЛЕНИЯ КОДА
1. Именование форм
имя формы - Русскоязычное ()
псевдоним (Alias) - англоязычный
Везде в коде и на формулах использовать обращение только через псевдонимы!!!

2. Именование полей на формах
по формату: Префикс_Смысловое название, где Префикс - аббревиатура названия формы на базе псевдонима, или по смыслу

3. Именование представлений
имя формы - Русскоязычное
псевдоним (Alias) - англоязычный, формат имени: ИмяФормы~ПевоеКлючевоеПоле
Везде в коде и на формулах использовать обращение только через псевдонимы!!!

Это лишь примерные правила, но общепринятые среди встречавшихся мне систем под Лотус.

Автор: Mihal 4:12:2006, 14:49

По поводу представлений:
-------------------------------------------------------------
Помимо этого условно можно разделить представления на категории использования:
1. Для просмотра - те, что показываются пользователю
2. Для поиска - для всяких @DBLookup'в и GetDOcumentByKey
3. Для выбора - для использования в PickList'ах.
4. Встроенное - для использования в качестве встроенного представления.

В связи с этим правила:
1. Никогда не использовать одно и то же представление в нескольких категория (вьюху, которая показывается пользователю не должна использоваться для поиска по ней с помощью GetDocumentByKey).
2. Как минимум русское название имени должно содержать категорию использования (например, "Для поиска\Персонал по ФИО").
----------------------------------------------------------
По поводу форм аналогично. Но там можно выделить две категории использования:
1. Для формирования/отображения документов.
2. Для Dialogbox'в.
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------

Помимо этого хочу добавить, что правильная организация баз данных (разработка-тестирование-использование) зачастую плавно переходит в такую: разработка\тестирование - использование.

Автор: Elena Nefedova 4:12:2006, 16:04

А иногда еще и в такую:
Разработка -> тестирование/использование

Автор: GROMILA 4:12:2006, 16:19

Я бы сказал, что это зависит от целесообразности на каждой из стадий создания и внедрения системы
На стадии тестовой эксплуатации сразу после разработки новой подсистемы (крупного куска) возможно и даже нужно применить Тест-Разработка
На стадии же рабочей эксплуатации обязательно Работа-Тест-Разработка и отвечает за это руководство вместе с админами и руководителем проекта, так что не рыпнешься и это правильно

Автор: Duedev 5:12:2006, 08:01

В продолжение...
есть ли у кого рекомендации по созданию документов верхнеуровнего и низкоуровнего дизайна разработок средствами Lotus?

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

Автор: Morpheus 5:12:2006, 08:07

а это как?

Автор: Elena Nefedova 5:12:2006, 08:10

Для: Duedev
Можно я спрошу, что такое "верхнеуровнего и низкоуровнего дизайна разработок средствами Lotus"?

Автор: Morpheus 5:12:2006, 08:15

Для: Elena Nefedova
Вас тоже заинтересовал этот термин

Автор: Mihal 5:12:2006, 09:50

Присоеденяюсь к вопросу о низкоуровневом и верхнеуровневом дизайне разработок!

Автор: GROMILA 5:12:2006, 11:34

Если я правильно понял, то вопрос по FrontEnd (GUI) и BackEnd начинке дизайна базы.

FrontEnd
В принципе хотелось бы иметь описалово стандарта графического интерфейса, но его сложно сделать.
Ну в принципе можно выделить общие подходы:
1. Создать общий вид формы ввода документов, где общими полями будут поля доступа и истории изменений. Данную форму использовать подобно шаблону - копировать и дополнять новыми полями.
2. Выработать различия в отображении полей при просмотре и при редактировании формы - обычно разными цветами: редактирование - синий, просмотр - черный
3. Обязательные поля помечать звездочками
4. Создать общий вид дизайна диалоговой формы для получения параметров, печати например. Использовать как шаблон.
5. Создать общий вид дизайна предсталений. Использоать как шаблон.
6. Свормулировать цветовую палитру всех возможных цветов в системе и добавить эти цвета в палитру для оперативного и безошибочного выбора в дизайне.

Все - юзай эти шаблончики и твой интерфейс будет как минимум унифицирован!!!


BackEnd
Ну тут особо ничего не придумаешь, разве что создать глобальные библиотеки по смыслу:
1. Сервис работы с базами
2. Сервисные функции (сортировка, например)
3. Сервис ведения лога
4. Сервис работы с печатными формами
5. Сервис работы с отчетами

Ну а далее - сами декомпозируйте


Что касается проектирования базы данных, то возьмите обычный реляционный инструмент (RRose, ERWin, Visio) и накропайте модель вашей базы, она будет с составными ключами, GUIDами, совсем не реляционная, но!!!! но позволит вам охватить всю систему целиком или частями, вывесив на стенке и тыкать указкой или еще чем-нибудь ))
Правда на это времечко понадобится. Ходят слухи, что IBM планирует все же поддержать лотус в розе.

Автор: Elena Nefedova 5:12:2006, 12:34

Для: GROMILA
В общем, мне понравилось

Автор: Mihal 5:12:2006, 12:49

Эхе-хе... А потом приходишь к заказчику. "Ой! А чего это у вас букавки такого цвета? Не! Мне не нравится!!! И шрифт не такой! И колнки не такие!". И всё перерисовывать ...

Автор: Morpheus 5:12:2006, 12:50

Для: Mihal
А как же стандарты/госты ??

Автор: Mihal 5:12:2006, 13:06

Для: Morpheus
При чём тут ГОСТы?

Автор: Morpheus 5:12:2006, 13:19

Для: Mihal
ну про госты я может и погарячился, но стандарты есть

Автор: Mihal 5:12:2006, 13:23

Для: Morpheus
Стандарты чего? Я чего-то даже направление мысли понять не могу... Можно поразвёрнутей?

Автор: Morpheus 5:12:2006, 13:39

Для: Mihal

Как чего ОФОРМЛЕНИЯ .. кнопоцьки, общий цвет , фон

Автор: Elena Nefedova 5:12:2006, 13:41

Стандарт оформления один - настраиваемое оформление!

Автор: Mihal 5:12:2006, 13:42

Для: Morpheus
Софт под заказ. Какие стандарты у заказчика?! "Ну, вы сделайте, а мы посмотрим". А потом начинается... "Это не нравится. а тут шрифт не 10-й, а 12-й. Мы плохо видим. Ой! А у нас на одном мониторе всё плохо видно. А нашему начальнику не нравится. И акты мы подписывать не будем!".

Автор: Morpheus 5:12:2006, 13:44

Для: Mihal
хм... канечно зависит от заказчика (у нас барышня после доса, кричала на БР шо эта серость ей глаза режет)
к сожалению щас просто нет книги в которой описаны стандарты эти

Автор: Mihal 5:12:2006, 13:47

Я подписываюсь под этим заявлением! Но как это настраиваемое оформление натянуть на Лотус... Вот где хундер храбен...

P.S. Заказчик умных книжек не читает... А акты подписывает он, а не автор книжек .

Автор: GROMILA 5:12:2006, 14:12

Проблема шрифтов да, существует, и она в принципе единственная серьезная.

Я долго прикидывал, но предлагаю ее решать по-майкрософтовски.
В системе по умолчанию везде в полях и кнопарях используется минимальный шрифт (8 или 9)
Если попадается слепой пользователь, то он не увилит не только вашу разработку, но и пункты меню любимого Word-а.
Ему нужно увелиличь шрифт по всей системе Windows.

Автор: oshmianski 5:12:2006, 14:24

есть еще варианты
1) Display_font_adjustment=n% в notes.ini
2) Писать инструмент для программной перестройки представлений (шрифты колонок и заголовок можно менять безболезненно, используя NotesView свойства)

Автор: Mihal 5:12:2006, 14:25

Для: GROMILA
Не только шрифты. Есть проблема настраиваемого интерфейса вцелом. Ведь менять массово по всей базе приходится не только шрифты. Но и много всего другого.

Автор: Elena Nefedova 5:12:2006, 14:32

Касательно клиента:
1. То, что цвета панели действий и фреймы можно настроить никто, я думаю, не сомневается
2. В формах еще и хедеры
3. Ячейки таблиц
4. Подлежат тончайшей настройке OutlineEntry и все-все кнопки (просто используем image hotspot)
5. Twistie и собственные иконки во вьюхах тоже легко меняются

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

Автор: Mihal 5:12:2006, 14:36

Хе. Сколько у представления свойств связаных с отображением? А у формы? А у шрифтов? А стили в таблицах не работают, между прочим . Всё не охватишь. С этим я уже смирился. Стараюсь перво-наперво показать экранные формы. Но заказчик не любит смотреть сразу почему-то. Он любит потянуть время...
- Вы это, делайте, а я потом всё сразу посмотрю.
- Давайте, может, сразу с интерфейсом разберёмся?
- У нас нету времени. Мы люди занятые. Мы всё сразу в конце.

А когда приносишь готовый продукт - ваще празник! "А у нас корпоративные цвета не такие!".

Я к тому. что оч. плохо отсутствие в Лотусе настраиваемого внешнего оформления.

Для: Elena Nefedova
Стоп! А текст в ячейках таблицы?

Автор: Elena Nefedova 5:12:2006, 14:42

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

Для: Mihal
А в Delphi вы интерфейс легко перенастроите?

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

Автор: Mihal 5:12:2006, 14:50

Для: Elena Nefedova
Ну, у мя есть базейка, куда вводяться данные представления (цвета строк там, формат акшн бара и т.д.). Потом можно выбрать другую базу, в ней вьюхи - и в этих вьюхах произойдут изменения. Через DXL работает.

Но всё равно напрягает. Это же не настройка под юзера. Когда в зависимости от профайла какого-нить можно менять оформления у конкретного клиента.

А сколько времени тратять в Делфи - меня как-то не трогает . То их проблемы. А в Лотусе хотелось бы что-то вроде CSS. Причём что б можно было менять "на лету" .


Эххх... Мячты, мячты...

Автор: Elena Nefedova 5:12:2006, 15:01

1. У меня настройки только подложек (в т.ч. под Outline), панелей и фреймов может юзер выбирать. И ему хватает (к счастью!)
2. Все "на лету" не поменять, ибо настроек слишком много. Но CSS для толстого клиента - это хорошая идея

Автор: Mihal 5:12:2006, 15:33

Кстати, надо бы всё вышенаписаное попытаться в файлик собрать. Типа, "Типовые стандарты и регламенты разработки в Лотус Нотесе".

Автор: xlETO 6:12:2006, 06:52

У компании Ytria есть несколько программ позволяющих разом окучивать различные элементы дизайна, в частности:

- ViewEZ
- ActionBarEZ
- DesignPropEZ

работал ли кто-нибудь с этими продуктами?

Автор: Mihal 6:12:2006, 08:14

Для: xlETO
Антиресно

Автор: Duedev 6:12:2006, 13:18

Да! Именно это я и имел в виду (чуть-чуть запоздал с ответом, пардон)



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



Я тоже над этим задумался. Если получится - выложу. А далее его можно совместно дополнить и произвести рецензию

Автор: Mihal 6:12:2006, 15:14

Уууу.... Полштучки за штучку стоит это удовльствие...

Автор: xlETO 12:12:2006, 13:04

Да, недешевые штучки. Но у них 30-ти дневный триал есть, а при желании - так и вовсе бесконечный

Автор: Dikobraz Grey 13:05:2008, 09:17

Ну у нас задекларированы такие правила (см аттач). Вот только соблюдают их далеко не везде и не все .