Read the book: «Взлет и падение Sierra On-Line. Сказка с несчастливым концом», page 5

Глава 11. (1980) Ну разве не круто жить в горах?

Хвойные леса Йосемитского национального парка и в целом склонов хребта Сьерра-Невада превосходят все другие в своем роде в Америке, да и во всем мире, не только по размеру и красоте деревьев, но и по разнообразию биологических видов, и по величию гор, на которых они растут.

Джон Мьюр

Пока мы с Робертой были заняты запуском бизнеса по разработке программного обеспечения, отец Роберты вышел на пенсию – он оставил должность сельскохозяйственного инспектора округа Лос-Анджелес и переехал в городок Окхерст, штат Калифорния. Они с Новой – Робертиной мамой – купили двадцать акров земли, где планировали выращивать яблоки.

Окхерст – небольшой, в какой-то мере рассчитанный на обслуживание проезжающих туристов городок совсем рядом с Йосемитским национальным парком. Ближайший «настоящий» город – Фресно, штат Калифорния, и ехать оттуда в Окхерст нужно сорок миль по горной дороге. Если верить «Википедии», население Окхерста в 2000 году составляло всего 2829 человек.

Озеро Басс рядом с Окхерстом, штат Калифорния

Йосемитский национальный парк был и остается чуть ли не лучшим в мире местом для пеших турпоходов, и тут же рядом находится прекрасное озеро Басс.

Мы с Робертой, увидев шанс сбежать из Лос-Анджелеса, чуть ли не за одну ночь приняли решение о переезде и последовали за родителями Роберты в Окхерст.

Строго говоря, мы переехали в соседний город – Корсголд, штат Калифорния. Это на самом деле был пригород оживленного Окхерста. С тех пор Корсголд разросся, и в «Википедии» сообщается, что в нем проживает 1840 человек.

Забавно, но во время работы над этой книгой я увидел, что «Википедия» до сих пор называет Окхерст местом рождения Sierra On-Line. Учитывая, что мы продали компанию почти двадцать пять лет назад, можно понять, что с тех пор в Окхерсте с историческими событиями было туго.

Дом на фотографии выше находится как раз по тому адресу, куда мы с Робертой впервые переехали «жить в лесу». Наш дом был похож на этот, но сгорел в пожаре как раз тогда, когда мы там жили (подробнее об этом позже). Во многих ранних играх от Sierra именно этот адрес (36575 Мадж-ранч-роуд) указан как адрес компании, а наш домашний номер телефона – как телефон для звонков в службу поддержки.

Наш дом прослужил офисом компании пару месяцев, прежде чем стало очевидно, что это плохая идея. С каждым днем телефонных звонков от дилеров, дистрибьюторов, журналов и, что хуже всего, покупателей становилось все больше и больше. Казалось, что у меня больше нет времени ни на что, кроме как отвечать на телефонные звонки.

Мы с Робертой не успевали копировать дискеты и упаковывать их. Я помню, как ходил в местный бакалейный магазин и скупал все полиэтиленовые пакеты с застежкой «зиплок», какие у них только были. На какое-то время я нанял женщину из местных, которая приходила к нам домой и отвечала на звонки (и принимала заказы!). Затем я нанял пару местных детей, которые приходили к нам домой каждый день, чтобы копировать дискеты и укладывать их в пакеты.

Копии игр из Америки попали в другие страны, и это значило, что звонки, которым поначалу мы были рады, вдруг начали будить нас посреди ночи. И тогда стало ясно, что нам нужен офис.

И еще новый номер телефона.

Клеон Джонс из местной типографии усердно печатал бумажные вкладыши, которые мы называли «упаковкой» и которые прилагались к каждой проданной дискете. Мы буквально за один день перешли от просьбы воспользоваться его ксероксом до крупных заказов, благодаря которым его огромный пресс никогда не простаивал.

