• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Стандарты и регламенты программирования в Lotus

  • Автор темы Duedev
  • Дата начала
D

Duedev

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

SOFTOBZOR.ru

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

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

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

morpheus



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

Duedev

<!--QuoteBegin-SOFTOBZOR.ru+10:11:2006, 07:22 -->
<span class="vbquote">(SOFTOBZOR.ru @ 10:11:2006, 07:22 )</span><!--QuoteEBegin-->Наверно тут специфика лотуса ни причем.
Все зависит от специфики разработчика (разработчиков).
[snapback]47595" rel="nofollow" target="_blank[/snapback]​
[/quote]

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

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

<!--QuoteBegin-SOFTOBZOR.ru+10:11:2006, 07:22 -->
<span class="vbquote">(SOFTOBZOR.ru @ 10:11:2006, 07:22 )</span><!--QuoteEBegin-->А если карябыеш один, то это уж зависи от "жопа-часов".
Чем больше этих самых ЖЧ - тем чище код.
[snapback]47595" rel="nofollow" target="_blank[/snapback]​
[/quote]

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

SOFTOBZOR.ru

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

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

Duedev

<!--QuoteBegin-SOFTOBZOR.ru+10:11:2006, 11:53 -->
<span class="vbquote">(SOFTOBZOR.ru @ 10:11:2006, 11:53 )</span><!--QuoteEBegin-->а квалификация не от жопачасов ли зависит
[snapback]47635" rel="nofollow" target="_blank[/snapback]​
[/quote]

Нет.... <_<
 
L

Lexa-xa

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

GROMILA

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

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

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

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

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

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

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

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

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

Mihal

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

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

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

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

Elena Nefedova

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

GROMILA

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

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

Duedev

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

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

morpheus

<!--QuoteBegin-Duedev+5:12:2006, 10:01 -->
<span class="vbquote">(Duedev @ 5:12:2006, 10:01 )</span><!--QuoteEBegin-->верхнеуровнего и низкоуровнего дизайна
[snapback]49821" rel="nofollow" target="_blank[/snapback]​
[/quote]а это как? :D
 
E

Elena Nefedova

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

morpheus

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

Mihal

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

GROMILA

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

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

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

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

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


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

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


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

Elena Nefedova

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

Mihal

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

morpheus

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

Обучение наступательной кибербезопасности в игровой форме. Начать игру!