Искусство рассказывания историй в разработке программного обеспечения

Рассказывание историй — самый мощный способ воплощения идей в мир сегодня, — Роберт Макафи Браун.

В настоящее время разработка программного обеспечения — это сложный процесс, который включает в себя множество научных аспектов, но также может рассматриваться как форма искусства. Даже если отбросить правила и передовой опыт, фрагмент кода всегда будет отражать разум, душу и творческий потенциал разработчика, который его создал. Таким образом, разработчик всегда может извлечь выгоду из заимствования элементов и изучения великих мастеров не только компьютерных наук, но и других искусств, таких как искусство сторителлинга. В конце концов, мастер должен постоянно оттачивать свое мастерство.

Программирование и повествование очень похожи по своей природе. Например, оба они выражаются посредством письменного языка и являются средством коммуникации (либо как набор инструкций для машины, либо как код, читаемый коллегой). У обоих есть правила, передовой опыт, методы и структура. Как же разработчику извлечь пользу из изучения сторителлинга?

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

Не говори мне про свет луны; лучше покажи мне, как лунный свет мерцает в треснутом бокале, — Антон Чехов.

В программировании существует аналогичный принцип, известный как «Говори, не спрашивай» (Tell, Don’t Ask), который направлен на управление связью между классами. Поскольку ожидается, что хороший рассказчик будет показывать аудитории вместо того, чтобы просто направлять информацию, разработчик может также сказать (приказать) своим объектам вести себя так, как ожидалось, вместо того, чтобы запрашивать у них их внутреннее состояние.

Чтобы объяснить это дальше, давайте рассмотрим пример тривиального, но типичного объекта ask:

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

Следуя принципу «говори, а не спрашивай», мы можем реорганизовать наш объект следующим образом:

Теперь вместо того, чтобы спрашивать, мы можем сказать объекту, чтобы он включил или выключил свет, и довериться ему вести себя так, как ожидалось. Но чего мы здесь добились?

Как разработчики, мы изо дня в день пишем и читаем код. На самом деле, мы можем тратить больше времени на чтение, чем на письмо. Следуя принципу «Говори, не спрашивай», мы не только уменьшили сложность (представьте класс с реальными внутренними зависимостями, а не единственной переменной), но также добавили намерение в наш код. Как сделал бы хороший рассказчик, мы выразили свое намерение нашему коллеге-читателю (разработчику) и создали повествование. Объект «Автомобиль» теперь может быть персонажем на более крупном изображении, а метод освещения может быть нашей собственной версией отблеска света на разбитом стекле.

Как и все, что имеет значение в нашем ремесле, вышеупомянутый метод не подходит для того, чтобы ему следовать всегда, однако вы можете использовать его в зависимости от ситуации.

А пока не переставайте создавать и исследовать идеи!

Источник