Клеон оказался человеком сообразительным и сам предложил нам по божеской цене арендовать у него помещение над типографией.

Глава 12. (1980) С цветом все лучше

Знаете, я играюсь с цветом своих волос с тех пор, как мне исполнилось девять лет.

Синди Лопер, певица

За первые полтора года своего существования компания Sierra выпустила десять новых игр. Половина из них работала на оригинальном игровом движке, который я создал для Mystery House.

Mystery House публика приняла хорошо, но и Роберта, и я знали, что графика игры была ужасна. Я хотел, чтобы Роберта немедленно начала работу над следующей игрой, но она уперлась и сказала: «Нет, пока ты не придумаешь, как сделать так, чтобы картинки выглядели лучше».

Изучая Mystery House, я заметил несколько вещей.

1) Роберта – не великая художница.

2) Всякий раз, когда на экране в ряд выстраивается несколько точек, они приобретают определенный цвет.

Меня заинтриговали фиолетовые и зеленые точки, и мне стало любопытно, можно ли получить и другие цвета. Я поэкспериментировал напрямую с аппаратным обеспечением на уровне машинного языка и обнаружил несколько уловок, благодаря которым на экран можно было выводить пурпурный и зеленый цвета. А еще придумал, как обмануть машину, чтобы она выдавала оранжевый и синий.

Я написал о графике на Apple II книгу, которая в те годы была лучшей и желанной для тех, кто хотел делать игры.

Роберта Уильямс, гейм-дизайнер (но едва ли великая художница)

Книга Кена о графике на Apple II

К сожалению, тот трюк, с помощью которого я сумел заставить монитор отображать цвета, был очень громоздким. Такого до меня еще никто не делал, и те, кто видел новую графику, были в восторге, но красивым результат назвать было нельзя.

Тем не менее это было все, что я мог выжать из Apple II, а Роберте нужно было продолжать работу.

Мне пришлось столкнуться с серьезными ограничениями. По-прежнему нужно было уложиться в крошечные размеры дискеты, а Роберта хотела добавить в Wizard and the Princess еще больше локаций (фонов или комнат). Чтобы обойти эту проблему, я попросил Роберту создавать векторные картинки так же, как и при работе над Mystery House, но затем щелкать мышью в любом месте любой обведенной контуром части картинки и задавать цвет заливки. По сути, это был тот же самый процесс, что в детских книжках-раскрасках, но с гораздо большими ограничениями. Была и хорошая новость: раскрашивание картинок с помощью этого приема практически не увеличивало их размеры, зато значительно улучшало их внешний вид. Все, что мне нужно было сохранить на дискете, – три байта (числа): расположение строки и столбца, где Роберта оставляла указание «нужен цвет», а затем еще одно число – код цвета, который она хотела получить. Если у меня была точка внутри замкнутого контура, я мог распространять цвет от нее во все стороны, пока не натыкался на какой-нибудь другой элемент. Например, Роберта с помощью VersaWriter рисовала ствол дерева, затем щелкала мышью в этом месте и выбирала коричневый цвет. Пока нарисованный ствол дерева представлял собой замкнутый контур, я мог алгоритмическим способом залить его нужным цветом.

К сожалению, мы наткнулись и на другие проблемы, уже непреодолимые. Я пытался победить ограничения того, какие цвета могут находиться рядом друг с другом. В пределах одного байта компьютерной памяти я мог закодировать только фиолетовый или зеленый, или же оранжевый и синий. Когда Роберте понадобилось показать на экране зеленое дерево на фоне голубого неба, случилась беда.

Вторая проблема заключалась в том, что Apple II мог создавать только шесть цветов. Что бы я ни делал, он выдавал лишь черный, белый, оранжевый, синий, зеленый и фиолетовый.

Чтобы обойти эту проблему, я смешивал разные цвета – так создавалось впечатление, что их на экране больше. Это была бы отличная идея, будь разрешение экрана повыше. Но на мониторе Apple II было только 280 горизонтальных точек (мы, компьютерщики, называем их пикселями, знаете ли) и 192 вертикальные точки. И это еще хуже. Чтобы получить цвет, я мог использовать только половину пикселей. Для сравнения, на всем экране Apple II было всего 53 760 пикселей, тогда как на моем мобильном телефоне (iPhone) – 2 740 500 пикселей, каждый из которых может принимать любой из миллионов цветов.

Wizard and the Princess, первая «цветная» приключенческая игра Sierra

На лицевой стороне вкладыша к Wizard and the Princess гордо заявлено: «В НАСТОЯЩИЙ МОМЕНТ ЭТО САМАЯ СОВЕРШЕННАЯ ГРАФИЧЕСКАЯ ИГРА, КОГДА-ЛИБО НАПИСАННАЯ ДЛЯ КОМПЬЮТЕРОВ APPLE».

Мы не лгали, но… ничего не поделаешь. Не могу сказать, что я горжусь результатом.

Покупатели были в восторге от цветной картинки! Я быстро понял, что Роберта наткнулась на золотую жилу – надо было ее разрабатывать по-крупному.

Мы немедленно запустили в разработку еще несколько приключенческих игр.

Роберта была в лучшем случае начинающей разработчицей. Тем не менее она практически в одиночку создала хит номер один среди тогдашних компьютерных игр. Она закончила разработку Wizard and the Princess и сразу же после нее выпустила следующую игру – Mission Asteroid. Роберта пахала изо всех сил, но часов в сутках у нее от этого больше не становилось.

Hi-Res Adventure #4. Ulysses and the Golden Fleece

Может быть, разработкой приключенческих игр мог бы заниматься кто-то еще?

У нас уже было несколько наемных работников, которые сидели за компьютерами и копировали диски. И один из них, Боб Дэвис, подошел ко мне и сказал, что у него есть идея для игры под названием Ulysses and the Golden Fleece.

Я дал ему полную свободу, и вскоре у меня появилась еще одна игра на продажу. Отлично!

– ИНТЕРЛЮДИЯ –
(Небольшое отступление, чтобы я мог вклинить что-нибудь другое)
Глава 13. Советы программистам

Умный человек разрешает проблему. Мудрый избегает ее.

Альберт Эйштейн

ПРИМЕЧАНИЕ. Эта глава адресована программистам и тимлидам. Остальные читатели, возможно, предпочтут (а может, и не предпочтут) перейти сразу к следующей главе.

Есть на свете одна книга, которую я бы порекомендовал всем, кто хочет построить карьеру программиста, или тем, кто хочет заниматься яхтингом, да и всем остальным тоже: «Дзэн и искусство ухода за мотоциклом»¹⁷. Эта книга оказала огромное влияние на мою карьеру разработчика программного обеспечения, а спустя десятилетия – еще и капитана яхты.

Тем не менее я не могу утверждать, что по-настоящему прочитал эту книгу. Я пытался сделать это несколько раз и действительно прочел ее от корки до корки, но так и не смог до конца понять все, что прочел. Автор этого творения, Роберт Пёрсиг, был профессором в университете и писал так, как можно ожидать от профессора. Его роман автобиографичен – читается он как блог о путешествии по стране на мотоцикле, которое Пёрсиг совершил со своим сыном Крисом. Как пишет сам автор, эта книга имеет очень мало отношения к дзэн-буддизму или уходу за мотоциклами. Вместо этого книга посвящена скорее его личным размышлениям на тему отношения к окружающему миру.

Я мыслю в категориях «вынесенных уроков», и для меня было не так важно, о чем на самом деле книга. Главное – что удалось вынести из ее прочтения.

Что именно я оттуда вынес:

• Как анализировать проблему.

• Как разбить большую проблему на мелкие части.

• Как определить, что по-настоящему важно.

