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