David Farley - Modern Software Engineering
Прочитал книгу David Farley “Modern Software Engineering”, 2022 год. Эту книга рекомендуется в числе прочих в курсе “Системная инженерия” в ШСМ. Кроме того мне независимо посоветовал ее прочитать коллега. Двойное попадание, хорошо. Автор книги являлся руководителем разработки биржи LMAX, а в свое время библиотечка LMAX Disruptor мне прям очень зашла, там были очень интересные вещи про то как устроено конкурентное программирование, например, концепт Mechanical sympathy.Получил несколько важных инсайтов. Пересмотрел, как надо программировать.В книге рассказывается про программную инженерию с упором именно на инженерию. Под этим автор понимает в первую очередь нацеленность на результат, на то чтобы “получать более качественный продукт быстрее”. Далее предлагаются несколько сильно связанных между собой практик, помогающих этому. Контринтутивно, но оказывается, что нет компромисса между “лучше” и “быстрее”, это ложный компромисс. В реальности команды, которые следят за качеством получают и результат качественнее.Вводятся две метрики: стабильность (stability) и пропускная способность (througput). Оказывается достаточно следить за этими двумя метриками в контексте поставки фич и это позволит улучшить качество продукта и ускорить разработку. Инженерия противопоставляется ремеслу. Ремесленный способ деятельности неточный и его невозможно масштабировать, поэтому важно, в том числе и при создании софта мыслить инженерно. Например, это о том, чтобы стараться автоматизировать все, что можно автоматизировать, о том, чтобы увеличивать точность измерений.Объясняется несколько важных практик: для более быстрого и качественного познания предметной области и для борьбы со сложностьюБыстрое познание
- итеративная разработка
- обратная связь
- инкрементальная разработка
- эмпирицизм
- опора на эксперименты
Борьба со сложностью
- Модульность
- Связность (cohesion)
- Разделение интересов (separation of concerns)
- Сокрытие деталей реализации (information hiding and abstraction)
- Сцепление (coupling)
Магистральной линией с точки зрения конкретных практик в книге является стимулирование использования TDD и Continous Delivery, использование которых поддерживают указанные выше практики.
Про TDD очень интересно. Оказывается ранее я прям неправильно использовал эту технику. Принципиально важно сначала писать тесты и лишь потом код. Если делать в обратном порядке, то вся сила TDD теряется, а вот если сначала писать - то это получается сначала ход на то, как будет код использоваться и лишь потом на создание кода, это очень важно и именно в этом суть TDD. В будущем буду программировать только так. Получается после прочтения этой книги, я поменяю способ с помощью которого программирую. Интересно к какому эффекту это приведет. А сколько еще знаний у меня нет?!
Про Continuous Delivery тоже очень интересно. Вообще автор написал еще несколько книг, где тема непрерывной поставки разобрана более детальна, но и здесь про это немало сказано. Например, автор предлагает релизится несколько раз в день, оптимальная частота по его словам новый релиз каждый час. Также поясняется разница между trunk based development и feature branching development с объяснением почему именно первый хорош.
Все объяснения маппятся на указанные 10 практик для быстрого познания и борьбы со сложностью, которые в свою очередь увеличивают стабильность и пропускную способность, что является базовыми метриками для улучшения качества и скорости поставки продукта.
Наверное еще более важной историей чем TDD стало для меня понимание важности инкрементальной и итеративной разработки. Моя обычная привычка - попытаться сделать все сразу, частенько не справляюсь и потом фрустрирую. В книге дается объяснения почему так происходит - это происходит из-за слишком длинного цикла обратной связи и потери контроля над тем что происходит. Вообще все практики связаны между собой и помогают тому, чтобы цикл обратной связи был меньше. Итеративная и инкрементальная разработка также направлены на это. После прочтения книги в осознание вышло, что это важно не только для софта, но и в многих других предметных областях.
Например, предположим стало понятно, что надо поставить полезную привычку, например такую как ежедневную зарядку. Итеративность говорит нам о том, что надо сразу сделать что-то, некий MVP, который может быть кривой и косой, например, пусть это будет 5 отжиманий в день в случайное время. Потом можно будет сделать это не в случайное время, а по утрам. Инкрементальность и итеративность немножко разные вещи. Итеративность это об изменении системы в целом, например в один момент может стать понятно, что отжимания не очень эффективны и ты меняешь их на подтягивания и добавляешь 10минутную разминку, а инкрементальность о том, чтобы немного улучшить текущую систему, например добавлять 1 отжимание в месяц или улучшить технику чтобы задействовать в отжимании мышцы таза.
Еще один пример. Например хочется научиться хорошо готовить шашлык. Идея купить мангал за 100500 рублей и попытаться приготовить блюдо уровня шеф-повара Мишленовского ресторана не очень здравая. Лучше делать постепенно, улучшая некоторые аспекты, это более надежный вариант. Это выглядит очевидно, но в жизни сплошь и рядом люди пытаются делать всё и сразу.
Итеративность работает на уровне всей системы, например, метод прогрессивного джипега Артемия Лебедева § 167. Метод прогрессивного джипега ровно об этом. Инкрементальность работает на уровне деталей. Это два разных принципа, использовать надо оба. И оба они про быструю обратную связь.
Понравился автор, также подписался на его youtube-канал Continuous Delivery https://www.youtube.com/@ContinuousDelivery, хорошие и понятные видосы о том, как устроены разные аспекты программирования.
Вообще для меня конечно это книга не столько про программную инженерию, как про создание любых вещей, советы и практики по работе со сложностью и познанию мира можно легко адаптировать и использовать для самых разных аспектов деятельности.
Текст также опубликован в личном блоге Telegram: Contact @burganov
как бы это совсем другой майндсет