Моя философия разработки программного обеспечения выросла из чтения книг Пёрсига (он написал и еще одну книгу, «Лайла»¹⁸ – своего рода продолжение первой книги; в «Лайле» он рассказывает о яхтах и путешествиях). В частности, эта книга помогла мне начать думать о двигателе или даже о программе как о комплексе подсистем, у каждой из которых есть какая-то определенная функция или цель.

Например, когда я думаю о дизельном двигателе, я думаю о нем не просто как о цельной «силовой установке». Я пытаюсь думать о нем как о комплексе систем: топливная система, система впуска воздуха, система охлаждения, система смазки, выхлопная система и т. д. Если вы можете смотреть на что-то и воспринимать это как комплекс подсистем, становится легче диагностировать проблемы и понимать, как работают отдельные компоненты.

Это привело меня к правилу номер один в разработке программного обеспечения:

Чем меньше, тем проще.

Кен Уильямс

Первый шаг в анализе любой проблемы – разбить ее на ряд более мелких частей.

Мало у кого столько опыта работы с самыми разными программами, сколько есть у меня. Я работал над сотнями программных продуктов и уже больше сорока лет непрерывно разрабатываю программное обеспечение.

Чем меньше и проще будет ваша программа, тем больше вероятность того, что она заработает как надо с первой попытки. Многие программисты гордятся тем, что находят сложные решения проблем. Я видел, как они часами мучаются над куском кода, пытаясь заставить его работать быстрее или потреблять чуть меньше байтов. Им, похоже, нравится писать код, где можно выпендриться мастерством программирования.

К сожалению, есть на свете и организации, в которых подобные подвиги ценят и вознаграждают. Но я смотрю на это по-другому.

Прежде чем я расскажу об этом, давайте на секунду отвлечемся вот на что.

Любую работу следует начинать с определения ее цели. Если вы пишете новый код, подумайте о том, как часто он будет выполняться. Подумайте о том, предназначена ли программа для использования внутри компании, или ей будут пользоваться клиенты. Подумайте о том, часто ли этой программе нужна будет поддержка. Подумайте об объеме обрабатываемых данных и т. д. Попытайтесь представить себе, какую роль будет играть этот код в продукте в целом.

Пример: я видел, как программисты целыми днями корпят над оптимизацией какого-то кода, который потом будут запускать от силы пару раз в неделю. Имеет ли значение, сколько времени занимает работа программы – 10 миллисекунд или 10 секунд? В некоторых случаях да, но обычно нет. Возможно, если писать код «небрежно», его будет легче читать и поддерживать, и к тому же вы быстрее все доделаете.

Концепция «код должен работать быстро» не так однозначна, как может показаться

Часто цель работы – угодить начальству, поэтому не воспринимайте мои слова чересчур серьезно и делайте все возможное, чтобы непосредственный руководитель был вами доволен. Это он отвечает за ваш карьерный рост, а не я. Тем не менее стоит знать, что скорость выполнения задач и строгость написания кода – не священный Грааль, как вам могли вбивать в голову в вузе.

Если вы программист или тимлид и хотите вынести из прочтения этой книги один урок, вот что я предлагаю запомнить:

Если в проекте работы на час, он будет готов через час. Если в нем работы на четыре часа, он займет день. Если в нем работы на день, он займет всю неделю. Если на неделю, он займет пару месяцев. Проекты, в которых работы на полгода и больше, как правило, не заканчиваются никогда.

Кен Уильямс

Запишите это. Это один из самых важных уроков в разработке программного обеспечения.

Чем меньше получатся кусочки, из которых состоит ваш проект, тем быстрее вы справитесь. Поэтому, если вам поручили большой проект, начать стоит с разделения его на ряд более мелких. Разделяй и властвуй. Если у вас получится распределить силы по мелким проектам, вы уложитесь в рамки времени и бюджета. А если не сможете – придется искать оправдания, чтобы выкрутиться. На хороших оправданиях можно протянуть не один год, так что это не конец света. Но нет ничего плохого и в том, чтобы сразу победить.

