DevelopersInfo
Версия 4.6.0
© 2015-2023, ООО "Процессные технологии"
# Соглашение по оформлению кода Java
Стиль форматирования (Eclipse: Window -> Preferences -> Java -> Code style -> Formatter)
В целом соответствует https://google.github.io/styleguide/javaguide.html, кроме увеличенной длины строки.
Для eclipse можно сделать импорт из файла Файл:RunaWFE.formatter.xml.
Настройки для idea: Файл:IdeaCodeStyle.xml.
- Создать новый форматтер на базе Eclipse [build-in].
- Увеличить размер Java-строки для форматирования: Line Wrapping -> Maximum line width заменить с 80 на 150.
- Comments -> Line width 150
- Tab policy -> Spaces only
- Применить http://stackoverflow.com/a/12705543
Действия при сохранении (Eclipse: Window -> Preferences -> Java -> Editor -> Save Actions)
Включить
- Perform the selected actions in save;
- Format source code;
- Format edited lines;
- Organize imports;
- Additional actions. Configure.
- Code Style -> Control statements -> Use blocks in if/while/for/do statements. Включить Always.
Порядок импортов
Порядок импортов в классе: импорты, пустая строка, статические импорты (Eclipse: Window -> Preferences -> Organize imports: Remove all; New * ; New static *)
# Соглашение по именованию переменных
Переменные лучше именовать так:
- Variable variable: в соответствии с полным названием класса
- Variable oldVariable: если переменных данного типа несколько в текущем контексте специфика отражается префиксом
- VeryLongType type: сокращение по суффиксу в случае длинного названия класса
- Variable oldVar: неправильное сокращение
Такие правила несложно соблюдать (в Eclipse Ctrl + Space) и они стимулируют называть классы более правильно (например VeryLongType вместо TypeVeryLong). При полном соответствии Eclipse также переименовывает названия переменных при переименовании класса.
# Соглашение по оформлению кода XML
Отступ 1 tab.
Но для plugin.xml - так как делает eclipse, там другие правила.
# Соглашение по properties
С использованием плагинов, описанных в https://rm.processtech.ru/issues/3295
# Соглашение по оформлению кода JS, XHTML, CSS
https://contribute.jquery.org/style-guide/js/ (за исключением пробелов в аргументах js) (отступы табы)
# Работа с багами и задачами
Все они у нас сейчас называются тикеты: https://sourceforge.net/p/runawfe/bugs/
Состояния у них 3:
- open[*] - открыт, нужно делать тому, на кого он назначен
- pending[*] - выполнен, переведён на тестирование
- closed[*] - закрыт, тестировать не нужно
При выполнении тикета, его статус нужно перевести в:
- pending[*] - если нет уверенности что всё приведено в порядок
- closed[*] - если тестирование проводилось и всё в порядке
При изменении статуса переназначать, думаю, нет необходимости.
В левой колонке добавили и изменили, сейчас:
- Closed Tickets - все закрытые
- For Testing - все для тестирования
- My Tickets - все открытые для текущего пользователя
- Open Tickets - все открытые
При создании нового тикета просьба сразу его назначать:
- по дистрибутивам Linux - Даниилу (efnez)
- по дистрибутивам Windows - Алексею (kanaal)
- если известен исполнитель работ - ему
- по остальным - Сергею (gritsenko_s)
# Работа с версиями
В проекте используется нумерация версий в виде X.Y.Z, где
- X - версия, обновляемая при существенных изменениях в ядре
- Y - версия, обновляемая при добавлении значимого нового функционала
- Z - версия, обновляемая при добавлении не значимого нового функционала или при исправлении ошибок
В trunk-е версия проектов устанавливается в виде X.Y.Z-SNAPSHOT (например 4.1.1-SNAPSHOT), где версия X.Y.Z - версия следующего релиза.
# Выпуск релиза
# Сервер
1. В master изменить версии, например с помощью команд
В папке wfe-app
mvn versions:set -DgenerateBackupPoms=false -DnewVersion=4.X.X
Данная команда не обновляет версии в некоторых проектах, например wfe-webservice-client.
2. Закоммитить
3. Собрать бинарный и Windows-дистритутив (инструкция, https://rm.processtech.ru/issues/342), проверить
4. Запушить, создать релиз в https://github.com/processtech/runawfe-server/releases
TODO. Загрузить артефакты в публичный репозиторий
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
5. По аналогии с п.1 увеличить версию до 4.X.(X+1)-SNAPSHOT либо 4.(X+1).X-SNAPSHOT
# Редактор
1. В master изменить версии, например с помощью команд
В папке gpd/plugins
mvn tycho-versions:set-version -DnewVersion=4.X.X
2. Закоммитить
3. Сделать [DesignerDeveloperGuide#BuildingFromSourcesUsingMaven сборку] и проверить его
4. Запушить, создать релиз в https://github.com/processtech/runawfe-devstudio/releases
5. По аналогии с п.1 увеличить версию до 4.X.(X+1)-SNAPSHOT либо 4.(X+1).X-SNAPSHOT
В случае проблем после выпуска релиза сделать из тега ветку releaseX.Y.Z, добавить исправления и сделать тег из неё заново (ветку придётся оставить)
# Работа с документацией
Правила оформления:
- не использовать в документации излишние слова runawfe и пр.
- заголовки всех страниц устанавливаются с помощью шаблона PageHeading
- все заголовки, которые представляют собой интерес как якори (anchor) для отправки ссылкой, оформить с использованием шаблона Title
- сноски оформить с использованием шаблонов Note (замечание) и Warning (предупреждение)
- использовать унифицированный словарь терминов (TODO: составить его)
Для отправки ссылки, не содержащий non-ascii символов, на определённый раздел нужно из меню выбрать раздел (или спозиционировать другим образом), после этого нажать на решётке и скопировать из строки браузера URL.