Хабрахабр

[Перевод] Цель важнее кода

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


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

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

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

Вот пример.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показать больше

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»