Если вы тимлид, заставьте своих программистов описать подход к написанию кода. Не позволяйте им приступать к работе, пока они не разобьют проект на мелкие кусочки. Требуйте список задач.

Приготовьтесь услышать такую фразу: «Не учите ученого, не надо меня по мелочам контролировать». Я не раз слышал подобное, и не только от программистов. В ней есть доля правды. Отличных программистов не надо контролировать по мелочам. Тем не менее у отличных программистов к моменту начала работ уже будет выстроен план, а проект разбит на мелкие части. Если этого не было сделано, то стоит задуматься, так ли он хорош.

Еще одна популярная фраза, которую часто можно услышать от исполнителей: «Я не знаю, сколько времени это займет. В процессе». Я считаю такой ответ неприемлемым. Лучше было бы сказать: «Я сейчас потрачу пару дней на изучение кода, а затем составлю план работ. Вот тогда я смогу дать точные оценки по срокам».

Нет правил без исключений, но я куда больше ценю надежность, читабельность и поддерживаемость кода, чем скорость выполнения или «строгость». И если вы постоянно пишете код, пытаясь увидеть его глазами какого-то другого программиста, которому через пару лет предстоит вносить в него изменения, вы обнаружите, что работа как по волшебству завершается в срок и в рамках бюджета. Код будет быстрее отлаживаться и надежнее работать на продакшене¹⁹.

И, как всегда, все начинается с «проще значит лучше». Лучший код выглядит до безобразия просто.

Обычно я начинаю написание кода с определения имен методов (подпрограмм)²⁰. Мне нравятся функциональные блоки с именами, которые четко говорят, что такая подпрограмма делает – типа get_input_from_customer («принять ввод от клиента») или put_record_to_database («отправить запись в базу данных»). Я стараюсь, чтобы функциональность процедуры сводилась к тому, что указано в названии метода. Другими словами, в методе под названием validate_customer_number («проверить номер клиента») не надо делать ничего, кроме проверки номера клиента. Если для этого вам нужно выполнить какую-то другую работу, вызовите для нее другой метод. Постарайтесь, чтобы каждый отдельно взятый метод занимал не более двадцати строк кода. Если для проверки номера клиента нужно провести, например, проверку того, активен ли счет клиента, вызовите метод check_customer_account_active («проверить, активен ли счет клиента»). Не помещайте предназначенный для этого код в тот же самый метод. Зачем это делать, если и надо-то всего четыре или пять строк кода? Ответ такой: большинство программистов в состоянии написать несколько строк кода и заставить этот метод из нескольких строк работать с первой попытки. При этом метод из 25 строк требует экспоненциально больше времени для отладки, чем кусок кода на 20 строк. Уж поверьте: надо быть простым как валенок. Используйте до омерзения длинные имена переменных. И вы закончите работу быстрее, чем «вундеркинд» за соседним столом.

Некоторые другие вещи, о которых стоит подумать…

Остерегайтесь логического отрицания (NOT). Всегда представляйте, что другой программист, которому предстоит поддерживать ваш код, – новичок, и вам надо ему помочь. Новичка очень легко сбить с толку конструкциями типа if (not customer_number is null)… Если вы постараетесь, чтобы код содержал как можно меньше отрицаний, вам самим будет проще его читать. Возможно, стоит подумать и о том, чтобы добавить метод для определения номера клиента. Конструкцию if (isValid(customer_number))… будет легче читать будущим кодерам.

В качестве примера того, как можно ускорить работу и при этом не спешить, я расскажу о своем подходе к большим сложным проектам по обслуживанию.

• Прежде чем изменить какую-либо часть кода, я один раз прохожусь по всему коду в целом, чтобы уловить, какие данные тут задействованы и что код в целом делает.

