Цель важнее кода

https://medium.com/@fagnerbrack/the-problem-you-solve-is-more-important-than-the-code-you-write-d0e5493132c6
  • Перевод

У программы есть цель, о которой иногда забывают



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

Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.

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

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

Вот пример.

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

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

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

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

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

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

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

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


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

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


Двумерная матрица приоритетов. По вертикальной оси представлено количество «пострадавших» со значениями «один», «несколько» и «все». По горизонтальной оси отложена «серьёзность» со значениями «косметический», «неудобный» и «прекращает работу». Приоритет бага определяется положением на осях. Например, если ошибка косметическая и затрагивает одного пользователя, приоритет равен 4 (минимальный). Если баг останавливает работу некоторых пользователей, приоритет 1. Если он останавливает работу всех пользователей, у него максимальный приоритет

Упомянутая выше проблема двойного депозита попадает в категорию неудобства, которое затронуло одного пользователя. Таким образом, приоритет 3.

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


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

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

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

Не каждая команда стоит описания


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

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

И вот почему: валидация и так принудительная!

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

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

Не каждая функция стоит кодирования


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

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

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

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

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

Если вам действительно нужно забить этот гвоздь.
Поделиться публикацией

Похожие публикации

Комментарии 15
    0
    Чтобы познать дао кода, нужно написать много кода. Не написав много кода ты не познаешь ничего.
      +1
      Ещё надо читать умные книги, да и не просто читать, а критически оценивать то, что пишут. Развивать системное мышление, общаться с людьми — пользователями, понимать их проблемы, которые решает ПО.
        +1
        Это необходимое, но не достаточное условие. Важен не сам опыт, а его осмысление. Человек может годами воспроизводить одни и те же ошибки, и если он не способен в достаточной мере анализировать свои решения, то он может написать хоть тысячу строк, хоть миллион, но это ему слабо поможет.
        +7
        Это превосходный пример узкого фокуса: целью было открыть замок с минимальным усилием.

        Или наоборот, кто-то смотрел достаточно широко, чтобы задуматься о необходимости минимального подтверждения намерений пользователя перед потенциально небезопасным действием.
          +1
          Да, такое поведение может быть опцией, но никак не действием по-умолчанию. Я бы туда еще и опциональную защиту проверкой отпечатка или кодом добавил — а ну как смартфон украдут, а пользователь не любит блокировку экрана?

          Мне кажется, что проблема с приложениями ровно обратная — их облегчают настолько, что не остается даже элементарных опций, позволяющих использовать приложение более чем одним путем.
            0
            Всё зависит от контекста. Если это входная дверь в квартиру, то я 10 раз подумаю над мыслью а стоит ли автоматизировать её открытие.
            Если же мы разрабатываем систему дверей между отсеками на условном крейсере «Ентерпрайз», то автоматическое открывание по какому-то идентификатору личности, передаваемому по беспроводному каналу вполне может оказаться уместным.
              0
              Опять же важен контекст. В Канаде настолько низкий уровень преступности, что двери домов вообще не запираются. Так что автооткрывальщик, как бы придворник, вполне может подойти.
              А в классическом случае «подойти, чтобы отпереть» я бы тоже не хотел. Хоть бы отпечаток пальца
            +7
            Кто то ломится в дверь. Подошел глянуть — упс, дверь открылась…
              0
              Типичный сюжет для ночного кошмара: кто-то ломится в дверь, я подхожу к ней и вижу что все замки почему-то открыты и остался один, который тоже открывается на глазах, и дверь уже начинает приоткрываться. Я начинаю спешно запирать, они снова отпираются…
              Забавно узнать, что в реальности такой сценарий тоже возможен, да.
            +3

            Все эти манагерские песни быстро сменяются на противоположные, когда приходит время исправлять баги и вносить изменения в дизайн. "Нужно быть flexible" или даже (боги упасите) "разбираться в чужом коде". Т.е. когда нужно хренак и в продакшен — никто, кроме инженегра, не печётся о дизайне (фактически — о будущем). Дизайн, рефакторинг — это всё потом, а сейчас нужно быстро и грязно удовлетворять клиентов.


            Здесь просто разные интересы. У разработчика — свои, а у манагера — свои. Соответственно, разработчик должен аргументтировать свою позицию и защищать свои интересы (чтобы потом исправлеия/изменения не были мучительной болью). Не дали время на вдумчивое исправление дизайна — извиняйте, в следующий раз проблемы будут потяжелее.

              +1
              Да, но: «шуруп, забитый молотком, лучше, чем гвоздь, закрученный отверткой»
                –1

                Возвращаясь к статье. У инженера цель — зп + наличие хороших молотка и отвёртки под рукой. Забитые шурупы и закрученные гвозди — это цели высокого менеджмента. И надо понимать разницу между целями разных людей

              0
              Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.


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

              Этот вывод должен делать ux-проектировщик/продакт/аналитик/манагер/etc, а не разработчик.
                +1
                программисты забыли… вывод должен делать ux-проектировщик/продакт/аналитик/манагер/etc, а не разработчик.

                Споры об определениях
                  0
                  Я к тому, что в статье в первом предложении незаслуженный «наезд» на разработчиков.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое