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