Итоги семинаров по книге Practice of an agile developer¶

1. Work for Outcome¶

• Оценивать в перерывах, сколько сделано на конечный результат.

• Не пытаться искать виноватого, а попытаться помочь найти настоящую причину проблемы и попытаться помочь с ней.

2. Quick Fixes Become Quicksand¶

• О всех обнаруженных quick fix сообщать другим членам команды

• Если делаешь quick fix, то должны быть веские причины. Сформулировать их.

4. Damn the Torpedoes, Go Ahead¶

• Всегда полностью разбираться в обнаруженных проблемах

• Тратить хотя бы 5 минут на поиск решения найденной проблемы

5. Keep Up with Change¶

• Каждый день знакомиться с новыми технологиями

6. Invest in Your Team¶

• Еженедельно должны проводиться такие семинары, где каждый по очереди выступает перед командой

7. Know When to Unlearn¶

• Как только привычки перестают быть удобными, нужно искать новый инструментарий, технологии (вырабатывать новые привычки).

• Из старых привычек брать идеи, которые в них закладывались

8. Question Until You Understand¶

• Добиваться полного понимания вопроса (пока не изчезнет ощущение, что что-то непонятно)

• 5 раз спрашивать "Почему?"

9. Feel the Rhythm¶

• Каждый день просматривать треккер

• Оценивать, что я хочу получить за день и выписать это на листочек (чтобы по ходу дня зачеркивать)

• Поддерживать ритмичность для задач (выписать план решения задачи)

• Все, что не входит в решение текущей задачи, записывать куда-то и продолжать решать свою задачу

10. Let Customers Make Decisions¶

• Решить, что ты должен решать, а что не должен (определиться, когда тебе нужно спросить решение у заинтересованного лица)

• Когда задаешь вопрос заинтересованному лицу, предоставить ему весь спектр возможных решений

• Если какое-то решение кажется предпочтительным, то можно аргументировать это заинтересованному лицу, но не решать за него

11. Let Design Guide, Not Dictate¶

• Дизайн использовать как карту, а не четкий план решений

• При добавлении класс писать в комментарии как его использовать и для чего он нужен

• В начале или конце дня смотреть javadoc затронутых классов. Проверить, все ли понятно из комментариев

12. Justify Technology Use¶

• Каждому узнавать о новых технологиях (практика Keep Up with Change)

• Использовать новые технологии, только когда для этого есть причина

• Спрашивать коллег об известных для них технологиях для решения проблемы

13. Keep It Releasable & 14. Integrate Early, Integrate Often¶

• В основной ветке НИКОГДА не должно быть сломанной сборки.

• Вносить изменения в основную ветку, а если потребуется сильные архитектурные изменения или если будут добавлены большие фичи, то создавать для этого отдельную ветку.

• Если приходится делать большой коммит, а короткие будут ломать сборку, то создать отдельную ветку, делать эти небольшие коммиты и потом слить это с основной веткой.

15. Automate Deployment Early¶

• На индивидуальном уровне: нужно писать скрипты в следующих случаях

  • требуется выполнить последовательность действий > 3 раз
  • требуется выполнить последовательность действий через длительный промежуток времени (есть вероятность забыть)

• На уровне команды:

  • замечать, когда нужна автоматизация, которая сократила бы время разработки и развертывания
  • когда обнаружились новые иструменты, автоматизирующие текущий процесс, сообщать это команде

• Нужно иметь подготовленное окружение для разработки (чтобы быстро вводить новых людей) и для развертывания (чтобы быстро показывать наработки заказчику)

15. Get Frequent Feedback Using Demos & 16. Get Frequent Feedback Using Demos¶

• Не показывать заказчику артефакты во время промежуточных демостраций. Вместо этого:

  • скрывать компоненты, ведущие к не реализованному функционалу
  • убирать действия с нажатия на эти компоненты

• Смотреть глазами пользователя на интерфейс

• Стараться общаться с заказчиком раз в 2 недели (или чаще, в зависимости от возможности заказчика общаться)

17. Use Short Iterations, Release in Increments¶

• Разбивать большую задачу (функционал на релиз, например) на маленькие итерации, чтобы в конце каждой можно было посмотреть на функционирование продукта.