• Затем я рефакторю²¹ код. Обычно я трачу день на переработку кода, разбивая большие методы на множество более мелких. Я ищу логические отрицания и преобразую код в позитивный. Я ищу сегменты кода с отступами более одного или максимум двух уровней и выделяю их в отдельные методы. Я ищу длинные методы, выполняющие десять различных действий, и разбиваю их на десять отдельных методов. Я ищу избыточный код и выделяю его в отдельный метод или класс. (Примечание: в процессе этой работы надо добавить комментарии, которые могут быть полезны будущим разработчикам и вам самим.)

• Затем я удостоверяюсь, что код по-прежнему выполняет то, что делал раньше.

Рефакторинг позволяет мне «проникнуть внутрь» программного кода и понять, что он делает. На этом этапе кажется, что проект стоит на месте или даже откатывается. Но после рефакторинга у меня уже есть понимание, сколько времени займет проект, и база исходного кода, с которой я могу работать. Что еще более важно, этой базой сможет воспользоваться другой программист, не проходя через ту же боль, что прошел я.

Еще несколько «правил» разработки программного обеспечения, большинство из которых основаны на здравом смысле и до боли очевидны, но я все равно включу их сюда:

• Используйте самоочевидные имена переменных и методов. Звучит как что-то из самого базового курса программирования, но поразительно, как много на свете программистов, которым об этом надо напоминать. Старайтесь не использовать имена переменных типа «foo» или «x». Гораздо лучше имена типа customer_number.

• Не используйте для одной и той же цели два разных имени переменных. Если в одном месте кода у вас будет переменная cust_num, а в другом месте те же данные будут обозначаться другой переменной customer_number, вы запутаетесь. Если нужно, определяйте где-то имя переменной, и не пишите его по-разному – например, db.customer_number и input.customer_number.

• Конечный пользователь не должен сидеть без дела. Это философия проектирования, а не стандарт программирования, но об этом определенно стоит подумать, работая с кодом. Конечным пользователям (людям, которые в итоге пользуются программой) трудно долго концентрироваться на одном предмете. Я всегда придерживался правила «семи секунд». Человека, сидящего перед компьютером, нужно каким-то образом задействовать каждые семь секунд. Может, и семь раз в секунду, но… я лично готов потерпеть в худшем случае семь секунд. Даже если это означает просто попросить пользователя «Нажмите ввод», нужно чем-то его занять. Не позволяйте ему скучать.

• Чем больше вопросов на странице, тем более запутанным становится пользовательский интерфейс. Если вы разрабатываете экран ввода данных, будьте проще. Не беспокойтесь о том, что пользователю, возможно, придется нажать «ввод» двадцать раз или несколько раз обновлять экран. Для конечного пользователя нет ничего хуже, чем неразбериха и непонимание, куда жать. Помните мантру: будьте просты как валенок.

• Значение имеет только одна-единственная реальность: то, что видит пользователь. Когда мы только начинали создавать многопользовательские авиасимуляторы, нам приходилось иметь дело с невероятно низкой скоростью передачи данных. Пакеты информации приходили через несколько секунд после отправления или в неправильном порядке. А зачастую и вовсе не приходили. Мы потратили недели на то, чтобы сделать сетевой код надежным, но потом зашли в тупик. Учитывая технологии того времени, обеспечить быструю и надежную передачу данных по сети было невозможно. Выход нашелся такой: программный код на каждой клиентской машине принимал решение самостоятельно. Если мой самолет на моем компьютере думает, что его сбили, значит, так оно и есть, и можно отправить сообщение всем на свете, что мой самолет сбит.

• Каждый метод должен работать сам по себе. Не обращайтесь к переменным за пределами метода. Избегайте «глобальных» переменных. У моих самых любимых методов название говорит о том, что делает метод. Вы вызываете такой метод, сообщаете ему необходимые данные, и он возвращает ответ. В идеале его можно протестировать с помощью сгенерированных тестовых данных. Если протестировать метод сам по себе нельзя и приходится ждать, пока будет закончен весь код, значит, что-то не так.

• Не пользуйтесь «магическими числами». Вы когда-нибудь видели выражения вроде «total = sales * 1.06»? Можно предположить, что «1.06» – это налог с продаж в размере 6 %. Но зачем тут гадать? Почему бы не использовать переменную (или константу) под названием SALES_TAX_RATE? Код будет легче читать. Или, что еще лучше, передать ставку налога с продаж в метод в качестве параметра. Вы можете слышать от программистов, мол, это глупо, ведь код использует больше памяти и становится громоздким. Я отвечу так: возможно, иногда несколько байт и несколько миллисекунд имеют какое-то значение, но в большинстве случаев никто никогда об этом не узнает, а преимущества в отладке, надежности и обслуживании кода компенсируют любые потери в скорости или памяти.

• Выясните, какие в вашей компании стандарты разработки кода, и придерживайтесь их. Неприятно писать код по стандарту, который вам не нравится или не кажется вам разумным. Не стесняйтесь побеседовать с начальником отдела и попытаться убедить его в необходимости изменений, но при работе с кодом надо придерживаться того стандарта, который у вас принят.

• Постарайтесь сделать так, чтобы у вас что-то работало уже на ранней стадии. Пишите код небольшими объемами и сразу же отлаживайте его. Начните думать о том, сколько кода вы можете написать без ошибок с первой попытки. Любой кусок длиной более 30 или 40 строк, скорее всего, содержит хотя бы одну ошибку. Чем быстрее вы ее обнаружите, тем быстрее будет сдан проект. Я слишком обобщаю, но суть именно в том, чтобы по очереди писать и отлаживать примерно каждые 20–40 строк кода. В крайнем случае отладку следует проводить после написания (или изменения) двух или трех методов. Потому что чем больше у вас будет непроверенного кода, тем дольше вы будете его отлаживать. Отладка двадцати строк кода занимает пять минут, сорока строк – двадцать минут, а четырехсот строк – несколько дней. Чем меньше, тем лучше. Чем проще, тем лучше. Вы будете передавать тестировщикам (QA²², людям, чья обязанность – вылавливать баги) чистый код, и у вас будет отличная репутация.

• Занимайтесь отладкой самостоятельно. Это связано с моим предыдущим пунктом. Найдите свои ошибки раньше, чем это сделает тестировщик. Что бы вы ни делали, тестировщики всегда что-нибудь да найдут, но чем чище код, когда он попадает к ним в руки, тем лучше.

• Расскажите тестировщикам, как победить ваш код. Это вы написали код, или, по крайней мере, переписали. Никогда не передавайте его на тестирование просто так. Вместо этого напишите документацию о том, как его сломать. Расскажите, как вы тестировали код сами и как, по вашему мнению, можно его протестировать, чтобы он перестал работать. Например, вот так: «Я смог провести тестирование только с ограниченным количеством данных. Я думаю, что код будет хорошо работать с реальными данными, но посоветовал бы провести стресс-тест с тысячами транзакций». Чем больше подсказок вы дадите QA для поломки вашего кода, тем лучше.

• Начните с самого сложного. Я видел, как это правило нарушали сотни раз разными способами. Программист начинает проект и быстро сообщает, что работа готова на 90 %. Затем он вдруг заходит в тупик, и оказывается, что первые 90 % проекта заняли только 10 % времени. Так всегда случается, если программисты смотрят на проект и хотят начать с той части, которую они умеют делать. Если нужно сделать что-то новое, они сосредоточатся на пользовательском интерфейсе, чтобы показать видимый прогресс. Они убеждают себя, что легко справятся со сложной частью и оставляют ее на потом. Хороший вопрос, который можно задать программистам на начальном этапе: «Что, по-вашему, в этом проекте самое сложное?» Как только вы выясните, с этого и начинайте. Всегда. Никогда не откладывайте сложную часть на потом. Сначала сделайте то, что вас пугает.

