diff --git a/doc/process/README.md b/doc/process/README.md index aee79ee9..ce0b8ed0 100644 --- a/doc/process/README.md +++ b/doc/process/README.md @@ -41,8 +41,9 @@ b. Сообщение должно описывать состав измене c. Сообщение должно иметь следующий формат: ``` -<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: <состав и семантика изменения 1>[, -..., <состав и семантика изменения M>][; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] +<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: +<состав и семантика изменения 1>[, ..., <состав и семантика изменения M>] +[; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] ``` Таким образом, самый простой вид сообщения: @@ -81,7 +82,8 @@ c. Сообщение должно иметь следующий формат: * `<модуль>` и `<подмодуль>` разделяются слешем `/`; * Группы `<модуль>/<подмодуль>` отделяются друг от друга запятой `,`; * `<модуль>/<подмодуль>` и `<состав и семантика изменения>` разделяются двоеточием `:`; - * Группы `<модуль >: <состав и семантика изменения>` отделяются друг от друга точкой с запятой `;`; + * Группы `<модуль >: <состав и семантика изменения>` отделяются друг + от друга точкой с запятой `;`; * Группы `<состав и семантика изменения>` отделяются друг от друга запятой `,` В квадратных скобках `[]` указаны части сообщения, которые могут отсутствовать. @@ -109,15 +111,20 @@ data-collectors // Отсутствует суть изменений #287 common: review fixes -// Нет номера задачи, в указании модуля присутствует название проекта и указана излишняя вложенность -data-collectors/report/pasrer/historical: optimized parsing of the dom to get 2x speed of parsing +// Нет номера задачи, в указании модуля присутствует название проекта +// и указана излишняя вложенность +data-collectors/report/pasrer/historical: optimized parsing of the dom + to get 2x speed of parsing // Хорошо inni/issues#104 common: added script to update dependencies to cure integrity check error -inni/issues#105 instrument: changed source of data from source1 to source2 to get more stable data stream -inni/issues#106 dev/db: changed type of the field `value` of report to store data from different sources; +inni/issues#105 instrument: changed source of data from source1 to source2 + to get more stable data stream +inni/issues#106 dev/db: changed type of the field `value` of report to store data + from different sources; report: implemented new service to get data from some new source of data. -inni/issues#107 common/services: added new service `report data service` to get report data from database +inni/issues#107 common/services: added new service `report data service` to get + report data from database ``` d. Не должно быть вложенности больше `<модуль>/<подмолуль>`, т.е. максимальная точность @@ -131,8 +138,9 @@ d. Не должно быть вложенности больше `<модуль <модуль 1>/<подмодуль 2>: <состав и семантика изменения> // Вариант 2. Сообщение сгруппировано по модулю -<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, что оно сделано в подмодуле 1>, -<состав и семантика изменения с указанием, что оно сделано в подмодуле 2>; +<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, +что оно сделано в подмодуле 1>, <состав и семантика изменения с указанием, +что оно сделано в подмодуле 2>; ``` e. Не должно быть точки в конце сообщения. @@ -211,10 +219,10 @@ h. Небольшие изменения (исправление опечатк вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью). -i. Задача должна быть переведена в состояние "в работе", когда над ней действительно начата +i. Задача должна быть переведена в состояние «‎в работе», когда над ней действительно начата работа. -j. Допускается отправлять в репозиторий только "зелёные файлы", т.е. файлы, по которым +j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым пройдены все инспекции кода. k. Перед отправкой изменений в репозиторий должны выполняться автоматизированный @@ -228,7 +236,7 @@ l. Добавленные изменения должны быть покрыт a. В файле `CHANGELOG.md` в корне проекта присутствует запись о сделанных изменениях. [Ведите Changelog](https://keepachangelog.com/ru/1.0.0/) -b. Задача должна быть перведена в состояние "ревью". +b. Задача должна быть перведена в состояние «ревью». c. Должно быть выполнено саморевью задачи, т.е. просмотр своих изменений перед тем, как предложить сделать это другим участникам команды. На этом шаге, как правило, @@ -246,7 +254,7 @@ f. После того, как изменения приняты проверя с последующим удалением своей ветки. g. Задача должна быть переведена в состояние следующее состояние задачи (как правило, -это состояние "готово") после её влития в `dev`. +это состояние «‎готово») после её влития в `dev`. ### 2.3. Ведение журнала изменений (changelog) @@ -262,8 +270,8 @@ c. Для каждого изменения в начале строки дол ``` // Пример описанного изменения - [`DXAPP-571`](https://smekalka.atlassian.net/browse/DXAPP-571) Added - [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware to get alternative to react native - debugger that slows down app during debug + [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware + to get alternative to react native debugger that slows down app during debug ``` d. Для записей в журнале изменений применяются те же правила по ограничению на длину строки, @@ -334,7 +342,47 @@ g. Все вопросы по ревью обсуждаются наибыстр использовать такой способ коммуникации, при котором ответ затягивается, а соответственно затягивается и ревью. -#### 2.4.4. Противоречия и споры в процессе обзора кода +#### 2.4.4. Process of task review not related with code management (Github, Gitlab) + +We are talking about tasks like writing documentation in Notion, Confluence and so on. + +Motivation:\ +We want to decrease number of distracting requests to the author of changes to the +single one in positive scenario. We want to distract each other less. + +1. A reviewer puts wishes and remarks in comments of the thread of a message +related to the task in `review` channel during the code review process. + + **Format** + + Message: + > [short task description] \ + [link to task] + + Comments: + > 1 [Remark or wish 1] \ + 2: [Remark or wish 2] \ + N: [Remark or wish N] + +2. After the reviewer has put all remarks and wishes, he notifies the author +of task. Also he changes status of the task to «open» / «reopen». +It is necessary so that other reviewers could make review only non-reviewed tasks. + +3. The author of task checks out list of remarks and wishes, prepares a list of +questions and discusses them with the reviewer. Before the author of task starts fixing +he changes status of the task to «in progress». + +4. The author of changes marks resolved item using smile: ✔ + +5. When the author of changes has finished and has marked all points as done, +he notifies the reviewer too. + +6. The reviewer marks items that are fixed correctly using smile ✔. +If the reviewer does not agree with something, he requires fixes and improvements +from the author of task. Repeat steps starting from the step 2 until +all the items are «done». + +#### 2.4.5. Противоречия и споры в процессе обзора кода a. Споры и затягивание обзора кода не допускаются. @@ -348,7 +396,7 @@ c. Не допускается повторных обсуждений по по уже принятых правил написания кода. Это не исключает возможности договориться о новых при хорошем уровне коммуникаций и взаимопонимания в команде. (см. пункт выше) -#### 2.4.5. Правила для участников, проверяющих код +#### 2.4.6. Правила для участников, проверяющих код a. Закрыв файл после проверки, вы тем самым полностью принимаете этот вариант так, как будто это написали вы. А так же вы уже несёте ответственность за уровень качества и работоспособности кода. @@ -359,7 +407,7 @@ b. Если что-то правится быстро (5-10 секунд) и о то можно уведомить автора об этих изменениях, чтобы он получил дополнительный опыт и учитывал его в дальнейшей работе. -#### 2.4.6. Состав участников обзора кода +#### 2.4.7. Состав участников обзора кода a. Запрос на влитие изменений должен быть сделан на двух участников команды, которые в состоянии понять смысл изменений и подтвердить их корректностью. Не может считаться @@ -393,7 +441,7 @@ d. [?] В качестве варианта ревью, возможно, сто автором с пояснениями. Это может сократить время, необходимое участникам команды на осмысление кода каждому в отдельности. -#### 2.4.7. Написание комментариев в процессе обзора кода +#### 2.4.8. Написание комментариев в процессе обзора кода a. Критиковать код, а не автора. Помните, раз вы увидели этот код - то он уже тоже ваш. @@ -416,7 +464,7 @@ d. Не писать в побудительном наклонении: `Исправь А на Б` ``` -#### 2.4.8. Отношение к комментариям в обзоре кода +#### 2.4.9. Отношение к комментариям в обзоре кода a. Не оправдываться в комментариях: `А, да, точно, я затупил`, `Я невыспался` и т.д. @@ -429,17 +477,17 @@ c. Запомнить ситуацию, усвоить полученный оп d. Если не согласны - обсудить. Не использовать агрессивно-защитные высказывания и пассивное игноирование. Держать в голове всегда цели обзора кода и команды в целом. -#### 2.4.9. Проверка стиля кода +#### 2.4.10. Проверка стиля кода a. У каждого участника должны быть настроены все автоматизированные средства для автоматической проверки и исправлений кода. b. В результате необходимо стремиться к отсутствию комментариев, касающихся стиля кода. -#### 2.4.10. Приоритет обзора кода +#### 2.4.11. Приоритет обзора кода a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным -как для просматривающего изменения, так и для автора изменений. Задача в состоянии "ревью" +как для просматривающего изменения, так и для автора изменений. Задача в состоянии «‎ревью» имеет наивысший приоритет, если по какой-то причине явно не было принято другое решение в виде исключения. @@ -450,7 +498,7 @@ b. Идеальное время влития изменений равно ну c. Запрос на влитие изменений не должен отправляться на участников команды, которые не могут своевременно выполнить обзор кода. -#### 2.4.11. Учёт при планировании +#### 2.4.12. Учёт при планировании a. Время на ревью и исправления должно учитываться при планировании задач на итерацию. diff --git a/doc/process/README.ru.md b/doc/process/README.ru.md index 8b647d98..216803ce 100644 --- a/doc/process/README.ru.md +++ b/doc/process/README.ru.md @@ -41,8 +41,9 @@ b. Сообщение должно описывать состав измене c. Сообщение должно иметь следующий формат: ``` -<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: <состав и семантика изменения 1>[, -..., <состав и семантика изменения M>][; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] +<номер задачи> <модуль 1>[/<подмолуль>][, ..., <модуль N>[/<подмодуль>]]: +<состав и семантика изменения 1>[, ..., <состав и семантика изменения M>] +[; ...; <модуль K>[/<подмодуль>]: <состав и семантика изменения>] ``` Таким образом, самый простой вид сообщения: @@ -81,7 +82,8 @@ c. Сообщение должно иметь следующий формат: * `<модуль>` и `<подмодуль>` разделяются слешем `/`; * Группы `<модуль>/<подмодуль>` отделяются друг от друга запятой `,`; * `<модуль>/<подмодуль>` и `<состав и семантика изменения>` разделяются двоеточием `:`; - * Группы `<модуль >: <состав и семантика изменения>` отделяются друг от друга точкой с запятой `;`; + * Группы `<модуль >: <состав и семантика изменения>` отделяются друг + от друга точкой с запятой `;`; * Группы `<состав и семантика изменения>` отделяются друг от друга запятой `,` В квадратных скобках `[]` указаны части сообщения, которые могут отсутствовать. @@ -109,15 +111,20 @@ data-collectors // Отсутствует суть изменений #287 common: review fixes -// Нет номера задачи, в указании модуля присутствует название проекта и указана излишняя вложенность -data-collectors/report/pasrer/historical: optimized parsing of the dom to get 2x speed of parsing +// Нет номера задачи, в указании модуля присутствует название проекта +// и указана излишняя вложенность +data-collectors/report/pasrer/historical: optimized parsing of the dom + to get 2x speed of parsing // Хорошо inni/issues#104 common: added script to update dependencies to cure integrity check error -inni/issues#105 instrument: changed source of data from source1 to source2 to get more stable data stream -inni/issues#106 dev/db: changed type of the field `value` of report to store data from different sources; +inni/issues#105 instrument: changed source of data from source1 to source2 + to get more stable data stream +inni/issues#106 dev/db: changed type of the field `value` of report to store data + from different sources; report: implemented new service to get data from some new source of data. -inni/issues#107 common/services: added new service `report data service` to get report data from database +inni/issues#107 common/services: added new service `report data service` to get + report data from database ``` d. Не должно быть вложенности больше `<модуль>/<подмолуль>`, т.е. максимальная точность @@ -131,8 +138,9 @@ d. Не должно быть вложенности больше `<модуль <модуль 1>/<подмодуль 2>: <состав и семантика изменения> // Вариант 2. Сообщение сгруппировано по модулю -<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, что оно сделано в подмодуле 1>, -<состав и семантика изменения с указанием, что оно сделано в подмодуле 2>; +<номер задачи> <модуль 1>: <состав и семантика изменения с указанием, +что оно сделано в подмодуле 1>, <состав и семантика изменения с указанием, +что оно сделано в подмодуле 2>; ``` e. Не должно быть точки в конце сообщения. @@ -211,10 +219,10 @@ h. Небольшие изменения (исправление опечатк вызывает сомнение в стабильности, оно должно быть выполнено либо через задачу, либо через запрос на вливание этого изменения, чтобы оно прошло обзор кода (ревью). -i. Задача должна быть переведена в состояние "в работе", когда над ней действительно начата +i. Задача должна быть переведена в состояние «‎в работе», когда над ней действительно начата работа. -j. Допускается отправлять в репозиторий только "зелёные файлы", т.е. файлы, по которым +j. Допускается отправлять в репозиторий только «зелёные файлы», т.е. файлы, по которым пройдены все инспекции кода. k. Перед отправкой изменений в репозиторий должны выполняться автоматизированный @@ -228,7 +236,7 @@ l. Добавленные изменения должны быть покрыт a. В файле `CHANGELOG.md` в корне проекта присутствует запись о сделанных изменениях. [Ведите Changelog](https://keepachangelog.com/ru/1.0.0/) -b. Задача должна быть перведена в состояние "ревью". +b. Задача должна быть перведена в состояние «ревью». c. Должно быть выполнено саморевью задачи, т.е. просмотр своих изменений перед тем, как предложить сделать это другим участникам команды. На этом шаге, как правило, @@ -246,7 +254,7 @@ f. После того, как изменения приняты проверя с последующим удалением своей ветки. g. Задача должна быть переведена в состояние следующее состояние задачи (как правило, -это состояние "готово") после её влития в `dev`. +это состояние «‎готово») после её влития в `dev`. ### 2.3. Ведение журнала изменений (changelog) @@ -262,8 +270,8 @@ c. Для каждого изменения в начале строки дол ``` // Пример описанного изменения - [`DXAPP-571`](https://smekalka.atlassian.net/browse/DXAPP-571) Added - [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware to get alternative to react native - debugger that slows down app during debug + [redux-logger](https://github.com/LogRocket/redux-logger) as redux middleware + to get alternative to react native debugger that slows down app during debug ``` d. Для записей в журнале изменений применяются те же правила по ограничению на длину строки, @@ -334,7 +342,46 @@ g. Все вопросы по ревью обсуждаются наибыстр использовать такой способ коммуникации, при котором ответ затягивается, а соответственно затягивается и ревью. -#### 2.4.4. Противоречия и споры в процессе обзора кода +#### 2.4.4. Процесс обзора задач, не связанных с системой управления кодом (Github, Gitlab) + +Такие задачи, как документирование в Notion, Confluence и пр. + +Мотивация:\ +Сократить количество отвлекающих воздействий на автора изменений до 1 (в позитивном сценарии), +меньше отвлекая друг друга от работы. + +1. Рецензент в процессе обзора кода фиксирует свои замечания и пожелания в комментариях +под задачей в канале `review`. + + **Формат** + + Сообщение: + > [краткое описание задачи] \ + [ссылка на задачу] + + Комментарии: + > 1 [Замечание или пожеление 1] \ + 2: [Замечание или пожеление 2] \ + N: [Замечание или пожеление N] + +2. После того, как рецензент завершил фиксирование замечаний, он уведомляет об этом автора задач. +А также переводит задачу в статус «открыта» / «переоткрыта», чтобы другие рецензенты делали +обзоры только на непросмотренные задачи. + +3. Автор задачи знакомится со списком замечаний и пожеланий, формирует список вопросов и обсуждает +их с рецензентом. В начале работы над исправлениями по замечаниям автор задачи меняет статус задачи +на соответствующий рабочему. + +4. Автор задачи отмечает сделанные задачи смайлом: ✔ + +5. После того, как автор задачи завершил улучшение проделанной работы и отметил все пункты как +завершённые, он также сообщает об этом рецензенту. + +6. Рецензент отмечает смайлом ✔ те пункты, в которых он уверен, что они исправлены или не нуждаются +в исправлении. Если рецензент с чем-то не согласен, он уведомляет автора задачи о необходимости +её доработать, и процесс повторяется с шага 2. В другом случае задача переводится в состояние «готово». + +#### 2.4.5. Противоречия и споры в процессе обзора кода a. Споры и затягивание обзора кода не допускаются. @@ -348,7 +395,7 @@ c. Не допускается повторных обсуждений по по уже принятых правил написания кода. Это не исключает возможности договориться о новых при хорошем уровне коммуникаций и взаимопонимания в команде. (см. пункт выше) -#### 2.4.5. Правила для участников, проверяющих код +#### 2.4.6. Правила для участников, проверяющих код a. Закрыв файл после проверки, вы тем самым полностью принимаете этот вариант так, как будто это написали вы. А так же вы уже несёте ответственность за уровень качества и работоспособности кода. @@ -359,7 +406,7 @@ b. Если что-то правится быстро (5-10 секунд) и о то можно уведомить автора об этих изменениях, чтобы он получил дополнительный опыт и учитывал его в дальнейшей работе. -#### 2.4.6. Состав участников обзора кода +#### 2.4.7. Состав участников обзора кода a. Запрос на влитие изменений должен быть сделан на двух участников команды, которые в состоянии понять смысл изменений и подтвердить их корректностью. Не может считаться @@ -393,7 +440,7 @@ d. [?] В качестве варианта ревью, возможно, сто автором с пояснениями. Это может сократить время, необходимое участникам команды на осмысление кода каждому в отдельности. -#### 2.4.7. Написание комментариев в процессе обзора кода +#### 2.4.8. Написание комментариев в процессе обзора кода a. Критиковать код, а не автора. Помните, раз вы увидели этот код - то он уже тоже ваш. @@ -416,7 +463,7 @@ d. Не писать в побудительном наклонении: `Исправь А на Б` ``` -#### 2.4.8. Отношение к комментариям в обзоре кода +#### 2.4.9. Отношение к комментариям в обзоре кода a. Не оправдываться в комментариях: `А, да, точно, я затупил`, `Я невыспался` и т.д. @@ -429,17 +476,17 @@ c. Запомнить ситуацию, усвоить полученный оп d. Если не согласны - обсудить. Не использовать агрессивно-защитные высказывания и пассивное игноирование. Держать в голове всегда цели обзора кода и команды в целом. -#### 2.4.9. Проверка стиля кода +#### 2.4.10. Проверка стиля кода a. У каждого участника должны быть настроены все автоматизированные средства для автоматической проверки и исправлений кода. b. В результате необходимо стремиться к отсутствию комментариев, касающихся стиля кода. -#### 2.4.10. Приоритет обзора кода +#### 2.4.11. Приоритет обзора кода a. Обзор кода не должен задерживать поток задач, соответственно должен быть приоритетным -как для просматривающего изменения, так и для автора изменений. Задача в состоянии "ревью" +как для просматривающего изменения, так и для автора изменений. Задача в состоянии «ревью‎» имеет наивысший приоритет, если по какой-то причине явно не было принято другое решение в виде исключения. @@ -450,7 +497,7 @@ b. Идеальное время влития изменений равно ну c. Запрос на влитие изменений не должен отправляться на участников команды, которые не могут своевременно выполнить обзор кода. -#### 2.4.11. Учёт при планировании +#### 2.4.12. Учёт при планировании a. Время на ревью и исправления должно учитываться при планировании задач на итерацию. @@ -868,4 +915,4 @@ b. Не более ли качественный вариант решения c. Классифицировать встречи. К каждому типу можно было бы прописать общие требования ко встрече, участникам, чтобы не нужно было одно -и то же писать во встречах такого типа. \ No newline at end of file +и то же писать во встречах такого типа.