Андрей Орлов - Записки автоматизатора. Профессиональная исповедь

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

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

Много ли вы знаете программистов, способных эффективно работать более двенадцати часов подряд? Я лично знал ровно одного, который переставал делать в коде даже синтаксические ошибки на 26-м часу непрерывной работы. Но, когда эта работа все-таки заканчивалась, он сначала отсыпался, а потом уходил в недельный запой.

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

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

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

Я уже забыл, в какой книге в 1970-е годы я прочитал про этапы разработки любых больших систем, но на всю жизнь запомнил, что последние три этапа – это:

– поиски виновных;

– наказание невиновных;

– награждение непричастных.

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

Итак, не думайте, что вам за вашу работу ничего не будет. Будет, и еще как.

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

– Программное обеспечение готово, чтобы вести разные цены?

– Ну, готово.

– Я говорил, что, по моему мнению, цены должны быть разными?

– Ну, говорил.

– Так в чем же я виноват?

– А почему ты нас не убедил, что это правильно?!!

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

После прочтения этой работы может сложиться впечатление, что внедрить автоматизированную систему вообще невозможно.

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

Я должен также признаться, что по результатам внедрения мне несколько раз платили обещанную заранее премию.

Это должно вернуть вам утраченный оптимизм.

Так что успехов вам.

Итак, разбор задачи.

Тест проверяет достижения соискателя скорее по п. 2 перечня требований, приведенного перед задачей, чем по п. 3 (если вы, конечно, еще помните, что там написано) Одновременно вы получаете представление об аккуратности кода и «доверчивости» при получении исходных данных. Вот решение, которое я хотел увидеть, без заморочек синтаксисом языка.

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

ЕСЛИ НЕ КОНТРОЛЬ_НА_ВРЕМЯ (ВРЕМЯ_РАСП) ИЛИ

НЕ КОНТРОЛЬ_НА_ВРЕМЯ (ВРЕМЯ_ФАКТ)

ТО ВЫЙТИ.

Комментарий: Я бы удовлетворился и без описания функции КОНТРОЛЬ_НА_ВРЕМЯ.

РАЗНОСТЬ:= МИНУТЫ (ВРЕМЯ_РАСП) – МИНУТЫ (ВРЕМЯ_ФАКТ);

Комментарий: 1440 = 24 х 60 – количество минут в сутках, а 720 – в полусутках.

ЕСЛИ РАЗНОСТЬ <= —720

ТО РАЗНОСТЬ:= РАЗНОСТЬ + 1440

ИНАЧЕ ЕСЛИ РАЗНОСТЬ >= 720

ТО РАЗНОСТЬ:= РАЗНОСТЬ – 1440;

ЕСЛИ РАЗНОСТЬ = 0

ТО ПЕЧАТАТЬ («ПРИШЕЛ ВОВРЕМЯ»)

ИНАЧЕ ЕСЛИ РАЗНОСТЬ > 0

ТО ВЫВЕСТИ («ПРИШЕЛ РАНЬШЕ НА», ЧАС_МИН

(РАЗНОСТЬ))

ИНАЧЕ ЕСЛИ РАЗНОСТЬ < 0

ТО ВЫВЕСТИ («ОПОЗДАЛ НА», ЧАС_МИН (—РАЗНОСТЬ))

Если испытуемый не заметил, что поезд, прибывающий по расписанию в 0.05, а фактически прибывший в 23.55, не опоздал на 23 часа 50 минут, а приехал раньше на 10 минут, то это очень грустно. Если увидел, но не сообщил вам (устно или в комментарии к тексту), что решение не работает при расхождениях с расписанием более полусуток, то это просто грустно. Кодировать по блок-схемам последние сорок лет уже не требуется, а на что еще такой годится?

Наиболее поразившей меня за последнее время реакцией на эту задачу было удивленное «Как нет дат в исходных данных? Без дат вообще нельзя решить, без дат нет метода!». Я сразу почувствовал себя таким старым… Правда, как-то мы без методов обходились, поскольку объектно-ориентированных языков тогда еще не было.