• На вашем критическом пути не должен стоять и мешать вам по нему двигаться никто, кроме вас самих. Программисты категории ААА никогда не говорят: «Моя часть кода готова, но я жду, пока группа API напишет свой код, чтобы я мог протестировать». Или: «Подозреваю, что в коде Microsoft есть какая-то ошибка. Жду ответа от их техподдержки». Если у кого-то есть код, с которым вам нужно интегрировать свой собственный, но чужой код не работает, напишите свой собственный код, который притворится чужим. И затем используйте этот новый код как «затычку» для тестирования собственной работы. Не сидите и не ждите. Если какая-то функция Microsoft (или чья-то еще) не работает так, как указано в документации, найдите альтернативное решение. Продолжайте двигаться и доводите дело до конца. С самого начала вы должны думать о том, как устранить зависимость от других. Если у вас не получается, пусть это будет из-за вас, а не потому, что с задачей не справился кто-то другой.

Приходит человек к врачу, отставляет руку в сторону и выворачивает ее под прямым углом.

– Доктор, доктор, – говорит он, – мне больно, когда я так делаю. Вы можете мне помочь?

– Да, – отвечает врач. – Не делайте так!

Это бородатый и не очень смешной анекдот (но в нем есть доля правды!)

• Берите на себя ответственность. Если ваш код не работает, скажите: «У меня ошибка. Я ею занимаюсь». Не пытайтесь заметать баги под ковер. Примите вашу ошибку, признайте, что ее сделали именно вы, и сосредоточьтесь на том, чтобы как можно скорее это исправить. Если вас уволят за ошибку, извлеките уроки и двигайтесь дальше. Но не прячьтесь. Промахи случаются даже с лучшими из лучших. По-настоящему сильные программисты берут на себя ответственность за ошибки и не успокаиваются, пока все не исправят. Если вы тимлид, а программист постоянно придумывает отговорки, почему кто-то другой тормозит его работу или почему в багах всегда «виноват другой», гоните его вон – пусть идет работать к конкурентам. Туда ему и дорога.

• Не отвлекайтесь. В рабочее время тупить в Интернете или болтать с коллегами – это для неудачников. Если надо кому-то позвонить, это можно сделать и за обедом, если дело не слишком срочное. Если вы хотите побеждать, то и вести себя надо как победитель.

• Чтобы найти ошибку в коде, нужно начать с уменьшения объема кода до того уровня, на котором все работает. А затем постепенно добавлять код, пока не случится сбой. Допустим, у вас есть приложение с несколькими тысячами строк кода. Вы пишете метод, который вызывает некий API от Twitter. Почему-то на вызове этого метода все вылетает. Если я ваш тимлид и вы придете ко мне и скажете: «Из-за Twitter у меня код вылетает», то я отвечу: «А покажите мне ваш тестовый пример». Если в нем больше 20 строк кода, я отправлю вас обратно на рабочее место. Почти всегда лучший способ найти ошибку – уменьшить объем кода. Обычно это означает написание нового кода, который будет окружать и «нагружать» код с ошибкой. Программисты вечно сопротивляются этому подходу – не хотят отклоняться от основного дела и потратить четыре часа на написание какого-то фреймворка-подпорки для неработающего метода. Практически во всех случаях, когда я давлю на программиста, заставляя его вытащить неработающий код из полного приложения и запустить отдельно, оказывается, что код-таки работает или в нем быстро обнаруживается баг. Ошибку, затерянную среди тысяч строк кода, найти практически невозможно. Но если сократить область поисков до 50–100 строк кода, проблема будет найдена за считаные минуты. Не бойтесь отвлечься на несколько часов, чтобы создать «испытательный стенд» (фреймворк) для поиска неуловимой ошибки. Это решение работает в 99 % случаев.