Организация процесса разработки, встреча №1

09.08.2018

На встрече определили список интересных тем и проголосовали за каждую:

Оценка эффективности программистов (12 голосов)
Обмен информацией (11 голосов)
Качество кода (11 голосов)
Оценка задач (11 голосов)
Уровень соискателей и отсутствие соискателей (10 голосов)
Инструментарий (7 голосов)
Организация работы удалённых программистов (7 голосов)
Как справляться с бардаком (6 голосов)
Требования (6 голосов)
Перевод теории в практику (6 голосов)
Выбор стека технологий (4 голоса)
Унификация процесса (4 голоса)
Выживание в не ИТ-компании (3 голоса)
Continous Delivery (3 голоса)
Вовлечённость людей (2 голоса)
Самоорганизация (2 голоса)

Обсудить успели три: обмен информацией, качество кода, оценку задач.

Обмен информацией

Прежде всего договорились, о какой информации речь. Внутри команды важными мы считаем сведения о

Предметной области
Обосновании технических решений
Серьёзных ошибках и их причинах

Предметная область

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

Обоснования технических решений

Это касается решений, которые балансируют на грани паттернов и анти-паттернов, например, анемичной модели (anemic model) и локатора служб (service locator). Обоснование таких решений — важная информация для программистов.

Серьёзные ошибки и их причины

Сленговое название посмертный снимок (post mortem). Посмертные снимки содержат описание симптомов (что было не так), фактическую причину краха и причину появления ошибки.

Пример. Симптомы: веб-сервис начинает работать заметно медленнее, перезагружается, какое-то время работает быстро, и снова замедляется. Фактическая причина: код создаёт множество объектов и сохраняет ссылки на них, в то время как эти объекты должны быть уничтожены сборщиком мусора. Причина появления ошибки: бездумный copy-past со Stack Overflow.

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

Решения

Обменялись опытом. Набросали такие способы обмена информацией.

Учебный центр совместно со сдачей экзаменов или сертификацией. Может быть организован в крупной компании.
Документация. Очевидно, что устаревшая докуменантация — всё равно, что её отсутствие, поэтому нам надо не просто констатировать важность документации, но и предложить, как поддерживать её актуальность. Плагин Delivery Pipeline для Jenkins визуализирует (документирует) процесс развёртывания приложения. Swagger Conformance проверяет соответствие REST API схеме Swagger. Программа doctest тестирует примеры из документации. Если код перестанет возвращать то, что написано в документации, вы об этом узнаете. Одним из эффективных способов повышения качества документации мы признали наличие технического писателя в команде.
Модульные тесты и приёмночные тесты. Они не всегда говорят, почему функция работает так, как она работает. Но они говорят, как именно работает функция. В идеале приёмночные тесты также должны быть автоматизированы (FitNesse).
Коллективное владение кодом очень способствует распространению знаний в команде. Можно практиковать парное программирование (pair programming) и обзор кода (code review). Для повышения качества code review можно применять двойной обзор: сначала первый программист пишет код, затем второй программист оценивает его, а после этого третий программит оценивает качество оценки.
Планёрки (stand-up meetings) и ретроспективы. А также курилки, совместные обеды и прочее неформальное общение.
Демонстрации и доклады внутри команды, когда один из программистов рассказывет другим программистам об аспектах системы.
Программирование толпой (mob programming). Совместный рефакторинг сложного кода, запланированный и включённый в спринт. Можно проводить раз в неделю, например, по пятницам.
Технические средства для организации группового общения, а именно Slack, Telegram, Gitter, Skype и так далее.
Программа адаптации новых программистов (onboarding).

Качество кода

Плохой код и технический долг замедляют скорость работы над проектом. Что делать команде для повышения качества работы?

Статические анализаторы (lints), как общеизвестные, так и самописные. Никита Соболев рассказал об анализаторе для обнаружения неговорящих имён переменных, таких как data, result и value.
Согласованные представления о хорошем коде внутри команды. На практике достаточно, чтобы самые опытные разработчики команды договорились о том, что такое хорошо, и что такое плохо.
Обзор кода (code review). Совет: привлекайте к обзору самого неопытного разработчика. Если он понимает код, значит, код действительно хорошо написан.
Парное программирование (pair programming). Не обязательно всегда и во всём, достаточно время от времени и особенно при разработки сложных частей.
Кодогенерация и аспектное программирование. Плохим может быть однотипный код. Бороться с однотипностью помогают средства кодогенерации и аспектного программирования, в том числе самописные, разработка которых включается в спринты.

Оценка задач

С оценкой задач в индустрии большая беда. Даже крупнейшие компании не могут предсказать, сколько времени займёт реализация проекта. Мы не исключения. Как будем справляться?

Вариант номер один — не предсказывать. Если у нас есть фиксированное время и фиксированный бюджет, давайте сделаем переменной величиной набор возможностей (FFF — Fix time, Fix money, Flex scope). Для этого нам потребуется дорожная карта с приоретизацией требований. Сначала делаем самые важные, а неважные оставляем на потом: даже если мы не успеем всё, мы успеем самое нужное.
Внедряем непрерывную интеграцию (continuous integration) и непрерывное развёртывание (continuous delivery). На финальную интеграцию уходит непредсказумое время, если делать её постоянно, то система всегда готова к поставке.
Назначаем крайний срок (deadline) для демонстрации продукта (demoday). Не забываем про промежуточные сроки (milestones). Классический тайм-менеджмент всё-таки важен.
Используем инструментарий для точной оценки затраченного времени. Автоматизируем процесс собственными скриптами, например, по имени ветки в git определяем, к какой задаче относить затраченное время.
Опираемся на опыт, описанный Джоэлем Спольски в статьях Планирование программного обеспечения малой кровью и Доказательное планирование.