ги, затем до точки, где вычитаются расходы на медицинское страхование, затем до точки, где идут отчисления в пенсионный фонд… Ну вы поняли.
Программисты и клиенты могут довольно просто применить такую метафору к подготовке зарплатного чека. Она дала им словарный запас, чтобы говорить о программах.
Но метафоры часто заводят не туда.
Например, в конце 1980-х я работал над проектом, в котором измерялось качество передачи данных в сетях T1. Мы загрузили данные счетчиков ошибок с конечных точек каждой линии связи. Эти данные были объединены в слои по полчаса. Мы рассматривали эти слои как ломтики чего-то сырого, из чего можно приготовить еду. Когда мы нарезаем хлеб ломтями, где мы жарим ломтики? В тостере! И тут мы метафорически стали описывать хлеб.
У нас были ломтики, батоны, сухари и так далее.
У программистов такой словарный запас работал неплохо. Мы отлично понимали друг друга, когда разговаривали о сырых и приготовленных ломтиках, батонах и так далее. С другой стороны, менеджеры и клиенты, которые слышали наши разговоры, крутили пальцем у виска и выходили из комнаты. Им казалось, что мы несем чушь.
А есть пример еще хуже. В начале 1970-х я работал над системой разделения времени. Она перемещала приложения в память, которая была ограничена, и выгружала их из нее. За время, за которое приложение находилось в памяти, она загружала в буфер текст и отправляла его на медленный телетайп. Когда буфер заполнялся, приложение уходило в спящий режим и выгружалось из памяти на диск, в то время как буфер постепенно очищался. Мы называли такие буферы мусоровозами, которые ездили между мусорными баками и свалкой.
Мы думали, что это гениально. Мы не могли сдержать смешков, когда разговаривали о метафорическом мусоре. По сути, мы говорили, что наши клиенты — торговцы мусором. Такая метафора была удобна для общения между нами, но она выражала неуважение к тем, кто нам платил. Они никогда не узнали об этой метафоре.
Эти примеры показывают как преимущества, так и недостатки метафоры. Метафора формирует словарь, который позволяет нам успешно общаться внутри команды. С другой стороны, некоторые метафоры глупо звучат и являются оскорбительными по отношению к клиенту.
Предметно-ориентированное проектирование
В своей прогрессивной книге Domain-Driven Design[43] Эрик Эванс решил нашу проблему с метафорами, и наконец мы избавились от чувства стыда. В этой книге он ввел понятие повсеместного языка — как раз так стоило назвать метод, который получил название «метафора». Команде была нужна именно модель предметной области, которую описывают теми словами, с которыми согласны все.
Под «всеми» я имею в виду всех: программистов, QA-специалистов, менеджеров, клиентов, пользователей и так далее.
В 1970-х Том Демарко назвал такие модели «словарями данных»[44]. Они были простыми представлениями данных, которыми манипулирует приложение, и процессов, которые манипулировали этими данными. Эванс значительно развил этот простой замысел в дисциплину моделирования предметной области. И Демарко, и Эванс использовали эти модели как транспортные средства для общения с партнерами.
Как простой пример: я недавно написал видеоигру Space War. Элементы данных носили названия «корабль», «клингон», «ромуланин», «выстрел», «удар», «взрыв», «база», «транспорт» и прочее. Я внимательно относился к тому, чтобы изолировать эти понятия в их собственных модулях и использовать эти названия исключительно в приложении. Это был мой «повсеместный язык».
Такой язык используется во всех частях проекта. На нем говорят клиенты. Разработчики говорят на нем. И QA-специалисты. Специалисты по DevOps тоже на нем говорят. Даже клиенты берут на вооружение те части, которые будут им полезны. Повсеместный язык применяется в бизнес-моделях, требованиях, архитектуре и приемочном тестировании. Он прочной нитью последовательно объединяет составляющие проекта на каждом этапе его жизненного цикла[45].
40-часовая рабочая неделя
Не быстрый побеждает в беге…
Претерпевший же до конца спасется.
На седьмой день Бог решил взять отдых. А позже Бог велел в этот день отдыхать всем. Видимо, даже Богу нужен метод «40-часовая рабочая неделя», или равномерная работа.
В начале 1970-х, когда я был восемнадцатилетним, меня и моих школьных приятелей взяли работать джуниор-программистами для работы над крайне важным проектом. Менеджеры установили сроки. Сроки были жесткими. Требовалось выкладываться по полной. Мы были незаменимыми винтиками в сложном механизме компании. Мы были важны!
Хорошо, когда тебе восемнадцать, не правда ли?
Мы, молодые и горячие, только окончившие школу, работали как волы. Мы работали долгими часами месяц за месяцем. В среднем мы работали по 60 часов в неделю. Были недели, когда мы работали даже по 80 часов. Десятки раз мы работали по ночам.
И мы гордились тем, что работали сверхурочно. Вот мы-то были настоящими программистами. Мы посвятили себя проекту. Нас ценили. Потому что мы были единственной силой, которая могла спасти такой важный проект. Мы. Были. Программистами.
А потом мы сгорели, причем жестко. Так жестко, что ушли всем скопом. Мы вылетели оттуда, оставив компании еле работающую систему разделения времени, при этом в компании не было толковых программистов, которые могли бы ее сопровождать. Вот так им!
Хорошо, когда тебе восемнадцать и ты в ярости, да?
Не беспокойтесь, компания выкарабкалась. Оказалось, что там все же были толковые программисты помимо нас. Ребята, которые спокойно себе работали 40 часов в неделю. Ребята, которых мы представляли безразличными к работе и ленивыми, над которыми мы во время сумасшедших ночных марафонов презрительно смеялись, пока они не видели. Эти ребята без лишней суеты взяли систему в свои руки, обеспечив вполне годное сопровождение. Не побоюсь сказать, они были рады избавиться от кучки шумных и надоедливых сопляков.
Работа сверхурочно
Как думаете, я усвоил урок из того, что вам только что рассказал? Нет, конечно. В течение последующих 20 лет я точно так же горел на работе ради своих работодателей. Я продолжал прельщаться байками о том, что проект чрезвычайно важен. Я, конечно, не сходил с ума, работая сутками, как в 18 лет. В среднем я работал уже где-то по 50 часов в неделю. Ночные посиделки стали происходить реже, но никуда не исчезли.
Когда я вырос, то понял, что самые худшие технические ошибки я совершал в ночные часы, когда из меня ключом била маниакальная энергия. Я осознал, что эти ошибки были огромными помехами, которые мне постоянно приходилось исправлять в часы, когда я по-настоящему был работоспособен.
Затем случилось кое-что, что заставило меня задуматься. Я и мой будущий деловой партнер Джим Ньюкирк занимались ночным бдением. Где-то около двух часов ночи мы пытались выяснить, как переместить единицу данных из низкоуровневой части нашей программы в другую часть, которая находилась намного выше в цепочке выполнения. Решение возвращать эти данные в стек не подходило.
Мы создали систему транспортировки внутри нашего продукта по типу почты. Мы применяли ее для пересылки информации между процессами. В наших жилах тек кофеин, мы были на пределе возможностей. Внезапно пришло осознание, что можно было сделать так, чтобы низкоуровневая часть процесса отсылала единицу данных самой себе, где высокоуровневая часть могла бы ее считать.
Даже сейчас, спустя более трех десятилетий, каждый раз, когда мы с Джимом хотим описать чье-то неудачное решение, мы говорим: «Да уж. Они просто отослали это самим себе».
Я не буду грузить вас скучными подробностями, почему это решение было дурацким. Достаточно сказать, что на него ушло намного больше усилий, чем мы, как казалось, сберегли. И, конечно же, это решение привело к слишком глубоким и труднообратимым изменениям, поэтому мы потеряли много времени[46].
Марафон
И в то время я понял, что проект по разработке программного обеспечения — это марафон, а не спринт или серия спринтов. Чтобы победить, надо рассчитывать силы. Если вы выскакиваете из стартовых блоков и летите на полной скорости, у вас закончатся силы прежде, чем вы пересечете финишную черту.
Таким образом, вы должны работать в темпе, который можно поддерживать в течение длительного времени. Должна быть 40-часовая рабочая неделя. Если пытаться бежать в более быстром темпе, чем вы можете поддерживать, все равно придется замедляться и отдыхать до пересечения финишной черты. Средняя скорость будет ниже, чем при умеренном темпе. Когда финишная черта близко, еще остается немного сил на то, чтобы совершить рывок. Но нет необходимости делать его раньше времени.
Менеджеры могут просить вас поторопиться. Ни в коем случае не поддавайтесь. Ваша работа — грамотно распоряжаться своими ресурсами, чтобы выстоять до конца.
Самоотдача
Работа сверхурочно — плохой способ выразить самоотверженность перед работодателем. Это лишь показывает то, что вы плохо умеете планировать, что соглашаетесь со сроками, на которые не нужно соглашаться, что даете обещания, но не в состоянии их сдержать, что вы управляемый чернорабочий, а не профессионал.
Это не означает, что работать сверхурочно неправильно или что никогда не нужно этого делать. Есть смягчающие обстоятельства, при которых работа сверхурочно — единственный выход. Но это должно быть исключением. И вы должны прекрасно понимать, что работа сверхурочно может в итоге привести к большим временным затратам.
Та ночная посиделка с Джимом несколько десятилетий назад была не последней. Она была предпоследней. Последний раз я сидел всю ночь, когда меня вынудили обстоятельства.