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

в 11:19, , рубрики: Программирование, Программное обеспечение, функциональное программирование

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

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

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

Независимо от того, каким путем программирование пошло с тех пор, по-прежнему существует проблема с разделением между бизнесом и разработкой программного обеспечения — или «ИНЖИНИРИНГ», как впервые назвала конференция. Если разработчики слишком сосредоточены на разработке, они могут пропустить цель программного обеспечения, которое они пишут. Они могут не видеть скрытых решений, которые не требуют никакого кода.

Вот пример.

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

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

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

Если мы используем Bluetooth и наша бизнес-модель пускает в дом любого, кто имеет телефон, почему мы должны заставлять кого-то брать телефон и нажимать на кнопку? Пусть дверь будет открываться при приближении устройства на 1 метр. Таким образом, нам не нужно платить за разработку и программирование визуального интерфейса!

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

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

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

Не каждый код стоит писать

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

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

image

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

Не каждый баг стоит исправлять

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

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

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

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

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

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

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

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

Не каждую функцию стоит программировать

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

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

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

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

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

То есть если вам нужен гвоздь в первую очередь.

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

Если у меня есть ошибки в переводе, пожулуйста напишите об этом в комментариях!
А также зайдите на мой сайт, где появился быстрый доступ к вопросом и ответам по javascript — Вопросы и ответы по JavaScript

Буду очень вам благодарен и признателен)

Я в твиттере и вк

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

Автор: Rapprogtrain

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js