valitydev/erlang-guidelines
14
0
Fork 0
mirror of https://github.com/valitydev/erlang-guidelines.git synced 2024-11-06 08:45:18 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix: Make checklist with checkboxes

Browse Source
This commit is contained in:
Yaroslav Rogov 2021-05-21 14:21:50 +03:00
parent 98ed1cf2c3
commit 1df671a715
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
contributing.md
View File

@ -8,20 +8,20 @@
## Создание новой функциональности
- проработка предметной области и выделение основных абстракций;
- написание кода, реализующего эти абстракции;
- [ ] проработка предметной области и выделение основных абстракций;
- [ ] написание кода, реализующего эти абстракции;
> Следует предоставлять в модулях _простые_, _понятные_ и _полные_ (_симметричные_) интерфейсы.
>
> Огромное количество полезных рекомендаций приведено в [соответствующем документе](code-style.md).
- покрытие написанного кода спеками;
- [ ] покрытие написанного кода спеками;
> Хорошей практикой является покрытие типами и спеками элементов и процессов, присутствующих в предметной области.
>
> Необходимо стремиться к сужению области определения различных типов, чтобы инструменты статического анализа действительно могли помочь в поиске проблем с написанным кодом.
- покрытие написанного кода тестами;
- [ ] покрытие написанного кода тестами;
> Большее внимание стоит уделять тестам, затрагивающим исключительные, неуспешные или ошибочные сценарии использования нового функционала, и только потом – тестам успешных или штатных сценариев использования.
>
@ -33,7 +33,7 @@
>
> Если инструменты для тестирования дают такую возможность, следует давать тестам понятные разработчику названия и/или описания.
- написание документации;
- [ ] написание документации;
> Если вносимое изменение каким-либо образом отражается на внешних интерейсах сервиса, приложения или библиотеки (при решении бизнес-задач случается в 95% случаев), этот эффект должен быть отражён в документации.
>
@ -41,7 +41,7 @@
>
> Чем ближе документация к репозиторию с кодом, тем лучше.
- подготовка процессов миграции.
- [ ] подготовка процессов миграции.
> Если необходима миграция и она может быть проведена без участия человека, она _должна_ быть проведена автоматически. В ином случае процессы миграции должны быть подробно задокументированы.
>
@ -49,12 +49,12 @@
## Правка багов
- анализ ситуации, в которой наблюдается ошибочное поведение;
- написание одного или нескольких тестовых сценариев, покрывающих эти ситуации;
- [ ] анализ ситуации, в которой наблюдается ошибочное поведение;
- [ ] написание одного или нескольких тестовых сценариев, покрывающих эти ситуации;
> Хорошим тоном будет сразу провести прогон тестов и проверить, что новые тестовые сценарии действительно завершаются неуспешно в отсутствии исправления.
- исправление логики в исходном коде.
- [ ] исправление логики в исходном коде.
> После этого все тестовые сценарии из предыдущего пункта должны завершатся успешно.
>