Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 (Рубрика Architecture)
Интересное выступление Кента Бека, который когда-то не просто участвовал в подписании Agile Manifesto, а был первым подписантом среди уважаемых джентельментов ... так как шел первым по алфавиту. В этом выступлении Кент, создатель методологии XP (eXtreme Programming) рассказывает о своих экстремальных подходах к дизайну и кратко про книгу "Tidy First?", про которую я уже рассказывал раньше. Если кратко обобщить его рассказ в этом выступлении, то получится следующее
- Начинается все с мотивации к деятельности - у нас есть порядка 3 млрд секунд (~ 95 лет). Если думать об истекающем времени, то есть мотивация не тратить его впустую
- А в разработке софта есть много таких бесполезных вещей, например, автор так троллит тему с документацией:)
- Когда-то давно автор участвовал в панельной дискуссии на конфе с корифеями Edward Yourdon, Larry L. Constantine, что написали книгу "Structured Design". Кент к той панельке прочел эту книгу и решил написать обновленную версию
- Так появилась "Tidy First?", где Кент говорит про то, как наводить порядок в коде. Это позволит разработчику улучшить свое рабочее место и упростить работу.
- Есть идея на вторую книгу "Tidy together?", в которой Кент планирует рассказать про совместную работу инженеров в командах, а в третьей книге будет рассказ про связь технологий с бизнесом
- Основная идея автора - важность дизайна для изменения поведения системы. Софт состоит из фунукций и структуры. Про фукнции думает бизнес, а структура является backbone для этих функций
- Если мы только клепаем фичи, то структура оказывается недоинвестированной - мы создаем технический долг, что усложняет внедрение новых фичей в дальнейшем 8 ) Цель правильного подхода в том, чтобы сбалансировать инвестиции в функции и структуру (автор приводит пример с выпиливанием дублирующего функционала)
- Кент много говорит про социальные эффекты в разработке, про доверие и отвественность, а также разные стимулы и интересы у разных участников процесса. Обычно это называют социотехнической системой.
- Кент много говорит про ограничения документации вида того, что она устаревает быстрее, чем ее обновляют и т.д. но не ясно какую альтернативу он предлагает
- Кент говорит, что в разработке софта совокупная стоимость владения складывается по большей части из стоимости поддержки и модификации написанного, а не из первоначальных инвестиций в написание кода. Кстати, про этот тезис часто сейчас забывают, когда оценивают эффекты написания кода LLM ассистентами, считая только легкость начальной генерации кода:)
- Но не все изменения стоят одинаково - обычно небольшие изменения стоят недорого, но много небольших изменений могут накапливаться и превращаться в большее, которое может стоить как значительная часть системы. В терминальном случае это большое изменение приводит к запрету версии 1.0 и создании нового пректа с нуля
- Для снижения стоимости изменений, которые точно будут, надо понимать структуру затрат - это поможет подготовить софт к эволюции по мере изменений требований бизнеса
- Кент говорит про coupling и про то, что изначально coupling между компонентами означал что изменения в одном элементе могут потребовать изменений в других. А потом определение Edward Yourdon, Larry L. Constantine начало мутировать и потеряло изначальный смысл
- При разработке ПО нужно учитывать стоимость связей и стоимость их отсутствия. Важно находить компромиссы между стоимостью изменений и их последствиями. Пространство компромиссов помогает оценить целесообразность изменений.
- Оценивать эти компромиссы лучше понимая экономические факторы вида NPV и стоимости денег во времени, оценки рисков и так далее. Например, инвестиции в структуру создают возможности для будущих изменений, что дает нам опцион на реализацию дешевых изменений в будущем
- Отдельно автор отмечает, что наличие ограничений дает инженерам пространство и стимул для хороших решений:)
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture