Как программисты пишут часы. Опасности общих моделей

Именно так выглядят часы,
дизайн которых придумал программист

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

В рамках нашего нового продукта ребята разрабатывали интерактивные виджеты для HTML5. И, в какой-то момент, дело дошло до анимации. Естественно, анимация представляла собой красивый и плавный переход между состояниями. Действительно, программисты довольно быстро и аккуратно всё реализовали, и я, вспомнив  вебдевную молодость, выпросил недоделанный компонент "поиграться".

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

Естественно, первым делом я попытался заставить их показывать правильное время. Поскольку программисты у нас хорошие, общая установка команды "делаем, чтобы было легко пользоваться", была выполнена, и часики начали показывать текущее время довольно быстро.  

А может быть - вот так

Но тут возникла непредвиденная заминка. Часы отлично шли до тех пор, пока секундная стрелка не доходила до отметки 59. А потом... Да, вы правы. Она красиво и плавно обращалась вспять и, пройдя весь циферблат в обратном порядке, возвращалась к отметке 0.

И ведь с точки зрения программистов всё выглядело логично! Действительно, чтобы анимировать переход от значения 59 к значению 0, надо, чтобы стрелка прошла в обратном порядке все числа от 59 до 0. Вот только в реальности никто никогда не видел часы, в которых стрелка возвращалась бы назад...

Итак, что же полезного мы можем вынести из этой ситуации?

• Во-первых: чтобы описать любой объект или явление, программистам приходится строить модель. По определению модели, часть факторов из реальной жизни остаётся "за бортом". И в этот момент особенно важно следить, чтобы модель, которую построили программисты, соответствовала модели, которую строит для себя пользователь. Действительно, когда я отключил анимацию, часы стали вести себя вполне ожидаемо (хотя и не так красиво).

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

• В-третьих: обычно программисты пишут программы, а не продукты. Они увлекаются описанием объектной модели, построением архитектуры и алгоритмов, забывая о том, что продукт должен собой представлять в реальности. То есть надо возвращать их с неба на землю. Здесь сильно помогает итеративный подход и частая демонстрация промежуточных результатов владельцу продукта (честно говоря, затрудняюсь более точно перевести скрамовское сочетание product owner).

• В-четвёртых: если вы пишите ТЗ на разработку внешней команде, по возможности описывайте исходный объект или процесс из реальной жизни, который лежит в основе создаваемого ПО. Это не только позволит программистам увидеть задачу шире, чем программный код, но и вы сможете более чётко сформулировать ключевые требования. 
  
  
  С другой стороны я с огромным трудом представляю себе ТЗ, которое содержит фрагмент типа "при переходе от 59 к 0 стрелки должны двигаться по часовой стрелке". Такая детализация возможна разве что в системе жизнеобеспечения космического корабля, но мне такие задания, к сожалению, пока читать не доводилось. Поэтому описание реального объекта поможет команде более точно понять задачу.
  
  
• В-пятых: идеальный программист всегда немного аналитик. Он мыслит не только интерфейсами, классами и методами, но и объектами предметной области, понимает не только алгоритмы, но и бизнес-логику системы. И это одна из основных черт, которая отличает опытного разработчика от начинающего кодера (каким бы классным он ни был).

В заключение хочу сказать, что никоим образом не пытаюсь посмеяться над "глупыми программистами" или как-то ещё задеть их в профессиональном плане. У меня отличные ребята и классная команда. Просто есть вещи, которые кажутся настолько очевидными, что перестаёшь обращать на них внимание и видеть исключения из общих правил. И поэтому очень важно смотреть на систему с разных сторон: как менеджер по продукту, как аналитик, как программист, как пользователь системы. Попробуйте, и ваши продукты будут великолепны! Как у нас :).