{"id":14284,"url":"\/distributions\/14284\/click?bit=1&hash=82a231c769d1e10ea56c30ae286f090fbb4a445600cfa9e05037db7a74b1dda9","title":"\u041f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0444\u0438\u043d\u0430\u043d\u0441\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0430 \u0442\u0430\u043d\u0446\u044b \u0441 \u0441\u043e\u0431\u0430\u043a\u0430\u043c\u0438","buttonText":"","imageUuid":""}

Future retrospective

Возникало у вас ощущение после выполнения задачи, что можно было сделать лучше? А часть и вовсе пропустить, сделав ход конем? Что-то затормозило или ускорило процесс? Если да - добро пожаловать! Обсудим это с моим коллегой Иваном Дьяченко.

Вам понадобится: тишина, спокойствие, и 20 минут времени.

Итак:

1. Устройтесь в кресле или на диване. Можно лечь, расслабиться и закрыть глаза.

2. Представьте задачу и срок выполнения.

3. Набросайте небольшой план реализации, 3-4 пункта.

4. Теперь, что обозначенный срок вышел и задача выполнена. Вы радуетесь, коллеги жмут руку, а начальник выписывает премию :)

5. Далее, вы рассказываете более опытному коллеге о том, как вы делали эту задачу. Вспоминайте максимально подробно. Коллега будет задавать уточняющие вопросы и спрашивать нюансы.

6. Во время рассказа и свершится магия.

Начнет всплывать все незапланированное. Приведу пример. Задача: реализовать перенос значений JSON в базу данных (БД). Срок – неделя.

1. Садимся, расслабляемся и представляем.

2. Есть задача, есть срок. Это будет отдельный сервис, принимающий JSON.

3. Примерный план: пишем сервис, содержащий веб-сервер с эндпоинтом, авторизацией и валидацией JSON. Ему понадобится библиотека для коннекта к БД.

4. Прошла неделя. Сервис готов и все довольны. Ура!

5. Пятничный вечер. Сидим в баре и рассказываем коллеге:

a. В понедельник начал писать сервис с авторизацией.

b. Во вторник сделал адаптер к БД.

c. В среду начал нагрузочное тестирование. Потребовалось делать кастомный десериализатор (des) JSON для скорости. Плюсом узнал, что кол-во коннектов к БД ограничено. Нужен пул соединений.

d. В четверг оптимизировал код. Делал des и пул соединений.

e. В пятницу поставил задачу на девопсов на деплой. Но, один девопс в отпуске, а у другого завал. В итоге, писал деплой сам. Но успел.

В ходе ретро мы выяснили, что задачу на деплой стоило ставить в понедельник. И сразу реализовывать быстрый des и пул коннектов к БД. Чтобы данный подход заработал, потренируйтесь на нескольких реальных задачах. С вами был Иван Дьяченко. Успехов! Готов обсудить в комментариях!

0
Комментарии
-3 комментариев
Раскрывать всегда