Если бы электроны имели чувства)))
Ричард Фейнман как-то сказал: «Представьте, насколько сложнее была бы физика, если бы электроны имели чувства». Он говорил это в другом контексте, но мне кажется, это частично описывает и программирование для людей. У человека, интерпретирующего твой код, есть чувства!
Давайте поговорим о том, как упростить ему задачу.
▍ Освоение продукта - это и есть продукт
Разумеется, нужно обязательно прислушиваться к своим пользователям и принимать во внимание их отзывы. Как оказалось, основную часть отзывов оставляют опытные пользователи, постоянно работающие с вашим продуктом!
Как это повлияет на распределение получаемых отзывов? Не будет ли оно перекошенным? И как с этим связан рисунок самолёта?
Конечно же, здесь идёт речь об ошибке выжившего. Есть пользователи, которые не применяют ваш инструмент, потому что не смогли освоить его. И их отзывы мы обычно никогда не слышим!
Вы можете заявить что-то типа: «Да кого волнуют ленивые пользователи». Отвечу вам так: сегодня уже есть примерно семь миллиардов инструментов разработчика. У пользователей нет ни лишней энергии, ни терпения, чтобы разбираться, чем ваш пакет NPM кэша LRU лучше остальных. Так что простите!
Люди учатся на примерах, а не на «базовых концепциях»
Люди замечательно справляются с сопоставлением паттернов, в отличие от компьютеров, следующих булевой логике и строгим командам. Часто документация инструментов разработчика структурирована как компьютерная программа. Она начинается с базовой модели данных, взаимосвязей и атомов, с «базовых концепций», с объяснения того, как конфигурировать и выполнять операции.
А люди учатся иначе.
Сразу после того, как я написал предыдущий параграф, в Twitter (X) обнаружился пост, сформулировавший как раз то, что мне хотелось сказать:
Слишком многие книги и туториалы по программированию устроены так: «давайте построим дом с нуля, кирпич за кирпичом». А мне нужно что-то такое: «вот вам готовый дом, давайте изучим его, поменяв что-нибудь и отметив, что поменялось» - Крис Элбон (@chrisalbon)
Вместо того, чтобы писать хронику «базовых концепций» на пять тысяч слов, я советую придумать с десяток примеров. У такого подхода есть несколько преимуществ:
Люди будут видеть примеры и изучать по ним, как работает ваш инструмент. Именно так и учатся люди!
Человек, у которого возникла проблема, будет смотреть на начальный пример, достаточно близкий к ней. Чем больше потенциальных начальных примеров, тем выше вероятность, что в них найдётся что-то близкое к нужному ему.
Но когда мне нужно изучать новые концепции, у меня начинает болеть голова. Слишком много концепций!
Есть что-то очень изящное во фреймворке из всего трёх-пяти концепций, которому при этом удаётся быть невероятно мощным. Я помню то чувство, когда впервые попробовал React и спустя один-два часа разобрался со всеми концептуальными преградами. Всего несколько относительно простых кирпичиков, позволяющих построить целый собор. Настоящая магия.
Уточню, что сложность не в том, чтобы снизить количество концепций. Сложность в том, чтобы при этом сохранить количество всего того, что можно создать при помощи продукта. Или, по крайней мере, снизить количество первых сильнее, чем количество вторых. Я говорю об этом, потому что могу представить «спираль смерти тупого упрощения инструментов разработчика»:
У фреймворка слишком много концепций.
Добавим слой абстракции, позволяющий реализовать самые популярные возможности, используя меньшее количество концепций.
Есть много всего, чего нельзя делать в слое абстракции.
Добавим новые концепции, чтобы это можно было делать.
Возвращаемся к пункту 1.
Не знаю, происходит ли такое в действительности, но считаю, что существует уровень «плохих» упрощений. В конечном итоге вам нужно изменить баланс между «сложностью» (тем, что нужно знать) и «возможностями» (тем, что можно создать). Самые потрясающие инструменты способны снизить сложность на 90%, сохранив тот же уровень возможностей. Но я бы согласился и на инструмент, снижающий сложность на 90% с уменьшением возможностей на 10%. Вполне нормальный компромисс!
▍ Принцип концептуальной утки
Этот пункт связан с предыдущим. Допустим, вы добавляете в свой фреймворк элемент, получающий какие-то значения и вычисляющий на их основе новые значения. Как его назвать? Вычислительным узлом? Блоком вычислений? Думателем?
Нет! Нужно назвать его функцией!
Если это выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, и есть утка.
Возможно, у этого элемента есть тонкости, немного отличающие его от функции. Например, значения кэшируются. Но он достаточно похож на функцию!
Если назвать его функцией, то можно воспользоваться уже имеющейся у пользователя ментальной моделью того, что умеет функция. А это сэкономит вам 90% времени на объяснение возможностей элемента.
▍ Программируемость
Люди будут делать с вашей кодовой базой безумные вещи. ....
В том числе и о том, что я считаю самым удивительным: почему крупные компании обычно неспособны выпускать высококачественные инструменты разработчика.
Я иногда думаю, что сложность проектирования инструмента для никогда не работавшего с ним пользователя похожа на сложность написания популярной песни. Продюсер прослушает песню тысячу раз. Но даже слушая её в 999-й раз, он должен представлять, как она будет звучать для человека, слышащего её впервые, что, как мне кажется, крайне сложно.
Скорее всего, именно поэтому я пишу инструменты разработчика, а не сочиняю попсу.
https://habr.com/ru/companies/ruvds/articles/847664/
Давайте поговорим о том, как упростить ему задачу.
▍ Освоение продукта - это и есть продукт
Разумеется, нужно обязательно прислушиваться к своим пользователям и принимать во внимание их отзывы. Как оказалось, основную часть отзывов оставляют опытные пользователи, постоянно работающие с вашим продуктом!
Как это повлияет на распределение получаемых отзывов? Не будет ли оно перекошенным? И как с этим связан рисунок самолёта?
Конечно же, здесь идёт речь об ошибке выжившего. Есть пользователи, которые не применяют ваш инструмент, потому что не смогли освоить его. И их отзывы мы обычно никогда не слышим!
Вы можете заявить что-то типа: «Да кого волнуют ленивые пользователи». Отвечу вам так: сегодня уже есть примерно семь миллиардов инструментов разработчика. У пользователей нет ни лишней энергии, ни терпения, чтобы разбираться, чем ваш пакет NPM кэша LRU лучше остальных. Так что простите!
Люди учатся на примерах, а не на «базовых концепциях»
Люди замечательно справляются с сопоставлением паттернов, в отличие от компьютеров, следующих булевой логике и строгим командам. Часто документация инструментов разработчика структурирована как компьютерная программа. Она начинается с базовой модели данных, взаимосвязей и атомов, с «базовых концепций», с объяснения того, как конфигурировать и выполнять операции.
А люди учатся иначе.
Сразу после того, как я написал предыдущий параграф, в Twitter (X) обнаружился пост, сформулировавший как раз то, что мне хотелось сказать:
Слишком многие книги и туториалы по программированию устроены так: «давайте построим дом с нуля, кирпич за кирпичом». А мне нужно что-то такое: «вот вам готовый дом, давайте изучим его, поменяв что-нибудь и отметив, что поменялось» - Крис Элбон (@chrisalbon)
Вместо того, чтобы писать хронику «базовых концепций» на пять тысяч слов, я советую придумать с десяток примеров. У такого подхода есть несколько преимуществ:
Люди будут видеть примеры и изучать по ним, как работает ваш инструмент. Именно так и учатся люди!
Человек, у которого возникла проблема, будет смотреть на начальный пример, достаточно близкий к ней. Чем больше потенциальных начальных примеров, тем выше вероятность, что в них найдётся что-то близкое к нужному ему.
Но когда мне нужно изучать новые концепции, у меня начинает болеть голова. Слишком много концепций!
Есть что-то очень изящное во фреймворке из всего трёх-пяти концепций, которому при этом удаётся быть невероятно мощным. Я помню то чувство, когда впервые попробовал React и спустя один-два часа разобрался со всеми концептуальными преградами. Всего несколько относительно простых кирпичиков, позволяющих построить целый собор. Настоящая магия.
Уточню, что сложность не в том, чтобы снизить количество концепций. Сложность в том, чтобы при этом сохранить количество всего того, что можно создать при помощи продукта. Или, по крайней мере, снизить количество первых сильнее, чем количество вторых. Я говорю об этом, потому что могу представить «спираль смерти тупого упрощения инструментов разработчика»:
У фреймворка слишком много концепций.
Добавим слой абстракции, позволяющий реализовать самые популярные возможности, используя меньшее количество концепций.
Есть много всего, чего нельзя делать в слое абстракции.
Добавим новые концепции, чтобы это можно было делать.
Возвращаемся к пункту 1.
Не знаю, происходит ли такое в действительности, но считаю, что существует уровень «плохих» упрощений. В конечном итоге вам нужно изменить баланс между «сложностью» (тем, что нужно знать) и «возможностями» (тем, что можно создать). Самые потрясающие инструменты способны снизить сложность на 90%, сохранив тот же уровень возможностей. Но я бы согласился и на инструмент, снижающий сложность на 90% с уменьшением возможностей на 10%. Вполне нормальный компромисс!
▍ Принцип концептуальной утки
Этот пункт связан с предыдущим. Допустим, вы добавляете в свой фреймворк элемент, получающий какие-то значения и вычисляющий на их основе новые значения. Как его назвать? Вычислительным узлом? Блоком вычислений? Думателем?
Нет! Нужно назвать его функцией!
Если это выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, и есть утка.
Возможно, у этого элемента есть тонкости, немного отличающие его от функции. Например, значения кэшируются. Но он достаточно похож на функцию!
Если назвать его функцией, то можно воспользоваться уже имеющейся у пользователя ментальной моделью того, что умеет функция. А это сэкономит вам 90% времени на объяснение возможностей элемента.
▍ Программируемость
Люди будут делать с вашей кодовой базой безумные вещи. ....
В том числе и о том, что я считаю самым удивительным: почему крупные компании обычно неспособны выпускать высококачественные инструменты разработчика.
Я иногда думаю, что сложность проектирования инструмента для никогда не работавшего с ним пользователя похожа на сложность написания популярной песни. Продюсер прослушает песню тысячу раз. Но даже слушая её в 999-й раз, он должен представлять, как она будет звучать для человека, слышащего её впервые, что, как мне кажется, крайне сложно.
Скорее всего, именно поэтому я пишу инструменты разработчика, а не сочиняю попсу.
https://habr.com/ru/companies/ruvds/articles/847664/