На опережение.

Дао, которое можно выразить словами, не есть постоянное дао; имя, которое можно назвать, не есть постоянное имя"

(c) Лао-цзы. «Дао-дэ-дзин»

Одно из полезных качеств, которое развивается у хорошего разработчика со временем - это телепатия. Поясню, что я имею ввиду.

Начиная с определенного уровня у разработчика приходит понимание, чего на самом деле хочет заказчик. Нет, заказчик что-то говорит, он говорит, что ему надо, но всегда существует зазор между реальностью, как она есть, и уровнем понимания самого компетентного заказчика. Этот зазор имеет наименьший размер у клиентов-технарей (embedded-системы и вообще любые хреновины, которые работают как конечный автомат) и наибольший - у финансистов. Что это за зазор, о чем вообще речь?

Любой заказчик описывает проблему в меру своей компетентности. При этом масса вещей для него проходит по категории "само собой разумеющиеся вещи, о которых и говорить-то смысла нет". Ну вода кипит при 100 градусах, а прямой угол - 90 градусов, чего тут обсуждать? Но за почти 13 лет работы контрактником я ни разу в своей жизни не встречался с заказчиком, который понимал бы, например, что такое граничные условия и исключения. Нет, на бытовом уровне они понимают, что это такое, но вот когда речь идет об их проблеме, это понимание исчезает напрочь, то есть совсем. Когда ты начинаешь рисовать диаграмму состояний системы и при этом беседовать с этим самым заказчиком, то открываются бездны оттенков и смыслов. Я люблю иллюстрировать те или иные вещи примерами, этот раз не будет исключением:

Если вы войдете в немецкий автобус (а так же вагон метро, трамвая или электрички) и поднимете голову, то увидите прямо над входом черную блестящую пластину. Это сенсор, который считает пасажиров. Штука достаточно умная: последние поколения способны отличить, например, вашу собаку от вашего же чемодана и ребенка от взрослого и понимает, вошел человек или вышел.

Зачем этот сенсор нужен? Во-первых, данные с него в реальном времени идут в центр управления движением. Собирается статистика, которая определяет загруженность тех или иных линий муниципального транспорта в разное время суток. На ходу меняется график движения транспорта (например, автобусы в случае, если народу много, начинают ехать чуть быстрее). Решается, сколько именно денег кинуть в какую именно область (билет-то общий, вы можете начать поездку на электричке, потом пересесть в метро а закончить ее автобусом, и все это будет один билет).

Так вот, приходит тут очередная модель такого сенсора плюс описание системы команд, оным управляющих. Открываю мануал (я вообще обожаю мануалы читать, некоторые из них уделывают Ле Каррэ, Агату Кристи и Честерфильда вместе взятых) и начинаю этот самый мануал вдумчиво курить.

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

- Уважаемый Херр Ку, я вижу здесь проблему.
- А... где проблема?
- Существуют конечные остановки.
- А что там?
- А там люди выходят, дверь закрывается, водитель глушит двигатель и идет обедать. И "уже никто никуда не едет" (с). А потом он возвращается, дверь открывает, снова заходят люди и только потом начинается движение. Это первая проблема. Вторая проблема - у нас в системе нет сигнала "началось движение". Нет, я конечно могу снимать данные с GPS-антенны и самостоятельно принимать решение о том, что мы вроде бы как движемся, но это нездоровая идея: не должен подсчет пассажиров зависеть от функционирования модуля, который ни к дверям, ни к пассажирам ни ухом ни рылом.
- Хм... и чо будем делать?

Я обожаю этот вопрос. Он мне всегда напоминает о судебных процессах против табачных компаний: я курил по две пачки в день каждый день, теперь у меня рак в четвертой стадии, но виновата табачная компания. Или, как было в одном сериале: мне 16 лет, я трахалась, как кролик (без кондома) nый дятел заразил меня ВИЧ, а виновата школа, которая мне об этом не рассказала.

- Если интересует мое мнение - будем генерировать искусственный сигнал "движение началось" для этого типа сенсоров сразу после того, как закроем двери.
- Ну... давай так.
- ОК, я сделаю изменения в нашей спецификации, отошлю вам на утверждение, как только получу ваше "ОК" - сделаю. (на самом деле я уже сделал, но немедленно коммитить в git все сделанное - это, как минимум, макрух ат-тахрим, и благоразумный контрактник удерживается от такого).

Читаю спецификацию дальше. Все на тот же сенсор. Но чтобы дальнейшее было понятнее, небольшое отступление:

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

- Херр Ку, вот такая нездоровая тема имеется.
- Хм... да, согласен, в этом нет Будды. А давай после каждой команды спрашивать датчик о его состоянии? На этот вопрос у датчика точно есть обратный ответ.
- Можно, но не очень хорошо.
- Почему?

И тут я рассказываю херру Ку историю, случившуюся во времена моей работы на Известный и Уважаемый автомобильный концерн, чью эмблему знают по всему миру. А там было так:

В автомобиле, на котором красовалась эмблема этого самого концерна, был GPS-сенсор. Среди прочих для этого сенсора была команда "расскажи нам, ты там живой или как". По причинам, которые обьяснять долго, сенсор на этот вопрос отвечал после достаточно долгого раздумья (и я его понимаю, иногда сложно ответить на этот вопрос однозначно). Кроме того, любой новый вопрос "ты там живой или как" прерывал процесс осознания себя сенсором и цикл начинался по-новой: сенсор снова впадал в самадхи и начинал заниматься нездоровым солипсизмом. Догадываетесь, что произошло дальше? Ага, именно оно: никто не сказал нам, сколько именно времени сенсору нужно на осознание себя в этом мире, но было сказано, что если не отвечает, то спросите еще раз. На это еще наложился еженедельный апдейт прошивки, поступавший от Известного и Уважаемого концерна, так что извращенного секаса там было с лихвой.

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

И вот из такого добра состоит примерно 70% рабочего времени контрактника в начале проекта и около 15-20% времени в его середине. Воистину, "если бы бы дома строились так же, как пишется код, первый же дятел разрушил бы цивилизацию" (с).

Как в этом выжить? Исключительно опыт и телепатия. Идеальный вариант - это когда ты видишь Бездонную Жопу еще до того, как она показалась на горизонте.

Да, чтобы два раза не вставать:

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