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