У программы есть цель, о которой иногда забывают
![](https://habrastorage.org/getpro/habr/post_images/5f2/b62/35e/5f2b6235ea5f8eb2bb4c4d0a94f1f938.jpg)
Изображение молотка, лежащего на доске. В доске застрял шуруп, который туда усиленно забивали
Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.
50 лет назад, в 1968 году, прошла Рабочая конференция по инжинирингу ПО, организованная Комитетом по науке НАТО. Тогда стали замечать, что программное обеспечение становится фундаментальной частью общества. И одновременно его становится труднее понять. После этой конференции программирование начало превращаться в настоящую индустрию. Оно начало уходить из-под контроля бизнеса.
Независимо от дальнейшей судьбы индустрии по-прежнему существует проблема с разделением бизнеса и разработки программного обеспечения — или «инжиниринга», как впервые прозвучало на конференции. Если программисты слишком узко фокусируются на разработке, то могут упустить цель, ради которой создаётся программа. Они могут упустить скрытые решения, вообще не требующие кода.
Вот пример.
Один стартап создавал устройство, позволяющее открыть дверь дома по Bluetooth. Графический интерфейс для связи с устройством — виджет на заблокированном экране телефона. У него одна кнопка под названием «Открыть дверь».
Когда пользователь подходит к дому, он берёт телефон, находит виджет и нажимает кнопку.
Кто-то посмотрел на эту механику и спросил:
Если мы используем Bluetooth и предполагаем, что владелец телефона может войти в дом, зачем заставлять его доставать телефон и нажимать кнопку? Пусть дверь сама отпирается, когда телефон находится в радиусе 1 метра. Не нужно тратить время на дизайн и код графического интерфейса!
Это превосходный пример узкого фокуса: целью было открыть замок с минимальным усилием. Нет смысла создавать графический интерфейс, если датчики беспроводные.
Если вы знаете о задачах бизнеса и нуждах пользователя, то можете объединить эти знания со своими знаниями технологий. Только тогда у вас будет достаточно информации, чтобы придумать лучшее решение и понять, что программе не нужен интерфейс.
Отличный пример, как решить программную проблему без единой строчки нового кода, кроме кода для собственно открытия замка. Но как и технический долг, ничто не может оправдать ненужное программирование всего остального.
Не каждый код стоит писать
Иногда исправлять серьёзный баг — не главная задача. Если вы криптобиржа, а система допустила один двойной депозит, человеческое вмешательство может быть лучшим решением с точки зрения соотношения затрат и пользы, если стоимость решения высока.
Такой компромисс между Важностью и Приоритетом напоминает мне модель, которую недавно показал коллега. Она называется матрицей приоритетов — двумерная модель, которую можно использовать для расставления багов по приоритету на основе серьёзности и количества затронутых пользователей.
![](https://habrastorage.org/getpro/habr/post_images/616/0b4/d99/6160b4d994bc0548fc9893e1c5c675d8.png)
Двумерная матрица приоритетов. По вертикальной оси представлено количество «пострадавших» со значениями «один», «несколько» и «все». По горизонтальной оси отложена «серьёзность» со значениями «косметический», «неудобный» и «прекращает работу». Приоритет бага определяется положением на осях. Например, если ошибка косметическая и затрагивает одного пользователя, приоритет равен 4 (минимальный). Если баг останавливает работу некоторых пользователей, приоритет 1. Если он останавливает работу всех пользователей, у него максимальный приоритет
Упомянутая выше проблема двойного депозита попадает в категорию неудобства, которое затронуло одного пользователя. Таким образом, приоритет 3.
Не каждый баг стоит исправлять
Разработчики часто стремятся предусмотреть все случаи. Но некоторые повторяющиеся задачи могут не заслуживать автоматизации. Не нужно тратить время на написание сценариев, если в результате будут скрыты важные знания о работе основной команды.
Есть разница между инкапсуляцией сложной логики и абстракцией полезных знаний. Иногда только ясную информацию можно понять. Если абстрагировать её, то можно получить противоположный эффект: понимание затруднится.
Более полезно использовать некоторые типы низкоуровневых команд в CLI, чем высокоуровневые команды с абстрактным знанием, как алиасы Git.
Не каждая команда стоит описания
Много лет назад я работал над проектом с инкрементной поставкой. Это была система проверки личности, которая просила пользователя предоставить некоторые личные данные для проверки третьей стороной.
И там команда хотела закодировать одну необычную функцию валидации поля. Тем не менее, эту валидацию отодвигали на каждой планёрке по мере приближения дедлайна. В конце концов решили, что в этой необычной функции вообще нет смысла.
И вот почему: валидация и так принудительная!
Предоставление достоверной информации отвечало интересам пользователя. Если он предоставил неправильные данные, они не пройдут проверку и он не сможет использовать систему. Кроме того, большинство браузеров поддерживает достаточно хорошую стандартную валидацию HTML.
В худшем случае, если пользователь не может верифицироваться, то позвонит в поддержку для проверки вручную.
Не каждая функция стоит кодирования
Если вы понимаете суть решаемой проблемы, то как разработчик сможете придумать лучший код, а иногда вообще обойдётесь без кода. Вы не быдлокодер, которому платят за написание строк по поставленной задаче. Вы профессионал, которому платят за решение проблем.
Но не нужно бездумно решать технологиями любую проблему, как будто программный код — это универсальное решение для всего. Иначе у вас возникнут проблемы с пониманием нужд клиента и генерацией отличных идей.
Ваша цель и задача кода — создать ценность и сделать мир лучше, а не удовлетворить своё эгоцентрическое представление о том, каким должен быть мир.
Есть такая поговорка: «Если у вас только молоток, всё становится похоже на гвоздь».
Лучше сначала увидеть гвоздь, чтобы рассмотреть необходимость в молотке.
Если вам действительно нужно забить этот гвоздь.
Комментарии (14)
martin_wanderer
25.06.2018 11:33Это превосходный пример узкого фокуса: целью было открыть замок с минимальным усилием.
Или наоборот, кто-то смотрел достаточно широко, чтобы задуматься о необходимости минимального подтверждения намерений пользователя перед потенциально небезопасным действием.Hellsy22
25.06.2018 12:02Да, такое поведение может быть опцией, но никак не действием по-умолчанию. Я бы туда еще и опциональную защиту проверкой отпечатка или кодом добавил — а ну как смартфон украдут, а пользователь не любит блокировку экрана?
Мне кажется, что проблема с приложениями ровно обратная — их облегчают настолько, что не остается даже элементарных опций, позволяющих использовать приложение более чем одним путем.Makc_K
25.06.2018 13:56Всё зависит от контекста. Если это входная дверь в квартиру, то я 10 раз подумаю над мыслью а стоит ли автоматизировать её открытие.
Если же мы разрабатываем систему дверей между отсеками на условном крейсере «Ентерпрайз», то автоматическое открывание по какому-то идентификатору личности, передаваемому по беспроводному каналу вполне может оказаться уместным.Dart_Zaiac
26.06.2018 09:31Опять же важен контекст. В Канаде настолько низкий уровень преступности, что двери домов вообще не запираются. Так что автооткрывальщик, как бы придворник, вполне может подойти.
А в классическом случае «подойти, чтобы отпереть» я бы тоже не хотел. Хоть бы отпечаток пальца
ihouser
25.06.2018 13:05Кто то ломится в дверь. Подошел глянуть — упс, дверь открылась…
JediPhilosopher
26.06.2018 16:24Типичный сюжет для ночного кошмара: кто-то ломится в дверь, я подхожу к ней и вижу что все замки почему-то открыты и остался один, который тоже открывается на глазах, и дверь уже начинает приоткрываться. Я начинаю спешно запирать, они снова отпираются…
Забавно узнать, что в реальности такой сценарий тоже возможен, да.
akurilov
25.06.2018 23:32+1Все эти манагерские песни быстро сменяются на противоположные, когда приходит время исправлять баги и вносить изменения в дизайн. "Нужно быть flexible" или даже (боги упасите) "разбираться в чужом коде". Т.е. когда нужно хренак и в продакшен — никто, кроме инженегра, не печётся о дизайне (фактически — о будущем). Дизайн, рефакторинг — это всё потом, а сейчас нужно быстро и грязно удовлетворять клиентов.
Здесь просто разные интересы. У разработчика — свои, а у манагера — свои. Соответственно, разработчик должен аргументтировать свою позицию и защищать свои интересы (чтобы потом исправлеия/изменения не были мучительной болью). Не дали время на вдумчивое исправление дизайна — извиняйте, в следующий раз проблемы будут потяжелее.
max1gu
26.06.2018 09:54+1Да, но: «шуруп, забитый молотком, лучше, чем гвоздь, закрученный отверткой»
akurilov
26.06.2018 12:15Возвращаясь к статье. У инженера цель — зп + наличие хороших молотка и отвёртки под рукой. Забитые шурупы и закрученные гвозди — это цели высокого менеджмента. И надо понимать разницу между целями разных людей
noodles
28.06.2018 00:44Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.
Если мы используем Bluetooth и предполагаем, что владелец телефона может войти в дом, зачем заставлять его доставать телефон и нажимать кнопку? Пусть дверь сама отпирается, когда телефон находится в радиусе 1 метра. Не нужно тратить время на дизайн и код графического интерфейса!
Этот вывод должен делать ux-проектировщик/продакт/аналитик/манагер/etc, а не разработчик.Oxoron
28.06.2018 10:21+1программисты забыли… вывод должен делать ux-проектировщик/продакт/аналитик/манагер/etc, а не разработчик.
Споры об определениях
thomasRim
Чтобы познать дао кода, нужно написать много кода. Не написав много кода ты не познаешь ничего.
Makc_K
Ещё надо читать умные книги, да и не просто читать, а критически оценивать то, что пишут. Развивать системное мышление, общаться с людьми — пользователями, понимать их проблемы, которые решает ПО.
nexus478
Это необходимое, но не достаточное условие. Важен не сам опыт, а его осмысление. Человек может годами воспроизводить одни и те же ошибки, и если он не способен в достаточной мере анализировать свои решения, то он может написать хоть тысячу строк, хоть миллион, но это ему слабо поможет.