63 / 94
Scrum и XP: заметки с передовой
63
Чтобы это всё заработало, пришлось потратить
уйму времени
, но, поверьте мне, это того стоило.
Совместное владение кодом (Collective code ownership)
Мы выступаем за совместное владение кодом, хотя ещё не все наши команды внедрили у себя эту
практику. На собственном опыте мы убедились, что парное программирование и постоянная смена пар
автоматически увеличивают уровень совместного владения кодом. А команды, у которых совместное
владение кодом на высоком уровне, доказали свою высочайшую надёжность. К примеру, они никогда не
проваливают спринты из-за того, что у них кто-то заболел.
Информативное рабочее пространство
У всех команд есть доступ к доскам и незанятым стенам, которыми они действительно пользуются. Во
многих комнатах стены завешаны всякого рода информацией о продукте и проекте. Самая большая проблема
у нас – постоянно накапливающееся старье на стенах. Уже подумываем завести роль "домработницы" в
каждой команде.
Хотя мы и поощряем использование доски задач, еще не все команды внедрили их (см. стр. 43"Как мы
обустроили комнату команды")
Стандарты кодирования
Недавно мы начали определять стандарты кодирования. Очень полезно – жаль не сделали этого раньше.
Это не займёт много времени, начни с простого и постепенно дополняй. Записывай только то, что может быть
понятно не всем, при этом, по возможности, не забудь сослаться на существующие материалы.
У большинства программистов есть свой индивидуальный стиль кодирования. Мелкие детали: как они
обрабатывают исключения, как комментируют код, в каких случаях возвращают null и так далее. В одних
случаях эти различия не играют особой роли, в других могут привести к серьёзному несоответствию дизайна
системы и трудно читаемому коду. Стандарты кодирования – идеальное решение этой проблемы, если они,
конечно, регламентируют важные моменты.
Вот небольшая выдержка из наших стандартов кодирования:
•
Вы можете нарушить любое из этих правил, но на то должна быть веская причина и это должно
быть задокументировано.
•
По умолчанию используйте стандарты кодирования Sun:
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html•
Ни при каких обстоятельствах не перехватывайте исключения без сохранения полного стека
вызовов программы (stack trace), либо повторной генерации исключения (rethrow). Допустимо
использование log.debug(), только не потеряйте стек вызовов.
•
Для устранения тесного связывания между классами применяйте внедрение зависимостей на
основе сеттеров (Setter Based Injection) (разумеется, за исключением случаев, когда такое
связывание просто необходимо).
•
Избегайте аббревиатур. Общеизвестные аббревиатуры, такие как DAO, допустимы.
•
Методы, которые возвращают коллекции или массивы, не должны возвращать null. Возвращайте
пустые коллекции и массивы вместо null.
Устойчивый темп / энергичная работа
Множество книг по Agile-раз аботке программного обеспечения утверждают, что затянувшаяся
переработка ведёт к падению продуктивности.
После некоторых не вполне добровольных экспериментов на эту тему, я могу только согласиться с этим
всем сердцем!