Резюме зустрічі 27.01.16
[00:00] Можно ли конфигурационный файл xml спринга разбить на составные, но оставить в нем ссылки на них, чтобы он был как одно целое? Например один и тот же бин нужен в двух конфигах, но если прописать его и там и там, то будет нарушение принципа DRY, а так можно было бы в обоих конфигах всего лишь прописать ссылку на отдельный xml с этим бином.
Если можно то как?
Можна і треба. У нас пошарове розмежування проекту. Тому має сенс на кожен шар свій контекст. Типу, persistence-contex, service, etc.
Типи архітектур проектів (принцип за яким відбувається поділ на пакети):
- леєрна (вертикальна) (
controller,dao,service,...); - за фічами (
user,event,subscribe,...);
Архітктура з розподілом за фічами зручна тому, що з неї легко зробити мікросервіси.
[03:00] В последнем ревью ты указал в качестве разделителя в именах в .properties точку. однако так как на Travis и OpenShift эти свойства хранятся в переменных окружения, а в переменных окружения нельзя использовать точку, то можно ли использовать знак подчеркивания вместо точки, либо есть другое решение?
Таке обмеження означає платформозалежність - це мені не подобається. А на практиці я не зустрічався. Тому варто окремо почитати.
Підхід з environment variables поганий, тому що колізія змінних, коли в нас на одному сервері запущено декілька апплікейшенів.
Workflow [6:45 - ]
В цьому розділі описані процеси, котрі повинні дотримуватись всіма учасниками команди відповідно до ролей.
1. Developer [9:45]
1.1. Початок роботи над задачею:
1.1.1. У девелопера може бути тільки одна задача в статусі In Progress;
1.1.2. Перед початком виконання задачі бере тікет із колонки Backlog:
1.1.2.1. Перш за все треба брати свої задачі, які були повернуті із рев'ю або були заблоковані
1.1.2.2. Брати задачі, вже назначені на когось, не дозволяється;
1.1.3. Якщо задача повернулась з рев'ю і в неї багато зауважень, треба розбити її на декілька, відповідно до скоупа (4 години);
1.1.4. Призначає себе на цю задачу;
1.1.5. Переносить задачу в колонку In Progress;
1.1.6. Гілку з задачею треба називати так: #123-very-important-feature;
1.2. Робота над задачею:
1.2.1. Повідомлення в коммітах повинні бути такого формату: #123: commit message;
1.2.2. На задачу повинні бути юніт-тести;
1.3. Якщо задача заблокована іншою [24:25]:
1.3.1. Додає коментар до своєї задачі blocked with #123 @AndriyBaibak @author-of-blocker pls fix it ASAP, тобто повідомляє PM'а та автора задачі-блокера про проблему;
1.3.2. Переводить заблоковану задачу в Backlog;
1.4. Якщо не вдається вирішити задачу:
1.4.1. Треба попросити допомоги у партнера;
1.4.2. Звернутисть в загальний чат;
1.4.3. Якщо робота вихлдить за рамки скоупа задачі - треба додати коментарі додати //TODO або @todo, доробити задачу частково; [56:36]
1.4.4. Створити тікети на основі todo [1:06:20]
1.4.5. Якщо є тести які не проходять, треба додати до них @Ignore;
1.5. Завершення роботи над задачею:
1.5.1. Створює пулл-реквест;
1.5.2. Для з'єднання пулл-реквеста з задачею в його опис додає connect to #123 (№ задачі);
1.5.3. Переносить задачу з колонки In Progress в Review;
1.5.4. В канал #reviewme додає лінк review me <link to PR>; Нічого крім запитів в цьому каналі постити не дозволяється!
1.5.5. Після мерджа або закриття рулл-реквеста видаляє із #reviewme запит на рев'ю;
1.5.6. Переходить до пункту 1.1;
1.6. Після того, як задача змерджилась в мастер, проводить демо (канал #demos);
1.7. Приймає участь у колективному code-review;
2. Project Manager - Андрій Байбак, @AndriyBaibak [20:40]
Зона відповідальності - щоб задачі швидше проходили від стврення до завершення;
2.1. Якщо пулл-реквест довго не розглядається, нагадує рев'юверам, що треба провести рев'ю; запити на рев'ю знаходяться в каналі #reviewme;
2.2. Нагадує девелоперу, що його задача блокує іншу;
3.1. Проводить рев'ю по запиту з каналу #reviewme:
3.1.1. Для того, щоб задача пройшла рев'ю, необхідно мінімум 2/3 голосів;
3.1.2. Рев'ювер не може голосувати за свою задачу;
3.2. В разі наявності зауважень:
3.2.1. Повертає задачу в Backlog;
3.3. В разі відсутності зауважень:
3.3.1. Робить мердж;
3.3.2. Переносить задачу в колонку Ready;
3.3.3. Назначає Віктора на задачу;
4.1. Scope задачі повинен бути максимум 4 години. [27:20]
4.2. Якщо задача більше, ніж на 4 години, варто розбити її на дрібніші;
4.3. Мердж між гілками, які не пройшли код-рев'ю не дозволяється; [26:25]
Демонстрація роботи над проектом GSR [39:00]
- ствоорення тесту; [40:00]