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

Сообщение отредактировал Duedev - 9:11:2006, 16:01

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

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

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

<< Десять заповедей >>

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

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

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



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

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

Нет....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а это как?

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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