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

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

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

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

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

Вот пример.

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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