[4/5] Чистый дизайн (Tidy First?) (Рубрика Architecture)
Продолжая посты (1, 2 и 3) о книге "Чистый дизайн" расскажу про последнюю часть, в которой автор делится своими теоретическими изысканимями, которые позволяют наработать интуицию в принятии решений относительно дизайна софта. Здесь автор рассматривает вопросы
- Что такое программный дизайн?
- Как дизайн влияет на разработку и эксплуатацию софта и наоборот?
- Стоит ли вкладываться в проработку струтктуры софта и к чем это приведет?
- Каакие принципы (экономические и гуманитарные) можно использовать для принятия решений о изменении структуры софта?
И вот что я вынес из этой части
- Взаимовыгодные отношения между элементами (benecially relating elements) - собственно, это и есть определение программного дизайна от автора, которое лаконично и интересно. По-факту, в определении приведены основные части: элементы, отношения и взаимная выгода между ними. А дизайнеры - это те, кто как раз обеспечивают то, чтобы отношения были взаимовыгодными.
- Структура и поведение (structure and behavior) - ценность кода в том, что он умеет делать уже сейчас (поведение), а также в том, что он сможет делать завтра (структура). Поведение можно характеризовать двумя способами: парами вход/выход и инвариантами, которые сохраняются во время изменений системы. Структура не влияет напрямую на поведение, но она влияет на варианты развития событий - насколько нам просто будет дорабатывать систему тем или иным способом. Изменения в поведении видны сразу, а вот изменения в структуре замерить сложно, поэтому их часто откладывают.
- Экономика: ценность во времени и вариативность (economics: time value and optionality) - автор рассказывает про природу денег: -- Доллар сегодня стоит больше доллара завтра, поэтому зарабатывать надо раньше - тут можно посмотреть в сторону дисконтированных денежных потоков и NPV -- В ситуации хаоса лучше вариативность, чем однозначность, поэтому перед лицом неопределенность создавайте варианты В итоге, задачей дизайн автор видит согласование императивов "зарабатывать раньше/тратить позже" (поведение) и "создаавать вариативность, а не однозначность" (структура).
- Доллар сегодня стоит больше, чем доллар завтра (a dollar today > a dollar tomorrow) - рассказ про пальцах про дисконтирование денежных потоков
- Вариативность (options) - рассказ про "дилемму Златовласки", где у нас не должно быть слишком много дизайна или очень рано, но и не должно быть слишком мало дизайна или слишком поздно. Дальше вступает в дело концепция опционов, когда мы платим деньги сейчас за возможность купить что-то в будущем. В итоге, проектирование, которым мы знимаемся сегодня, - это "опционная премия", которую мы платим, "покупая" изменения поведения программы в будущем.
- Опционы и денежные потоки (options versus cash flows) - здесь автор объясняет как принимать решения об очистке (tidying) с учетом наших знаний ою опционах. Одновременно звучит тезис о том, что программный дизайн - это про налаживание отношений с людьми, а очистка - это про отношения с самим собой:) Считать всю экономику для очистки часто бывает затратно, но принимая решения о ней мы тренируем -- Привычку читывать факторы, влияющие на время и область действия дизайна -- Навыки выстраивать взаимоотношения с людьми
- Обратимые изменения структуры (reversible structure changes) - структурные изменения обычно обратимы, а вот изменения в поведении приводят к сайд-эффектам, которые мы не всегда можем откатить (условно, рассылка не тех сообщений не тем людям). В итоге, надо работать с разной степенью тщательности с обратимыми и необратимыми изменениями (это сходно с концепцией one-way door и two-way door decisions как это описывал Джефф Безос)
В следующем посте я расскажу про оставшиеся части теории и про литературу, что советует изучать автор.
#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture