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

[1/2] Growing Your Personal Design Heuristics • Rebecca Wirfs-Brock • YOW! 2019 (Рубрика Architecture)

#Architecture #Management #Software #SoftwareDevelopment #Patterns #Engineering #SelfDevelopment

Посмотрел на днях выступление за авторством Rebecca Wirfs-Brock, заслуженной бабушки, что написала две книги: "Designing Object-Oriented Software" в 1990 и "Object Design: Roles, Responsibilities, and Collaborations" в 2003. Она является изобретателем Responsibility-Driven Design, одного из первых поведенческих подходов к объектному дизайну. В итоге, если вы слышали про X-driven design (XDD), где X - это произвольное слово, то можете поблагодарить Ребекку за то, что она проложила эту дорожку.

В этом выступлении Ребекка рассказывает про эвристики, как они помогают принимать дизайн решения и как собрать осмысленно свой набор эвристик. Речь идет про

  • Кулинарные рецепты, в которых инструкции недостаточно точны, чтобы следуя им напрямую получить желаемое блюдо
  • Потом следует вывод, что не существует замены для обучения на своем собственном опыте и рефлексии относительно него
  • Дальше автор разбирает то, что такое эвристика и разбирает четыре варианта: rule of thumb, practical method, ~~useful shortcut~~, ~~approximation~~. И бракует пару последних вариантов. В итоге, ее определение близко с определениями из wikipedia

Под эвристикой понимают совокупность приёмов и методов, облегчающих и упрощающих решение познавательных, конструктивных, практических задач

  • Следом за этим Ребекка начинает погружаться в примеры эвристик из разных областей и вспоминает про Мартина Фаулера с его эвристикой для структурирования domain layer, где он предлагал много лет назад три варианта: transaction script pattern, table module pattern, domain model pattern. И Ребекка откапывает тут стюардессу для того, чтобы показать, что эвристики устаревают со временем, так как state-of-the-art постоянно прогрессирует и мы сталкиваемся с новыми проблемами и придумываем новые эвристики для решений. Тут она показывает и другой набор эвристик для дизайна и вспоминает про хранимую процедуру со 100 входными параметрами, которую ей когда-то пришлось ревьювить:) В итоге, следует вывод, что между эвристиками и их пользователями всегда будут нестыковки и надо уметь договариваться.
  • Поговорив про эвристики для дизайна, Ребекка переходит к обсуждению мета-эвристик, а точнее эвристик для использования других эвристик. Тут приводится пример с разделением команд, паттерн для первого контакта с системой.
  • Следующим шагом идет эвристика, которая определяет наше поведение и отношение к происходящему. Для себя Ребекка вывела эвристику, что она ценит больше консистентность, а не ум. Интересно, что еще в школе я видел похожую эвристику у своего учителя по физике (ниже история скрыта за спойлером) ||В лицее у меня был учитель по физике, который выучил кучу призеров международных олимиад по физике. Его эвристика по оцениванию учеников была примерно такой: "Я ценю больше старание и усилия, чем ум". Так у меня в школе итоговой оценкой по физике от него стала четверка и это с учетом учебы в 10 и 11 классе в ЗФТШ и поступление в МФТИ. Просто я был недостаточно сфокусированным на саморазвитии в области физики:)||
  • Для того, чтобы эвристики не протухали, их требуется переодически испытывать на прочность. Дальше Ребекка обсуждает эвристики насчет размера микросервисов - в 2019 году это было горячей темой:)

А алгоритм для развития эвристик будет в отдельном посте, так как в этот он не поместился:)

#Management #Software #SoftwareDevelopment #Patterns #Engineering #SelfDevelopment