Всем привет.
Читая рассылку блога Мартина Фаулера, наткнулся на его предисловие к недавно вышедшей книге коллег из ThoughtWorks - "Building Evolutionary Architectures".
Книга посвящена проблеме, с которой сталкиваются многие разработчики: развитие архитектур программных продуктов, или как задизайнить систему так, чтобы всё было ок при условии постоянно меняющихся требований к системе. Где же лежит тот crystal ball, который покажет нам будущее и что делать, если у вас его таки нет :)
Про проблемы создания архитектур можно говорить очень долго, но я выделю, как мне кажется, основную, которая является источником всех бед - попытка не смотря ни на что здесь и сейчас побороться с неопределённостью, которая естественным образом возникает в каждом программном продукте. C'est la vie.
Молодые архитекторы в погоне продемонстрировать свои способности бросаются в этот омут с головой, таща за собой на дно и свой уютненький стартап. Как правило, они подыхают под весом того количества комбинаций разных факторов, которые надо перебрать, чтобы найти оптимальное решение. А иногда по ходу открываются новые факторы, которые не были учтены ранее и всё начинается заново и вот наш простодушный максималист уже не замечает, что выбирает подход дольше, чем ему дали времени на реализацию.
На сладкое ему может прилететь и то, что его красивый замок из слоновой кости, готовый по всем согласованиям гнуться влево будет просто-напросто отказываться гнуться вправо, когда от него этого потребуют реалии жизни.
Но даже если произошло чудо и систему не стали проверять на ту мифическую гибкость, которая была в неё заложена (вот это поворот!), есть шанс натолкнуться на ситуацию, когда
всё равно начинаешь жалеть о том, что наворотил, - сделал гибко там, где нужно было просто, сделал статично там, где нужна была динамика. И тут начинается тёмный мир разработки - костыли, велосипеды, технический долг, наращивание ненужной сложности, в очередной раз обещание больше так не увлекаться...
Так что же делать? Как проектировать систему, чтобы она потом не разъезжалась под ногами и не теряла критически важных свойств, несмотря на изменения? С чем то надо просто смириться, что-то надо начать делать иначе и постоянно иметь ввиду, что у всего есть своя цена и нужно десять раз подумать прежде чем что-то выбрать. Об этом и есть данная книга.
В ней затрагиваются как глобальные вопросы выбора подходящей архитектуры под требуемые свойства, цены гибкости и переиспользования кода, так и конкретные техники, которые должны помочь в контролируемом развитии системы: постоянная валидация свойств системы, миграция данных, проверка контрактов. Будут затронуты как тактические, так и стратегические нюансы, которые необходимо учитывать для успеха всего мероприятия. Понятно, что без соответствующего уровня инженерной культуры в компании этого достичь нельзя, поэтому о важности CI и CD и как их прикрутить к решению этой проблемы тоже будет упомянуто.
Лично мне особенно понравилась вторая часть книги, где описываются антипаттерны, которые стали актуальны в последнее время. Лично мой эффект - переосмысление прошлого опыта и очередное подтверждения девизов: "всё - тлен" и "всё надо подвергать сомнению" (confirmation bias - он коварный).
Читая рассылку блога Мартина Фаулера, наткнулся на его предисловие к недавно вышедшей книге коллег из ThoughtWorks - "Building Evolutionary Architectures".
Книга посвящена проблеме, с которой сталкиваются многие разработчики: развитие архитектур программных продуктов, или как задизайнить систему так, чтобы всё было ок при условии постоянно меняющихся требований к системе. Где же лежит тот crystal ball, который покажет нам будущее и что делать, если у вас его таки нет :)
Про проблемы создания архитектур можно говорить очень долго, но я выделю, как мне кажется, основную, которая является источником всех бед - попытка не смотря ни на что здесь и сейчас побороться с неопределённостью, которая естественным образом возникает в каждом программном продукте. C'est la vie.
Молодые архитекторы в погоне продемонстрировать свои способности бросаются в этот омут с головой, таща за собой на дно и свой уютненький стартап. Как правило, они подыхают под весом того количества комбинаций разных факторов, которые надо перебрать, чтобы найти оптимальное решение. А иногда по ходу открываются новые факторы, которые не были учтены ранее и всё начинается заново и вот наш простодушный максималист уже не замечает, что выбирает подход дольше, чем ему дали времени на реализацию.
На сладкое ему может прилететь и то, что его красивый замок из слоновой кости, готовый по всем согласованиям гнуться влево будет просто-напросто отказываться гнуться вправо, когда от него этого потребуют реалии жизни.
Но даже если произошло чудо и систему не стали проверять на ту мифическую гибкость, которая была в неё заложена (вот это поворот!), есть шанс натолкнуться на ситуацию, когда
всё равно начинаешь жалеть о том, что наворотил, - сделал гибко там, где нужно было просто, сделал статично там, где нужна была динамика. И тут начинается тёмный мир разработки - костыли, велосипеды, технический долг, наращивание ненужной сложности, в очередной раз обещание больше так не увлекаться...
Так что же делать? Как проектировать систему, чтобы она потом не разъезжалась под ногами и не теряла критически важных свойств, несмотря на изменения? С чем то надо просто смириться, что-то надо начать делать иначе и постоянно иметь ввиду, что у всего есть своя цена и нужно десять раз подумать прежде чем что-то выбрать. Об этом и есть данная книга.
В ней затрагиваются как глобальные вопросы выбора подходящей архитектуры под требуемые свойства, цены гибкости и переиспользования кода, так и конкретные техники, которые должны помочь в контролируемом развитии системы: постоянная валидация свойств системы, миграция данных, проверка контрактов. Будут затронуты как тактические, так и стратегические нюансы, которые необходимо учитывать для успеха всего мероприятия. Понятно, что без соответствующего уровня инженерной культуры в компании этого достичь нельзя, поэтому о важности CI и CD и как их прикрутить к решению этой проблемы тоже будет упомянуто.
Лично мне особенно понравилась вторая часть книги, где описываются антипаттерны, которые стали актуальны в последнее время. Лично мой эффект - переосмысление прошлого опыта и очередное подтверждения девизов: "всё - тлен" и "всё надо подвергать сомнению" (confirmation bias - он коварный).
В общем, речь будет идти о многом, что необходимо для уменьшения времени между появлением идеи фичи и её выкаткой на прод. Если вам эта тема интересна - крайне рекомендую ознакомиться с этой небольшой книжкой.
Комментариев нет:
Отправить комментарий