Comments 6
Спасибо! Хороший текст
Достаточно часто встречаю часто такие подходы к разработке интерфейса инструментов:
Делаем очень удобное апи для вырожденного случая. На остальные забиваем. Шаг в сторону от этого кейса - выкидывать библиотеку/инструмент
Делаем всратое апи, чтобы любой кейс покрыть. Не пытаемся никак приоритизировать ситуации. Человек мучается даже с теми вещами, которые делает постоянно.
Делаем удобное апи для плохих архитектурных решений, сильно более сложное для хороших. Зачастю документация тут покрывает как раз только удобную часть. Человек выбирает плохие решения, так как они проще.
Делаем всратое апи, чтобы любой кейс покрыть. Не пытаемся никак приоритизировать ситуации. Человек мучается даже с теми вещами, которые делает постоянно.
Оно даже может быть не всратым, а нормальным. Просто кейс для которого его используют в 90% — это просто один из методов в глубине API с документацией не хуже и не лучше остальных. И получается что на долю 90% использования достается 20% документации и примеров.
Люди будут видеть примеры и изучать по ним, как работает ваш инструмент. Именно так и учатся люди!
Не все и не всегда. Например, мой друг терпеть не может, когда обучение идёт через примеры и по паттернам. У него сугубо структурный тип мышления, и ему нужна эта концептуальная структура, а не готовые примеры, которые можно менять. Я в принципе и сам такой же.
Сейчас я своим коллегам читаю лекции по Git. И вот что любопытно: на подготовку этих лекций меня сподвигло то, что я пришёл к выводам, абсолютно противоположным выводам в статье. Интернеты забиты примерами и быстрыми туториалами по Git, а вот толкового курса о том, как действительно он работает, так вот быстро и не найдёшь. Потому что большинство так и поступает: это же не язык программирования, а просто вспомогательный инструмент, я быстренько разберусь как там выполнять основные команды, а если начнутся проблемы, то лид разберётся, ему же больше платят. Поэтому в своих лекциях я как бы изобретаю Git заново со своими слушателями, чтобы объяснить те весьма простые концепции, на которых он построен, а не зубрить хаотичный CLI Git-а.
Если современная разработка много где превратилась в потогонку вида «в прод нужно было ещё вчера», и все занимаются stackoverflow-oriented/ChatGPT-oriented programming, то это скорее проблема менеждмента, а может даже и экономики/рынка.
Нет! Нужно назвать его функцией!
А вот это хороший совет. Только есть другая проблема: этот понятийный аппарат сначала нужно как-то получить. Тут мы и вспоминаем, зачем же на самом деле нужно полноценное образование — чтобы понимать людей, и чтобы тебя понимали.
Избегайте перегрузки концепциями
Ну тут автор изобрёл бритву Оккама, нечего добавить.
Спасибо за перевод!
Не все и не всегда. Например, мой друг терпеть не может, когда обучение идёт через примеры и по паттернам. У него сугубо структурный тип мышления, и ему нужна эта концептуальная структура, а не готовые примеры, которые можно менять. Я в принципе и сам такой же.
Мне тоже эта уверенность, что люди учатся на примерах, да ещё и с восклицательным знаком, в статье не понравилась. И я себя чувствую неуютно, когда я знаю только отдельные "заклинания", а что там происходит на уровне концепций - не понимаю.И при малейшем углублении в тему стараюсь найти концептуальное описание, только вот в наше время с этим часто сложно. Ну - или трачу силы на восстановление концепций, по этим самым примерам или даже по исходникам. Это окупается (IMHO): знание немногих принципов часто заменяет знание многих фактов.
PS Что до Git, то мне лично помог самый что ни на есть официоз - Pro Git. Собственно, я начал практически именно с чтения этой книги. Благо я вовремя понял, что от широкого применения Git я не отверчусь, а время читать у меня было.
Не все и не всегда. Например, мой друг терпеть не может, когда обучение идёт через примеры и по паттернам. У него сугубо структурный тип мышления, и ему нужна эта концептуальная структура, а не готовые примеры, которые можно менять. Я в принципе и сам такой же.
Как мне кажется, это зависит от желаемого уровня погружения. Да вы и сами это чуть ниже отметили. Какой-то вспомогательный инструмент, которым нужно воспользоваться несколько раз более-менее стандартным образом, проще изучить на примерах. Но для постоянной работы такой подход работать, естественно, не будет.
Писать код для компьютеров сложно, ещё сложнее — писать код для людей