Проблема, которую вы решаете, важнее, чем код, который вы пишете

Программисты, кажется, забыли реальную цель программного обеспечения — решать реальные проблемы. Перевод публикации Фагнера Брэка на Medium.

50 лет назад, в 1968 году, была организована рабочая конференция по программной инженерии, которая была организованна при поддержке Научного комитета НАТО.

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

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

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

Вот пример.

Был стартап, который создавал устройство, позволяющее человеку открывать дверь своего дома по Bluetooth. В качестве визуального интерфейса использовался виджет, который был виден, даже когда телефон заблокирован. У него была единственная кнопка под названием «Открыть дверь».

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

Кто-то посмотрел на это и спросил:

Эта история с Bluetooth — отличный пример узкой направленности: цель состояла в том, чтобы открыть дверь с минимальными усилиями. Нет смысла разрабатывать визуальный интерфейс, если датчики беспроводные.

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

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

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

Этот компромисс между серьёзностью и приоритетом напоминает мне модель, которую недавно показал мне коллега. Она называется матрицей приоритетов.

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

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

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

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

Более полезно использовать некоторые типы команд низкого уровня в CLI, чем команду высокого уровня, которая абстрагирует знания, такие как Git.

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

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

И вот почему: проверка была обязательной!

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

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

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

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

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

Есть такая поговорка: «Если у вас есть только молоток, всё выглядит как гвоздь».

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

Спасибо за прочитанную статью!

Если у меня есть ошибки в переводе, пожалуйста, напишите об этом в комментариях! Мой сайт, где появился быстрый доступ к вопросом и ответам по JavaScript. Буду очень вам благодарен и признателен :)

Я в Twitter и во «ВКонтакте».

Спасибо большое за ваше внимание!

#код