Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО
Грязь, болота и трясины
Грязь еще хуже, чем тупик. Она вас замедляет, но не останавливает полностью. Грязь препятствует вашему продвижению, но вы все равно можете двигаться вперед, действуя методом «грубой силы». Грязь опаснее тупиков, потому что вы всегда видите путь впереди, и он всегда кажется короче, чем путь назад (хотя на самом деле это не так).
Я видел продукты и целые компании, уничтоженные грязью в программном коде. Я видел, как производительность работы групп падала едва ли не до нуля всего за несколько месяцев. Ничто не оказывает более основательного и долгосрочного отрицательного эффекта на производительность группы программистов, чем грязь в программном коде. Ничто.
Проблема в том, что возникновение грязи, как и тупики, неизбежно. Опыт и благоразумие помогут вам избегать его, но рано или поздно вы примете решение, которое заведет вас в грязь.
Возникновение грязи весьма коварно. Вы создаете решение простой задачи, всеми силами стремясь к тому, чтобы код оставался простым и чистым. С ростом масштаба и сложности задачи вы расширяете ее кодовую базу, по возможности стараясь сохранять ее чистоту. В какой-то момент вы понимаете, что изначально приняли неверное архитектурное решение и ваш код плохо масштабируется в направлении смещения требований.
Здесь и находится критическая точка! Вы все еще можете вернуться и исправить архитектуру. Но вы также можете продолжить движение вперед. Кажется, что возврат обойдется слишком дорого, потому что вам придется перерабатывать существующий код, однако в будущем он обойдется еще дороже. Если вы будете двигаться вперед, то система сползет в грязь, и вполне возможно, что она из нее уже не выберется.
Профессионалы опасаются грязи намного сильнее, чем тупиков. Они всегда обращают внимание на грязь, которая начинает неограниченно разрастаться, и прикладывают все необходимые усилия к ее устранению – по возможности раннему и быстрому.
Движение вперед по грязи (когда вы знаете, что это грязь) является худшей из разновидностей инверсии приоритетов. Двигаясь вперед, вы обманываете себя, обманываете вашу группу, обманываете свою компанию и заказчиков. Вы говорите им, что все будет хорошо, хотя на самом деле вы ведете их к общей катастрофе.
Заключение
Профессиональные разработчики серьезно относятся к управлению своим временем и концентрацией. Они понимают соблазн инверсии приоритетов и борются с ним, поскольку это является делом чести. Они непредвзято относятся к альтернативным решениям. Они никогда не увлекаются решением настолько, что не могут отказаться от него. А еще они всегда следят за возможным возникновением грязи и вычищают ее при первых признаках. Нет более печального зрелища, чем группа разработчиков, бесцельно плетущаяся по постоянно углубляющейся трясине.
10
Оценки
Оценка – одно из самых простых, но при этом самых рискованных задач, с которыми сталкиваются профессиональные разработчики. От оценки напрямую зависит коммерческая ценность проекта. От нее зависят наши репутации. Неверные оценки становятся причиной наших страхов и провалов. Оценка – это первый клин, вбиваемый между бизнесменами и разработчиками. Это источник почти всего недоверия, связанного с этими отношениями.
В 1978 году я был ведущим программистом для 32-килобайтной встроенной программы Z-80, написанной на языке ассемблера. Программа «прошивалась» на 32 перепрограммируемых микросхемах, которые вставлялись в три платы (до 12 микросхем на каждой).
У нас в эксплуатации были сотни устройств, установленных на центральных телефонных станциях по всем Соединенным Штатам. Каждый раз, когда мы исправляли ошибку или добавляли новую функцию, нам приходилось отправлять техников к каждому устройству для замены всех 32 микросхем!
Это был настоящий кошмар. Микросхемы и платы были непрочными, контакты на микросхемах гнулись и ломались. Нечаянные изгибы плат могли повредить места пайки. Риск ошибок и поломок был огромен, а затраты для компании – слишком высоки.
Мой начальник Кен Файндер пришел ко мне и попросил что-нибудь сделать. Нам был нужен способ замены микросхем, который бы не требовал замены всех остальных микросхем. Если вы читали мои книги или слушали мои лекции, то вы знаете, что я много говорю о возможности независимого развертывания. Именно тогда я впервые усвоил этот урок.
Проблема заключалась в том, что программа представляла собой единый скомпонованный исполняемый файл. Добавление новой строки кода приводило к изменению адресов всех последующих строк. Так как в каждой микросхеме попросту хранился один килобайт адресного пространства, то изменялось содержимое практически всех микросхем.
Решение было довольно простым. Микросхемы нужно было изолировать друг от друга. Содержимое каждой микросхемы преобразовывалось в независимую единицу компиляции, которая могла записываться независимо от всех остальных.
Я определил размеры всех функций в приложении и написал простую программу, которая «укладывала» их, словно фрагменты головоломки, на микросхемах, оставляя 100 байт свободного пространства для расширения. В начале каждой микросхемы размещалась таблица указателей на все функции данной микросхемы. Во время загрузки эти указатели перемещались в память. Весь код системы был изменен таким образом, чтобы функции никогда не вызывались напрямую – только через векторы, хранящиеся в памяти.
Да, вы правильно поняли: микросхемы превратились в аналоги объектов с v-таблицами, а функции вызывались полиморфно. Именно так я узнал некоторые принципы объектно-ориентированного программирования задолго до того, как познакомился с понятием «объект».
Выгода от такого решения была огромной. Мы получили возможность не только ограничиться установкой отдельных микросхем, но и вносить исправления «на месте», перенаправляя векторы в оперативной памяти. Это значительно упростило отладку и «горячие» исправления.
Но я отклоняюсь от темы. Когда Кен пришел ко мне с предложением решить проблему, он предложил подумать об указателях на функции. Я потратил день-два на формальное изложение идеи, а затем представил подробный план. Он спросил, сколько времени займет работа; я сказал, что около месяца.
Мне понадобилось три месяца.
Я напивался только дважды в жизни и только один раз напился основательно. Это произошло на праздновании Рождества в Teradyne в 1978 году. Мне тогда было 26 лет.
Праздник проводился в офисе Teradyne, который в основном состоял из открытого лабораторного пространства. Все пришли рано, а сильная снежная буря не позволила оркестру и фирме выездного обслуживания добраться до нас. К счастью, выпивки было достаточно. Я не очень хорошо помню этот вечер, а то, что помню, предпочел бы забыть. И все же я не могу не поделиться одним важным моментом.
Я сидел по-турецки на полу с Кеном (мой начальник – ему тогда было 29 лет, и он был трезв), сетуя на то, сколько времени у меня заняла векторизация. Алкоголь освободил мои скрытые страхи и неуверенность по поводу исходной оценки. Надеюсь, я не клал голову ему на плечо – впрочем, такие подробности не очень четко отложились у меня в памяти.
Помню, я спросил, не сердится ли он на меня и не считает ли, что работа заняла слишком много времени. И как бы смутно я ни помнил тот вечер, его ответ четко отложился у меня в памяти на последующие десятилетия. Он сказал: «Да, я думаю, что прошло много времени, но я вижу, что ты прилежно трудишься, а работа не стоит на месте. И нам это действительно нужно. Так что я не сержусь».
Что такое «оценка»?
Проблема в том, что оценки можно рассматривать по-разному. Бизнес любит рассматривать их как обязательства. Разработчики предпочитают рассматривать оценки как предположения. Между этими точками зрения существуют принципиальные различия.
Обязательства
Обязательство – нечто такое, что вы обязаны сделать. Если вы обязуетесь сделать что-то к определенной дате, то к этой дате «что-то» должно быть готово. Если для этого вам придется работать по 12 часов в сутки и по выходным, пропускать семейные праздники – так тому и быть. Вы приняли обязательство и его необходимо соблюдать.
Профессионалы не принимают на себя обязательств, если только они не уверены в возможности их выполнения. Да, все просто. Если вам предлагают принять на себя обязательство, а вы не уверены, что сможете справиться с задачей, – ваша честь требует отказаться. Если вам предлагают принять обязательство, которое, на ваш взгляд, выполнимо, но потребует сверхурочных, работы по выходным и пропущенного семейного отдыха – решайте сами; но если уж пообещали – выполняйте.
Обязательствам присуща определенность. Другие люди принимают ваши обязательства и используют их как базу для построения собственных планов. Нарушение обязательств обернется огромным ущербом для вашей репутации; это проявление непорядочности, лишь немногим лучшее открытой лжи.
