Три закона разработки

Думаю, многие слышали о законах роботехники, сформулированных Айзеком Азимовым:

1. Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинён вред.
2. Робот должен повиноваться всем приказам, которые даёт человек, кроме тех случаев, когда эти приказы противоречат Первому Закону.
3. Робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам.

Эти законы являются высокоуровневой моделью поведения каждого «правильного» (по версии Азимова) робота, но на этом их призвание не ограничивается.

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

Общий смысл

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

Если поднять уровень абстракции этих законов, то мы получим такие три пункта:

1. Инструмент должен быть безопасен для человека.
2. Инструмент должен выполнять свою функцию (делать жизнь человека лучше), если это не противоречит первому закону.
3. Инструмент должен быть безопасен для себя, если это не противоречит первым двум законам.

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

Чуть интереснее применить эти законы к государству (это пример взят из Википедии):

1. Государство не должно вредить людям или своим бездействием допустить, чтобы им был причинён вред.
2. Государство должно выполнять свои функции, если они не противоречат Первому Закону.
3. Государство должно заботиться о своей безопасности, если это не противоречит Первому и Второму Законам.

Все верно, ведь государство – это инструмент, созданный народом, чтобы жизнь была лучше. По крайней мере, так задумывалось.

Три закона программы

Программы – это тоже инструменты. Их создают для того, чтобы сделать нашу жизнь лучше: упростить учет, позволить общаться с сотнями друзей из разных уголков мира, узнавать свежие новости… Применять вариант трех законов, описанный выше к таким вещам скучно: большинство из этих вещей не угрожают нашему здоровью (мед. оборудование сейчас не рассматриваем). Можно, конечно, выжать достаточно косвенные вещи:

1. Приложение должно сохранять личные данные пользователя конфиденциальными, не показывать детям жестокие кадры и не разжигать ненависть и национальную вражду (это я только что читал новую политику Google Play).
2. Приложение должно делать то, для чего было создано. Например, оно должно позволять выкладывать фото с дак-фейсом в интернет, но только если на этой фотографии нет жестоких кадров, которые могут травмировать детскую психику.
3. Приложение должно следить за своей безопасностью: блокировать DDoS атаки на сервер, но не убирать шифрование паролей с целью снизить нагрузку на сервер и не запрещать выкладывать фотки реальным людям для уменьшения затрачиваемых ресурсов

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

Так, если все так просто, зачем было базировать это на трех законах? Разработчики должны помнить, что их приложение должно быть безопасным и сделать его таким – их первичная задача. Никаких «Я потрачу время, выделенное на добавление шифрования пароля, на прикольную свистелку» быть не должно.

Три закона разработки

Хорошо, с тем, какой должна получиться программа мы определились. Теперь посмотрим на наши приоритеты при разработке приложения по ТЗ заказчика. Для этого нам нужно еще сильнее обобщить законы, убрав из них конкретизацию «безопасность». Вот так они звучат теперь (на примере «пользователь использует инструмент»):

1. Инструмент должен удовлетворять потребности пользователя.
2. Инструмент должен делать все правильно.
3. Инструмент должен удовлетворять свои потребности.

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

1. Соответствие тех. заданию. Разработчик должен выполнять заказ в соответствии с требованиями заказчика.
2. Качество продукта. Разработчик может предлагать идеи по улучшению приложения (функциональность, интерфейс), но применять их только с разрешения разработчика. Также исходный код должен быть простым, расширяемым, гибким и аккуратный, но, опять же, должен соответствовать требованиям. Если даже одна небольшая и «ненужная» кнопка делает невозможным повторное использование всей формы (пример надуман) – стоит делать как говорит заказчик. Также сюда относится соответствие приложения гидлайнам платформы. Если заказчик топает ногами и хочет в Android-приложении расположить внизу – да будет так. Кстати, характеристики кода (аккуратность, гибкость…) расположены в случайном порядке и уточнение их приоритета – тема не этой статьи.
3. Интересы разработчика. Наконец, если какая-то функция была бы очень выгодна разработчику лично (ссылка «Сайт разработчика» в About) и это не скажется на качестве продукта и заказчик не против, — можно смело ее добавлять.

То есть, я разрабатываю приложение, периодически делаю предложения по изменению задания с целью улучшения качества приложения. Заказчик согласен – изменяем, нет – делаем как он хочет. И в About оставляю свой email.

Открытый финал

Думаю, многие любители фантастики слышали также о Нулевом Законе. Он стоит приоритетнее первого закона и говорит нам, что потребности человечества стоят превыше потребностей одного человека. Пример с бензопилой к этому закону сложно адаптировать, разе что она должна взрываться в руках Leatherface. А вот с точки зрения разработки не все так просто:

1. Если под «человечеством» понимать разработчиков же, то стоит, по возможности, делать проекты Open Source, открывая их под какой-то свободной лицензией.
2. Если речь идет о пользователях, то стоит все же ставить качество продукта превыше требований заказчика. Но это предположение заранее ложно, ведь в том примере роль человека занимает заказчик, стало быть человечество – это…

Пожалуй, на этом я остановлюсь, ведь мораль статьи проста: «Помни о приоритетах»