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

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

Такие продукты, как Jira и Salesforce, получили широкое распространение благодаря своей гибкости. Они все делают. Их также часто не любят люди, которым приходится с ними работать, потому что у них плохой UX, они не помогают с конкретной задачей, которую вы хотите выполнить, их можно настроить так, что две установки одного и того же продукта могут быть неузнаваемыми. .

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

Другой способ взглянуть на это - крайний случай.

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

Это просто компьютер. Конечно, вам придется написать весь машинный код самостоятельно, чтобы он заработал, но он может делать буквально все, что угодно. Может ли Jira это сделать?

Глупый пример, который я знаю, но суть в том, чтобы подчеркнуть, что для каждой добавленной вами гибкости вы также должны добавить некоторые усилия по настройке для ваших пользователей, чтобы заставить их делать то, что они хотят. Машинный код - это самая гибкая вещь из возможных, он может делать все, на что способен ваш компьютер. Но это очень большая работа.

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

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

Подумайте об этом так:

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

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

Другая причина, по которой я не согласен с «менталитетом функций», заключается в том, что функции трудно удалить после того, как вы их добавили. Это как проблема избирательного возраста. Большинству людей все равно, если мы снизим возрастной ценз до 16 лет. Правительства не хотят пробовать это, потому что, даже если бы никто не использовал его, было бы возмущение, если бы мы снова подняли его до 18 лет. Люди невероятно сопротивляются этому. терять что-то, даже если им было все равно.

Многие проблемы связаны с тем, что функции - это простой способ продемонстрировать прогресс. Если вы - продуктовая команда, и руководители спрашивают, чем вы занимаетесь, легко ответить: Мы разработали функции X, Y и Z, поэтому мы были продуктивными. Я ссылался на книгу Moneyball в предыдущей статье, и это прекрасный пример того вида неэффективности рынка, который описывается в книге, потому что мы измеряем себя неверными метриками. Я не уверен на 100%, каковы правильные показатели, но уверен, что простое количество выходных данных неверно.

Здесь есть очевидный контраргумент: я критикую Jira и Salesforce, несмотря на то, что это огромные и успешные продукты. Их не любят, но, в конце концов, они приносят прибыль. Это результат того, как растет продукция. Никто не стал бы создавать с нуля что-то похожее на Salesforce, но продукты растут такими, какие они есть. Только время покажет, узурпируют ли они более простые решения.

Вот часть разработки, которую я обещал ранее. В данном случае, когда я говорю о продукте, я имею в виду что-то вроде фрагмента кода с открытым исходным кодом. Пакет NPM в терминах Javascript.

На микроуровне мы знаем, что гибкий код - это здорово. Это определенно то, к чему стоит стремиться. Когда вы начинаете как разработчик, это одна из первых вещей, которой вас учат, и я определенно поддерживаю это как способ размышления о вашей работе. Гибкость действительно требует компромиссов, если вы начинаете расширять ее до того, как люди могут использовать ваш код.

В принципах SOLID у нас есть довольно четкое представление об этом на уровне класса. Единоличная ответственность = сосредоточенность. Открытый-закрытый = гибкий. Однажды вы начнете соединять все вместе, чтобы создать продукт или пакет, хотя правило больше не применяется.

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

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

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

Слишком часто люди по умолчанию считают, что чем больше вариантов, тем лучше, хотя на самом деле желательно меньшее. Слишком часто мы пытаемся догадаться, как кто-то может захотеть что-то использовать без каких-либо доказательств. В следующий раз, когда вы подумаете о том, чтобы сделать какой-либо аспект вашего компонента настраиваемым, подумайте, есть ли в нем требование, может ли это снизить согласованность его использования, и если вы хотите сохранить эту функциональность в течение всего срока службы. компонент. И помните, что если вам легко добавить эту возможность настройки сейчас, то ее можно будет легко добавить и позже, когда для этого возникнет реальная потребность. Это очень похожий принцип на KISS (Keep It Simple, Stupid) и YAGNI (Вам это не понадобится), за исключением того, что, я бы сказал, он идет дальше. Я не только говорю, что не делайте этого, потому что вам это не нужно, я говорю, что не делайте этого, потому что лучше не иметь этого.

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

Я закончу одним последним примером. Я полагаю (я не эксперт), что было бы легко добавить кнопку «взорвать все» на атомной электростанции. KISS и YAGNI сказали бы, что вы не должны этого делать, потому что это пустая трата времени. Я говорю, что нам нужен новый акроним, поскольку это не только пустая трата времени, но и лучше не делать этого. Я собираюсь предложить MBNLPDT для начала. Может, лучше не позволять людям это делать.

Всего наилучшего,

Ник