• Значение имеет только одна-единственная реальность: то, что видит пользователь. Когда мы только начинали создавать многопользовательские авиасимуляторы, нам приходилось иметь дело с невероятно низкой скоростью передачи данных. Пакеты информации приходили через несколько секунд после отправления или в неправильном порядке. А зачастую и вовсе не приходили. Мы потратили недели на то, чтобы сделать сетевой код надежным, но потом зашли в тупик. Учитывая технологии того времени, обеспечить быструю и надежную передачу данных по сети было невозможно. Выход нашелся такой: программный код на каждой клиентской машине принимал решение самостоятельно. Если мой самолет на моем компьютере думает, что его сбили, значит, так оно и есть, и можно отправить сообщение всем на свете, что мой самолет сбит.
• Каждый метод должен работать сам по себе. Не обращайтесь к переменным за пределами метода. Избегайте «глобальных» переменных. У моих самых любимых методов название говорит о том, что делает метод. Вы вызываете такой метод, сообщаете ему необходимые данные, и он возвращает ответ. В идеале его можно протестировать с помощью сгенерированных тестовых данных. Если протестировать метод сам по себе нельзя и приходится ждать, пока будет закончен весь код, значит, что-то не так.
• Не пользуйтесь «магическими числами». Вы когда-нибудь видели выражения вроде «total = sales * 1.06»? Можно предположить, что «1.06» – это налог с продаж в размере 6 %. Но зачем тут гадать? Почему бы не использовать переменную (или константу) под названием SALES_TAX_RATE? Код будет легче читать. Или, что еще лучше, передать ставку налога с продаж в метод в качестве параметра. Вы можете слышать от программистов, мол, это глупо, ведь код использует больше памяти и становится громоздким. Я отвечу так: возможно, иногда несколько байт и несколько миллисекунд имеют какое-то значение, но в большинстве случаев никто никогда об этом не узнает, а преимущества в отладке, надежности и обслуживании кода компенсируют любые потери в скорости или памяти.
• Выясните, какие в вашей компании стандарты разработки кода, и придерживайтесь их. Неприятно писать код по стандарту, который вам не нравится или не кажется вам разумным. Не стесняйтесь побеседовать с начальником отдела и попытаться убедить его в необходимости изменений, но при работе с кодом надо придерживаться того стандарта, который у вас принят.
• Постарайтесь сделать так, чтобы у вас что-то работало уже на ранней стадии. Пишите код небольшими объемами и сразу же отлаживайте его. Начните думать о том, сколько кода вы можете написать без ошибок с первой попытки. Любой кусок длиной более 30 или 40 строк, скорее всего, содержит хотя бы одну ошибку. Чем быстрее вы ее обнаружите, тем быстрее будет сдан проект. Я слишком обобщаю, но суть именно в том, чтобы по очереди писать и отлаживать примерно каждые 20–40 строк кода. В крайнем случае отладку следует проводить после написания (или изменения) двух или трех методов. Потому что чем больше у вас будет непроверенного кода, тем дольше вы будете его отлаживать. Отладка двадцати строк кода занимает пять минут, сорока строк – двадцать минут, а четырехсот строк – несколько дней. Чем меньше, тем лучше. Чем проще, тем лучше. Вы будете передавать тестировщикам (QA[22], людям, чья обязанность – вылавливать баги) чистый код, и у вас будет отличная репутация.
• Занимайтесь отладкой самостоятельно. Это связано с моим предыдущим пунктом. Найдите свои ошибки раньше, чем это сделает тестировщик. Что бы вы ни делали, тестировщики всегда что-нибудь да найдут, но чем чище код, когда он попадает к ним в руки, тем лучше.
• Расскажите тестировщикам, как победить ваш код. Это вы написали код, или, по крайней мере, переписали. Никогда не передавайте его на тестирование просто так. Вместо этого напишите документацию о том, как его сломать. Расскажите, как вы тестировали код сами и как, по вашему мнению, можно его протестировать, чтобы он перестал работать. Например, вот так: «Я смог провести тестирование только с ограниченным количеством данных. Я думаю, что код будет хорошо работать с реальными данными, но посоветовал бы провести стресс-тест с тысячами транзакций». Чем больше подсказок вы дадите QA для поломки вашего кода, тем лучше.
• Начните с самого сложного. Я видел, как это правило нарушали сотни раз разными способами. Программист начинает проект и быстро сообщает, что работа готова на 90 %. Затем он вдруг заходит в тупик, и оказывается, что первые 90 % проекта заняли только 10 % времени. Так всегда случается, если программисты смотрят на проект и хотят начать с той части, которую они умеют делать. Если нужно сделать что-то новое, они сосредоточатся на пользовательском интерфейсе, чтобы показать видимый прогресс. Они убеждают себя, что легко справятся со сложной частью и оставляют ее на потом. Хороший вопрос, который можно задать программистам на начальном этапе: «Что, по-вашему, в этом проекте самое сложное?» Как только вы выясните, с этого и начинайте. Всегда. Никогда не откладывайте сложную часть на потом. Сначала сделайте то, что вас пугает.
• На вашем критическом пути не должен стоять и мешать вам по нему двигаться никто, кроме вас самих. Программисты категории ААА никогда не говорят: «Моя часть кода готова, но я жду, пока группа API напишет свой код, чтобы я мог протестировать». Или: «Подозреваю, что в коде Microsoft есть какая-то ошибка. Жду ответа от их техподдержки». Если у кого-то есть код, с которым вам нужно интегрировать свой собственный, но чужой код не работает, напишите свой собственный код, который притворится чужим. И затем используйте этот новый код как «затычку» для тестирования собственной работы. Не сидите и не ждите. Если какая-то функция Microsoft (или чья-то еще) не работает так, как указано в документации, найдите альтернативное решение. Продолжайте двигаться и доводите дело до конца. С самого начала вы должны думать о том, как устранить зависимость от других. Если у вас не получается, пусть это будет из-за вас, а не потому, что с задачей не справился кто-то другой.
Приходит человек к врачу, отставляет руку в сторону и выворачивает ее под прямым углом.
– Доктор, доктор, – говорит он, – мне больно, когда я так делаю. Вы можете мне помочь?
– Да, – отвечает врач. – Не делайте так!
Это бородатый и не очень смешной анекдот (но в нем есть доля правды!)
• Берите на себя ответственность. Если ваш код не работает, скажите: «У меня ошибка. Я ею занимаюсь». Не пытайтесь заметать баги под ковер. Примите вашу ошибку, признайте, что ее сделали именно вы, и сосредоточьтесь на том, чтобы как можно скорее это исправить. Если вас уволят за ошибку, извлеките уроки и двигайтесь дальше. Но не прячьтесь. Промахи случаются даже с лучшими из лучших. По-настоящему сильные программисты берут на себя ответственность за ошибки и не успокаиваются, пока все не исправят. Если вы тимлид, а программист постоянно придумывает отговорки, почему кто-то другой тормозит его работу или почему в багах всегда «виноват другой», гоните его вон – пусть идет работать к конкурентам. Туда ему и дорога.
• Не отвлекайтесь. В рабочее время тупить в Интернете или болтать с коллегами – это для неудачников. Если надо кому-то позвонить, это можно сделать и за обедом, если дело не слишком срочное. Если вы хотите побеждать, то и вести себя надо как победитель.
• Чтобы найти ошибку в коде, нужно начать с уменьшения объема кода до того уровня, на котором все работает. А затем постепенно добавлять код, пока не случится сбой. Допустим, у вас есть приложение с несколькими тысячами строк кода. Вы пишете метод, который вызывает некий API от Twitter. Почему-то на вызове этого метода все вылетает. Если я ваш тимлид и вы придете ко мне и скажете: «Из-за Twitter у меня код вылетает», то я отвечу: «А покажите мне ваш тестовый пример». Если в нем больше 20 строк кода, я отправлю вас обратно на рабочее место. Почти всегда лучший способ найти ошибку – уменьшить объем кода. Обычно это означает написание нового кода, который будет окружать и «нагружать» код