18. Fixed Prices Are Broken Promises¶

• Эта практика плохо с нами коррелируется, т.к. у нас нет как таковых заказчиков, которым мы устанавливаем цену. Она была сугубо образовательной.

19. Put Angels on Your Shoulders¶

• В местах, с которыми работаем искать места, где можно добавить тесты, и предложить их туда добавить.

20. Use It Before You Build It¶

• При написании чего-то нового, при желании проявить инициативу и попробовать разрабатывать с помощью TDD.

21. Different Makes a Difference¶

• Писать и запускать тесты на все возможные платформы (для нас: на всех доступных разработчикам устройствах).

• Перед каждым релизом, как правило, нужно тестировать одни и те же вещи (для них нужно написать тесты какому-нибудь младшекурснику):

  • доступность всех экранов;
  • поддержка изменения ориентации на всех экранах;
  • доступность платного функционала для купленной версии и ее отсутствие для бесплатной;

22. Automate Acceptance Testing¶

• Приемочные тесты нужны, чтобы заказчик вводил свои данные (создавал данные для тестирования) и проверял корректность работы системы. Для нас эта практика не применима, так как у нас нет явного заказчика. Ближе всего к данным тестам являются end-to-end тесты.

23. Measure Real Progress¶

• Разработчикам необходимо самостоятельно оценивать время, необходимое на решение задачи, и записывать его в поле "Estimated time" каждой задачи. Это необходимо делать как только задача переводится в состояние "In progress".

24. Listen to Users¶

• Нужно организовывать каналы обратной связи и внимательно слушать пользователей, какой, казалось бы, бред они не говорили.

• Особое внимание уделять вещам, о которых пользователи говорят часто.

25. Program Intently and Expressively¶

• Читать книжки по языкам, с которыми работает разработчик.

• Делать ревью собственного кода перед коммитами более детально, как будто ревью чужого кода.

• Не накидываться на рефакторинг кода и не откладывать его. Оценивать, сколько он может занять времени, сколько даст полюсов его проведение (обсуждать с коллегами).

26. Communicate in Code¶

• Цель: всегда знать, что делает код и как его использовать.

• Комментарии внутри реализации нужны лишь когда в коде не очевидное место или когда намеренно был добавлен костыль (в этом случае подробно описать проблему, дать сопутствующие ссылки).

• Плохие глаголы в названиях: do и get.

• В качестве примера правильных комментариев смотреть комментарии Дениса для проекта Blood Pressure Diary.

• Советы по именованию переменных и методов - из книжки "Читаемый код".

• В именах переменных отвечать на вопрос "Зачем переменная?", а не на вопрос "Что переменная обозначает?".

27. Actively Evaluate Trade-Offs¶

• Trade-Off - это прикладывание усилий к тому, что стало не актуальным для проекта.

• Чтобы замечать trade-Off и не позволять тем самым выходить за рамки сроков, нужно периодически оценивать свои задачи в рамках всего проекта. Как только обнаружиться, что текущая деятельность начала занимать слишком много времени, нужно сообщить об этом менеджеру и совершить перерасчет времени.

• Оценивать свои задачи в рамках всего проекта предполагается раз в день, перед началом трудовой деятельности.

• Важно оценивать задачу на нарушение сроков не тогда, когда была закончена задача и осознана ее бесполезность, а в течении выполнения самой задачи.

28. Code in Increments¶

• Цель практики - делать небольшие добавления кода, сократить время, когда невозможно запустить результат программирования, кроме запуска дополнительно убедиться, что код корректный с помощью тестов.

• Чтобы добиться того, чтобы добавления кода были на самом деле небольшими, нужно хорошо декомпозировать задачу, делая ее подзадачи независимыми друг от друга.

