К основному содержимому
#Architecture

[4/5] Чистый дизайн (Tidy First?) (Рубрика Architecture)

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Продолжая посты (1, 2 и 3) о книге "Чистый дизайн" расскажу про последнюю часть, в которой автор делится своими теоретическими изысканимями, которые позволяют наработать интуицию в принятии решений относительно дизайна софта. Здесь автор рассматривает вопросы

  • Что такое программный дизайн?
  • Как дизайн влияет на разработку и эксплуатацию софта и наоборот?
  • Стоит ли вкладываться в проработку струтктуры софта и к чем это приведет?
  • Каакие принципы (экономические и гуманитарные) можно использовать для принятия решений о изменении структуры софта?

И вот что я вынес из этой части

  • Взаимовыгодные отношения между элементами (bene€cially 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