Читать книгу - "Взлет и падение Sierra On-Line. Сказка с несчастливым концом - Кен Уильямс"

с ошибкой. Программисты вечно сопротивляются этому подходу – не хотят отклоняться от основного дела и потратить четыре часа на написание какого-то фреймворка-подпорки для неработающего метода. Практически во всех случаях, когда я давлю на программиста, заставляя его вытащить неработающий код из полного приложения и запустить отдельно, оказывается, что код-таки работает или в нем быстро обнаруживается баг. Ошибку, затерянную среди тысяч строк кода, найти практически невозможно. Но если сократить область поисков до 50–100 строк кода, проблема будет найдена за считаные минуты. Не бойтесь отвлечься на несколько часов, чтобы создать «испытательный стенд» (фреймворк) для поиска неуловимой ошибки. Это решение работает в 99 % случаев.

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

• Действительно ли нужна эта фича? Если в продукте есть какая-то функция или свойство, из-за которого проект в целом становится намного сложнее, обсудите эту проблему и предложите альтернативное решение. Если функция очень нужна, ну, значит нужна, но так бывает не всегда. Никто не осудит вас за критику в духе: «Думаю, если мы уберем этот элемент или реализуем его другим способом, мы быстрее доделаем проект, а финальный код будет надежнее». Если позже окажется, что вы были правы, и фича, против которой вы высказывались, обернется ящиком Пандоры, о вашем предложении вспомнят – это вы отстаивали альтернативный и более простой подход. Даже если вы «всего лишь» кодер, не стесняйтесь задавать вопросы о дизайне проекта. При этом не будьте назойливы. Указывайте на проблемы, которые видите, и убедитесь, что вы действительно понимаете, что должен делать написанный вами код. Но в конце концов, когда придет время приступить к работе, надо будет молча засучить рукава и кодить.

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

• Как можно быстрее дайте заказчику что-то, что можно попробовать. То, что просит заказчик, неизбежно отличается от того, что ему на самом деле надо. Если в ваш код придется внести изменения, то чем раньше вы об этом узнаете, тем быстрее можно будет начать. Уже с самого начала проекта подумайте, как создать рабочий прототип.

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

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

• И всегда помните: важнее всего – понять, чего хочет ваш руководитель, и дать ему это. Если начальство хочет, чтобы вы сделали какую-то глупость, сделайте ее лучше, чем начальство могло себе представить. Даже если вы двигаетесь куда-то не туда, но руководитель желает двигаться именно в этом направлении, значит, так и надо. Не стесняйтесь доказывать, почему вы считаете что-то неправильным, но, когда придет время приступать к работе, не надо игнорировать пожелания руководителя и делать все по-своему. Если вы так поступите, то работу вы, может, и сделаете, но оттолкнете руководителя и не получите повышения. Нет, начальник не всегда прав, иногда подчиненных просят делать что-то бессмысленное. Если вы попытались переубедить руководителя, а он все равно настаивает на том, чтобы двигаться в неправильном, на ваш взгляд, направлении, у вас есть два варианта: ехать куда велели или хлопнуть дверью. Решать вам. Но не пытайтесь бороться с системой.

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

В те времена, когда еще не было ЭВМ общего назначения, один господин по фамилии Дейкстра построил машину для умножения чисел. Эту машину хотело купить датское правительство, но чиновникам нужна была уверенность в том, что ЭВМ можно доверять. Для «тестирования» машины была собрана специальная группа контроля качества. Тестировщики начали перемножать на машине числа и через две недели получили следующие результаты: 1 × 2 = 2, 1 × 3 = 3, … 2 × 3 = 6 и так далее. Они добрались до 120 × 12 = 1440, когда у чиновников лопнуло терпение. Тестировщики пожали плечами и сказали: «А что еще нам остается делать?» Дейкстра занервничал. Для него это была большая сделка, и ему нужны были деньги. Он умолял чиновников завершить продажу, но безуспешно. Наконец, спустя несколько недель, когда команда только приступила к умножению четырехзначных чисел на однозначные, а жена Дейкстры запретила ему спать с ней в общей постели, Дейкстра решил, что пора поискать какой-то способ ускорить тестирование.

Именно тогда его посетило важное откровение.

«Чисел на свете бесконечно много. Нельзя взять и перемножить все числа. Такой проект будет продолжаться бесконечно долго», – сказал Дейкстра. Он знал, что тестировщики пошли по ложному пути. Он взялся размышлять, как же помочь команде, учитывая, что от этого еще и зависел его брак. Как насчет случайной генерации чисел? Если группа контроля качества произвольно сгенерирует 1000 чисел, а машина выдаст для каждого результат, то можем ли мы утверждать, что числа между ними тоже будут правильными? «Может быть», – сказали чиновники.

Наконец, поразмыслив еще немного, он придумал следующий тест.

• Умножить 0 на случайно выбранное положительное число

• Умножить 0 на 0

• Умножить случайно выбранное отрицательное число на 0

• Умножить два случайно выбранных отрицательных числа

• Умножить два очень маленьких случайно выбранных (например, 0,00000000000123) положительных числа

• Умножить два очень больших случайно выбранных (например, – 123 937 983 416 125 371) отрицательных числа

• Умножить очень маленькое случайно выбранное отрицательное число на очень большое случайно выбранное положительное число

• Умножить два целых случайно выбранных числа

Этот тест занял минут пять,