• Для этого хорошо подходить практика управления временем, называемая Помидор (например, см. http://mydebianblog.blogspot.ru/2012/08/pomodoro.html).

29. Keep it Simple¶

• Есть 2 проблемы: реализация, учитывающая не все требования (чересчур упрощенная) и чрезмерно сложная реализация (когда берем несколько требований за раз и пытаемся их все сразу реализовывать).

• Мы рассмотрели 2 способа борьбы с этим:

  • при проектировании рассмотреть альтернативную реализацию, оценить плюсы и минусы
  • использовать методологию TDD (при этом не забывать постоянно проводить refactoring)

• Нужно иметь внутренний сигнал, говорящий, что пора делать рефакторинг (для того, чтобы услышать этот голос, лучше делать коммиты после перерыва, чтобы взглянуть на свой код со свежим взглядом)

30. Write Cohesive Code¶

• Цель - писать небольшой связный код

• Для этого думать о предназначении класса, его цели (должна быть только одна)

31. Tell, Don’t Ask¶

• Цель - не смешивать бизнес логику, а концентрировать ее в отдельных местах. Для этого полезна инкапсуляция

• В классах предоставлять высокоуровневый интерфейс

• Когда появляются классы, которые просто хранят данные без какой-либо логики, то это сигнал о том, что бизнес-логика находится в другом месте. Она должна быть именно в этом классе (исключение - ORM)

• Для того, чтобы не возникало таких классов, нужно проектировать классы с концентрацией на цель этого класса, а не на хранимые им данные

32. Substitute by Contract¶

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

• Выделить проектирование в отдельную активность, а не смешивать его с реализацией

33. Keep a Solutions Log¶

• TODO (всем): нужно ввести подобную базу знаний, но для этого нужно решить, что документировать, а что нет, а также где это записывать

  • сложну логику - не нужно
  • высокоуровневые решения, детали (выбор в использовании API, технологий и т.д.) - нужно
  • баги в 3D-party коде, которые не описаны в документации к ней (описывать на common information в соответствующем разделе).

• TODO (Тимофеев): предложить объединенный формат вики для удобного расположения нового материала и поиска нужной информации

34. Warnings Are Really Errors¶

• Предупреждения являются потенциальным местом для ошибок, поэтому они опасны

• Предупреждения говорят о не корректном использовании языка

• Можно использовать дополнительные иструменты (lint, cppchecker, ...) для получения дополнительных предупреждений

• Настраивать инструменты для использования предупреждений как ошибок легче в начале проекта, что и стоит делать

35. Attack Problems in Isolation¶

• Использовать сторонние инструменты, такие как инструмент для отслеживания утечек памяти, историю изменений или unit-тесты для изолирования и поиска проблемы

• Если программа работает с данными, полученными из внешних источников, то сначала проверять ее, потом уже свой код, работающий с этими данными

• Поддерживать код модульным, чтобы легче было изолировать ошибки

• Когда обнаружена ошибка, проводить рефакторинг для изоляции кода уже поздно - нужно сначала найти ошибку, подтвердить ее тестом, исправить, а уже потом проводить рефакторинг

36. Report All Exceptions¶

• Отлавливание всех подряд исключений с помощью IOException или Throwable является плохой практикой - помимо ожидаемых исключений мы можем поймать то, которое не ожидали и отладка приложения в этом случае заметно усложниться

• Пустые обработчики исключений также являются плохой практикой. Вывод debug-сообщений внутри них является столь же плохим

• Поимка исключения и возвращение функцией null также плохо, так как в этом случае теряется часть информации об исключительной ситуации

37. Provide Useful Error Messages¶

• Есть три уровня ошибок - пользовательские, проблемы окружения, проблемы в коде

• Первые две должны решаться корректным и адекватным выводом сообщения для пользователя что произошло и, возможно, как это исправить

• Ошибки в коде должны отправляться разработчику, причем желательно автоматическим способом (например, автозаполненным электронным письмом).

38. Schedule Regular Face Time¶

• Ежедневные встречи (или через день) с целью информирования о задачах каждого члена проекта может быть полезным, так как дает всей команде представление о том, какое состояние у проекта в целом

• Данные собрания должны быть как можно короче, чтобы не отнимать у команды много времени. Все детальные обсуждения должны быть после подобных совещаний

• Подобные встречи нужны для того, чтобы:

  • Избежать "неожиданностей", которые были сделаны другими членами команды
  • Оценивать свой прогресс по краткосрочным задачам

39. Architects Must Write Code¶

• Все разработчики должны быть вовлечены в решение архитектурных вопросов, при возникновении сложностей, разработчики должны консультироваться с архитектором и решить проблему совместно с ним

• Сам архитектор должен быть вовлечен в процесс написания кода, чтобы как можно раньше заметить:

  • не правильное использование кода
  • момент, когда код перестал удовлетворять изначальным требованиям к программе

40. Practice Collective Ownership¶

• Совместная работа над частами проекта нужна для того, чтобы:

  • разрушать мнение разработчиков, что они пишут "идиальный код"
  • учиться всей командой писать хороший код
  • узнавать другие части системы, чтобы быть готовым работать с ними
  • находить недостатки своего кода при объяснении

• При нахождении плохого кода другого участника необходимо сообщить об этом остальной команде, возможно на ежедневных собраниях

• Изоляция разработчиков - явный признак нарушения данной практики

• Для того, чтобы разработчики узнавали систему и новые технологии, можно их периодически менять местами, чтобы они работали с большинством частей системы

41. Be a mentor¶

• Можно быть активным либо пассивным ментором. Пассивный отвечает только лишь тогда, когда его спрашивают, активный сам начинает давать советы, когда видит, что человек мучается

• Каждый может быть ментором, важно понимать в каких именно областях

42. Allow People to Figure It Out¶

• Для того, чтобы дать хороший совет, нужно:

  • Понять вопрос самостоятельно
  • Дать совет для того, чтобы спрашивающий сам нашел ответ
  • Проверить, понял ли спрашивающий твой совет

• Можно давать непосредственный ответ, если спрашивающий уже потратил некоторое время на его поиски, шел в правильном пути (возможно по твоему совету), но не дошел до конца

• Если все-же был дан ответ, а не совет, то его нужно сопроводить объяснением. Это помогает для:

  • самостоятельного более глубокого понимания проблемы
  • поможет спрашивающему понять ситуацию и, возможно, больше не српашивать
  • проверить, правильно ли ты сам понял ситуацию

• когда есть готовое решение, возможно, стоит указать на него, но не объяснять, чтобы спрашивающий сам разобрался и, возможно, что-то понял

43. Share Code Only When Ready¶

• Не стоит использовать репозиторий не по его предназначению: делать не доделанные коммиты в основную ветку или делать слишком редкие коммиты

• Если планируется добавить функциональность, которая может сломать приложение, ее следует добавлять в новую ветку

• Если планируется провести рефакторинг кода, то ни за что нельзя его делать в отдельной ветке. Нужно вместо этого написать тесты на исправляемую часть кода и править ее в основной ветке

• Если в основной ветке что-нибудь сломалось, то это нужно исправить незамедлительно, чтобы другие разработчики тоже могли видеть, не ломают ли их коммиты что-нибудь. Если исправить бысто не удается, то нужно обратить изменения и делать эксперименты в отдельной ветке

• Ветки могут помочь при работе с начинающими программистами, когда их код предварительно нужно проверять перед добавлением в основную ветку

44. Review code¶

• Обзор кода, как и тесты, помогают улучшить его поддержку. Разница между ними в том, что они помогают найти разного рода ошибки.

• Обзор кода помогает увидеть более ошибки в логике, архитектуре, он нацелен на улучшение читаемости кода (а также комментариев).

• Обзор кода помогает найти ошибки, которые которые сложно или невозможно обнаружить при помощи тестов (ошибки работы с памятью, ошибки, связанные с пользовательским интерфейсом, ошибки, реализация тестов для которых очень трудозатратна, а польза от их написания не велика).

45. Keep Others Informed¶

• Практика говорит, что нужно делиться информацией: о своем прогрессе; другую относящуюся к проекту информацию.

• Для информирования о своем прогрессе можно использовать треккер, сообщать через IM или e-mail, обновлять wiki-страницу с backlog.

• Для того, чтобы использование треккера и wiki-страницы дало пользу, задачи должны быть разбиты на задачи, которые занимают менее дня.

• Так же для информирования можно использовать звонок по телефону или SMS, но прибегать к этому только в критических случаях: когда ты блокируешь себя или коллег; когда возможен сдвиг deadline; когда задача имеет самый высокий приоритет и должна быть решена очень быстро.

• Для сообщения другой важной информации по проекту можно использовать специальные собрания, сообщать данную информацию по рассылке (e-mail, RSS)