Что, почему и зачем

Как вы объясняете?

Представьте, что вы объясняете другу некую сложную штуковину. Как вы будете её объяснять?

Скажем, ваш друг никогда не видел и не слышал о велосипеде, и он спрашивает вас “а что такое велосипед?”, что вы ответите?

Вы расскажете из чего состоит велосипед? Или что с ним можно делать? Или для чего люди покупают велосипеды?

Три уровня понимания

Когда я пытаюсь объяснить что-то, я держу в голове три уровня понимания. См. картинку выше.

Базовый уровень понимания — детали, ответ на вопрос “что?”

Второй, более высокий уровень понимания — контекст, ответ на вопрос “почему?”

Третий, высший уровень понимания — цель, ответ на вопрос “зачем?”

Пример бегущего человека

Представьте, бежит по улице человек.

  1. Вы не понимаете, что происходит. Куда-то бежит, но смысл? На работу опаздывает или просто решил размять ноги?

    Вы знаете что он бежит, но не знаете почему он бежит.

  2. Теперь он подбежал поближе, и вы увидели что за ним гонится другой человек. Ага, подумали вы. Теперь ясно. Он убегает от кого-то.

    Вы знаете почему он бежит: он убегает от другого человека. Но ещё непонятно, зачем он это делает.

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

    Ну, теперь понятно — он хочет избежать наказания за кражу, вот зачем он бежит.

От деталей к общей причине

Если бы вы рассказали об увиденном кому-то ещё, то для полного понимания вашему собеседнику было бы недостаточно услышать, что человек бежал по улице.

“Что ты видел? Я видел как кто-то бежит по улице”

Этого недостаточно.

Вам пришлось бы рассказать полностью всё что вы видели, чтобы он пришёл к тем же выводам что и вы, либо рассказать ответы на вопросы “зачем?”, “почему?” и “что?” — только тогда собеседник поймёт всё так же как и вы сами.

Понимание причины, контекста и деталей даёт полную картину. При этом контекст даёт больше понимания чем просто детали, а причина даёт больше понимания, чем просто контекст.

Пример сообщения в коммите

Все встречали такие коммиты, когда программист спешит или ленится:

  • fix
  • fix 2
  • more fix
  • another fix

1. Если попросить автора улучшить сообщения в коммитах, написать подробнее, будет примерно так:

  • поправил OrderController
  • валидация
  • баг с длинными строками
  • сделал проверку на null

Чуть лучше, но ещё остаются вопросы. Что с OrderController было не так, а валидация зачем понадобилась? И так далее.

2. Просим добавить контекст.

  • убрал ошибку 500 в OrderController
  • добавил проверку на корректность Email
  • обрезались строки, исправлено
  • если null то не бросаем исключение

Лучше, но и тут вопросы ещё остаются. Не идеально.

3. Просим добавить причину изменений.

  • Вместо 404 Not Found была ошибка 500, исправлено
  • Михайлова попросила запретить ввод некорректных Email в форме заявок
  • Терялись описания из-за маленького поля VARCHAR в БД
  • Подрядчика в заказе может не быть, это нормальное состояние

Вот теперь — идеально.

Если разбирая код я задамся вопросом “почему в этой строке написано именно так” и просмотрю изменения в истории коммитов, я увижу не только что мы поменяли и на что, но и зачем мы это сделали.

Как это применять?

Применять три уровня можно в любой ситуации, где требуется максимально точно донести смысл до другого человека.

Спросите себя, достаточно ли хорошо ваше объяснение работает на каждом из уровней? Понятны ли ответы на все три вопроса?

Чаще всего люди в коммуникации передают только самый нижний уровень, реже два, все три почти никогда.

Отсюда часто происходит непонимание, когда один представил себе верхние уровни вовсе не так как хотел другой.

Названия классов, методов

Название — это объяснение, сжатое до одного или нескольких слов.

Если название класса или метода чётко отвечает на вопросы “что?”, “почему?” и “зачем?”, тогда оно будет понятным.

Нужно иметь в виду, что часть смысловой информации мы берём из окружения, контекста. В само название стоит добавлять лишь то, что нельзя сразу извлечь из непосредственного контекста. Если класс называется Collection, то метод не стоит называть addCollectionItemToCollection, назовите просто add или addItem.

Анализ сложной структуры

Можно провести параллель со сложными структурами и также выделить в них три уровня, от общего (цель) к частному (детали).

Например, для проектирования приложения можно описать три уровня:

  1. Зачем — Домен
  2. Почему — Абстракция
  3. Что — Реализация

И так далее.

Объяснение сложной концепции

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

Это сэкономит время. Ведь нет никакой пользы обсуждать детали, если эти детали находятся в разном контексте или исходят от разных причин.

Можно вспомнить здесь притчу о слепых мудрецах и слоне — каждый из мудрецов сделал неверный вывод из деталей, упустив общую причину. Один пощупал хобот и сказал “это змея”, другой ногу и сказал “это дерево”, третий хвост и сказал “это верёвка”.

Точно так же выглядят споры о SOLID. Нет смысла спорить “что такое SRP” если различается понимание “зачем нужен SRP”.

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

Мои ответы на вопросы “зачем” про принципы SOLID можно почитать здесь: “Вывернутый SOLID”