• Не пишите код, привязанный ко времени выполнения. Иногда вы будете сталкиваться с кодом, который основан на временном интервале. Самый вопиющий пример, который я встречаю чаще всего, – это код, который ждет завершения какой-то другой задачи, а через полсекунды уже считает, что она завершилась. Такой код обычно работает на компьютере разработчика, но в реальных условиях идет вразнос – может, соединение с Интернетом слишком медленное, может, у пользователя слишком старый компьютер. Хуже кода с ошибкой может быть только «код с ошибкой, которая проявляется только при определенных условиях». Такие баги невероятно трудно найти и связать с кодом, который писали, исходя из предположений об определенном наборе условий работы. Правильный код «знает», что некоторые машины работают ужасно медленно, а некоторые срабатывают мгновенно. Иногда на соединение с интернетом можно положиться, иногда оно еле-еле передает данные или вообще неожиданно обрывается. Программисты категории 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) отрицательных числа
• Умножить очень маленькое случайно выбранное отрицательное число на очень большое случайно выбранное положительное число
• Умножить два целых случайно выбранных числа
Этот тест занял минут пять,
