[1/2] Экстремальное программирование: постановка процесса (Extreme Programming Applied: Playing to Win) (Рубрика Engineering)
Этот пост заканчивает разбор книги из начала 2000х, рассказ про которую я начал в предыдущем посте. Здесь я планировал рассказать про шесть оставшихся практик второй очереди, а также дать материалы для дальнейшего изучения. Ну поехали
- Простой дизайн (Simple Design) - здесь суть в том, чтобы не делать большую архитектуру перед стартом проекта, а проектировать по мере поступления новой информации и требований. Звучит хорошо, но у неопытных ребят это превращается в big ball of mud. В итоге, тут до сих пор есть вопросики о том, а как же правильно проектировать комплексные системы
- Коллективное владение кодом (Collective code ownership) - коллективное владение кодом внутри команд является стандартом де-факто, а вот контрибьютинг в код соседних команд до сих пор не так тривиален - есть такое направление как innersourcing, про которое упоминают при желании уменьшить ожидания и зависимости от других команд. Основная суть как раз в том, чтобы не ждать соседнюю команду, а самому набацать им кода и влить через процедуру merge request. На этом пути есть ряд организаионно-технических проблем, но bigtech компании как-то справляются с ними:)
- Приемочные тесты (Acceptance tessting) - суть в том, чтобы фиксировать ожидания заказчика и писать приемочные тесты, которые выступают как фиксация критериев приема задач со стороны заказчика. Сейчас этот подход чуток расширился до критериев готовности по задачам (definition of done), которые должны быть выполнены прежде, чем элемент бэклога (пользовательская история) будет считаться завершенным.
- Стандарты кодирования (Coding standards) - авторы говорили про стандарты кодирования, которые сейчас автоматизируются на уровне linters. Но если пойти чуть дальше, то стандарты помогают и на уровне использования общих библиотек или стандартизации подходов к проектированию API
- Метафора системы (metaphor) - интересная концепция про использование метафор внутри системы и общего языка для общения технарей и бизнес-заказчиков. Лет через 5 после выпуска этой книги вышла книга "Domain-Driven Design: Tackling Complexity in the Heart of Software", в которой Эрик Эванс представил концепцию DDD и ввел термин ubiquitous language
- Сорокочасовая рабочая неделя (40-hour week) - здесь авторы говорят про отсутствие переработок и нормальный work/life balance. Интересно, что уже тогда эта тема была важна и вошла в набор принципов.
Отдельно отмечу, что в книге очень много говорится о том, как продать XP менеджерам и разработчикам, а также как эти практики внедрять в процесс работы постепенно и бороться с сопротивлением. В итоге, книга сейчас уже не особо актуальна технически, но сами концепции были приняты на вооружение индустрией.
P.S. Если этот обзор понравился, то рекомендую почитать книги
- Modern software engineering - это недавняя книга Дейва Фарли, про которую я уже писал. В этой книге Дейв рассказывает примерно про эти же практики, но в приложении к текущему уровню индустрии
- Accelerate - это книга 2017 года от Nicole Forsgreen, Jez Humble и Gene Kim, про которую я уже писал. В этой книге авторы рассказывают результаты DevOps Reports за 5 лет и показывают как инженерные практики помогают бизнесу двигаться быстрее
- Tidy First?: A Personal Exercise in Empirical Software Design (Чистый дизайн. Практика эмпирического проектирования ПО) - недавняя книга Кента Бека, создателя eXtreme Programming, про которую я уже рассказывал. В этой книге Кент подробнее ракрывает суть принципа Simple Design:)
- A philosophy of software design - книга Джона Остерхута, создателя алгоритма консенсуса Raft, про которую я уже рассказывал. В этой книге Джон круто раскрывает про свой подход к дизайну софта и важности инженерных практик
#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE