На днях программный проект, на который я потратил год, был «положен на полку». Год усилий был бесцеремонно спущен в канализацию программного обеспечения. Несколько коллег спросили меня: «Как вы к этому относитесь?» Вы поверите, облегчение?
Это не фальшивая бравада и не глупый солнечный оптимизм. Я не наивен. Я знаю, что эта неудача причинит мне боль. В современных корпорациях виновные в неудачах стороны, обычно менеджмент, редко берут на себя вину. Вина, как грунтовые воды, опускается до самых нижних уровней. В кругах разработчиков программного обеспечения он объединяется с программистами, выполняющими реальную работу. Никогда не говорится, но всегда подразумевается, что программные сбои — это исключительно результат ошибок программистов. Если бы мы только работали усерднее и работали месяцами по шестьдесят или восемьдесят часов в неделю; если бы мы были мастерами кодирования более высокого уровня, которые могли бы создавать тысячи безошибочных строк кода в час, как полностью вымышленные гении программного обеспечения на телевидении, все могло бы быть иначе.
Предаваться гипотезам — все равно что спорить с молодыми земными креационистами о расстоянии галактик.
«Учитывая абсолютное постоянство скорости света, как можно увидеть галактику Андромеды, которая, как мы знаем, находится на расстоянии более двух миллионов световых лет, во Вселенной возрастом шесть тысяч лет?»
Неизбежным ответом на этот вопрос об убийстве молодой Земли всегда будет что-то вроде того, что Бог мог создать вселенную со светом в пути. Бог мог бы также заставить пукать запах Шанель № 5, но, к сожалению, [1] этого не сделал. Точно так же Бог не смог укомплектовать корпорации легионами программистов уровня Спока, готовых и желающих удовлетворить любое au courant представление, которое устанавливает управление мозгами в управленческих черепах. Галактика Андромеды находится в миллионах световых лет от нас, мы живем не на шеститысячелетней Земле, и программное обеспечение не создается по волшебству. Проекты работают или барахтаются по вполне реальным причинам. Меня не удивило прекращение этого проекта. Я был удивлен, что потребовалось так много времени, чтобы отказаться от чего-то, что никогда не сработает, как ожидалось.
Работа с плохим унаследованным кодом всегда напоминает мне сцену из фильма «Империя наносит ответный удар», когда Хан Соло спасает Люка в ледяном мире, разрезая его упавшего таунтауна световым мечом. Когда кишки таунтауна вываливаются наружу, Соло говорит: «Я думал, что они плохо пахнут снаружи». Устаревший код может выглядеть довольно плохо снаружи, просто подождите, пока вы не разберетесь с ним. Только тогда вы выпускаете всю мерзкую сильную вонь.
Этот проект, назовем его Проект вонючего таунтауна, был попыткой реформировать унаследованную систему. Нашей задачей было добавить в старую систему, написанную на языке программирования, напоминающем иероглифы, крупные новые возможности. Я знаю и регулярно использую полдюжины языков программирования. За редким исключением, языки программирования больше похожи, чем различны. Со времен Тьюринга мы знали, что все языки программирования по сути одинаковы. Вы всегда можете реализовать один язык на другом; все системы программирования используют эту фундаментальную эквивалентность. Теоретически возможно скомпилировать SQL в JavaScript и запустить полученный код на восьмибитном интерпретаторе, написанном на древнем пакетном режиме. Я просто не рекомендую вам запускать проект программного обеспечения, совместимого с SOX, для создания такого безумия. Это удваивается, если только один программист в вашей организации знает древний Bat! Проект Вонючий таунтаун не был таким безумным, но были явные признаки того, что мы приступаем к тому, что было точно описано как Марш смерти.
Избегание «маршей смерти» или поиск способов переложить вину за них — важный навык выживания для молодых корпоративных программистов. Не будет преувеличением сказать, что многие современные программы построены на наивности молодежи. Когда вы впервые учитесь программировать, вас соблазняет его непреодолимая рациональность. Это мир, основанный на логике, математике и реальных инженерных ограничениях. Вещи работают и не работают по совсем не ерундовым причинам! Нет никаких бессмысленных споров с идеологическими метросексуальными головорезами о «привилегиях» или «гендере». Программам плевать на цвет кожи программиста или на то, была ли их мать оскорбительной лесбиянкой. После нескольких лет вдыхания паров разреженной логики молодые программисты часто совершают гигантскую и катастрофическую ошибку, заключающуюся в том, что общество голых обезьян, в котором они живут, также работает на принципах отсутствия чуши. Именно на этом деликатном этапе вы можете сильно подтолкнуть молодого программиста. Есть старая поговорка, что продавцы любят деньги, а инженеры любят работу, поэтому в большинстве компаний продавцы получают деньги, а инженеры — работу. Как сказал бы великий мудрец Гомер Симпсон: «Это смешно, потому что это правда!»
Марши смерти разрушают наивность. Лучшее понимание отвратительного мира, в котором мы живем, всегда приносит пользу голой обезьяне, но за это приходится платить; ваша карьера пострадает, и вы пострадаете: просветление пропорционально боли! Школа жестоких ударов — это реальная вещь, и в отличие от той партийной школы, которую вы пропивали, никто не заканчивает ее живым. Я настоятельно рекомендую каждому работающему программисту пройти несколько маршей смерти. Перефразируя Толстого, «все успешные программные проекты похожи друг на друга; каждый неудачный проект терпит неудачу по-своему!» Вы можете рассмотреть то, что следует за моим скромным вкладом в обширную, полностью игнорируемую литературу по программному обеспечению «Марши смерти».
Запах кода №1: большое количество плохо написанного устаревшего кода без тестов, который делает что-то важное.
Рефакторинг — это слово, над которым я люблю издеваться, но в литературе по рефакторингу встречается удивительно точный термин: запах кода. Запахи кода — это именно то, что вы ожидаете. Что-то в коде воняет. Кодовая база Вонючего таунтауна не просто воняла, она воняла, как мочегонное собачье дерьмо на холерической блевотине. Это было хорошо известно всей компании. Мой общий совет молодым программистам, которые почуяли запах гниющего кода, прост: бегите, бегите, прерывайте работу, убирайтесь из Dodge! Не проливайте свои драгоценные телесные жидкости, убирая чужой беспорядок.
Когда меня наняли, несколько опытных программистов-иероглифов задали мне острый вопрос: «Как вы справляетесь с гигантскими вонючими кучами устаревшего ду-ду?» Может быть, это было не совсем так, но намерение было ясно. Они говорили мне, что имеют дело с кипящей массой полусырого дерьмового кода, который каким-то образом, несмотря на многочисленные недостатки, был полезен для организации и не мог быть избавлен от заслуженного страдания.
Я честно ответил. Системы, которые просуществовали много лет, несмотря на свои проблемы и недостатки, удовлетворяют потребность. Вы должны уважать это. Я все еще верю в это! Каждый день я запускаю старые командные оболочки, которые выглядят почти так же, как и тридцать лет назад. Почему я использую эти старые инструменты? Это просто; они очень эффективно выполняют ключевые задачи. Я постоянно пробую новые инструменты. Я провел несколько месяцев, играя с PowerShell. Это очень гладкая современная оболочка, но у нее есть одна большая проблема. Загрузка занимает гораздо больше времени, чем древние оболочки DOS или Bash. Когда я хочу выполнить несколько простых команд, меня очень раздражают несколько дополнительных секунд, необходимых для запуска и запуска PowerShell. Зачем мне ждать, если мне не нужны замечательные новые функции PowerShell? Система Вонючих Таунтаунов также отвечала потребностям пользователей, и точно так же, как меня ужасает неуклюжая непродуманная непоследовательность старых оболочек, пользователи Вонючих Таунтаунов зажали нос и использовали хорошие части того, что в целом было плохой системой.
Запах кода №2: нет полностью автоматического набора тестов с контролем версий.
Существует история, возможно, апокрифическая, на заре программирования, которая звучит примерно так: у молодого программиста поколения ENIAC был плохой день. Он пытался запустить какую-то программу и расстраивался из-за перемонтажа. Наш молодой программист переживал один из первых сеансов отладки, когда в дело вступили настоящие насекомые. В момент острого озарения наш молодой программист понял, что отныне большую часть своего времени он будет тратить на поиск ошибок в неисправных программах. Сказка становится темной здесь. Я часто задавался вопросом, что случилось с молодым программистом. Была ли у него счастливая жизнь, или он, как Сизиф, толкал эту чертову программу в гору только для того, чтобы она снова и снова рушилась, пока руководство не крикнуло: Стоп!
Отладка — необходимое зло. Если вы программируете — вы отлаживаете. Избавиться от отладки невозможно, но, по крайней мере, к ней можно подходить разумно, и на сегодняшний день единственным успешным методом контроля программных ошибок является полностью автоматический постоянно расширяющийся набор тестов с контролем версий. Системы с такими наборами на самом деле улучшаются со временем. Системы без таких пакетов всегда вырождаются и убивают нескольких наивных программистов по мере их упадка. В системе Stinking Tauntaun не было набора автоматических тестов. В системе Stinking Tauntaun не хватало неавтоматического набора тестов. У Вонючего Таунтауна никогда не было полезных тестовых случаев! Тестировать The Stinking Tauntaun было труднее, чем разбираться с его кодом. Первому тестировщику снились кошмары о Вонючем Таунтауне.
Моя иллюстрация качества с течением времени без использования Power Point для системы, в которой отсутствует полностью автоматический и постоянно расширяющийся набор тестов с контролем версий. Системы без хорошо спроектированных испытательных стендов почти без исключения полнейшая чушь. Если кто-то не платит вам огромные деньги, лучше начать рассылать резюме, когда вас просят починить такие системы. Вы можете испортить себе здоровье, размешивая свое вкусное мороженое в дерьме, но конечная смесь почти наверняка будет на вкус больше дерьмом, чем мороженым.
Это люди 21 века! Во времена ENIAC вы могли не заметить отсутствующие наборы автоматических тестов. В настоящее время отсутствие наборов автоматических тестов является изобличающим обвинением организации, которая терпит такие гнусные преступления против программирования человечества!
Запах кода №3: только один программист может работать с устаревшим кодом.
Когда меня наняли, в штате было несколько программистов-иероглифов. Ни один программист не был обременен ошибками, накопленными за предыдущие десятилетия. Мы могли бы разделить и справиться с болью. В это счастливое время наша работа была ориентирована на поддержку. Мы не беремся за большие проекты. Затем последовал неизбежный приступ корпоративной реорганизации, за которым последовали увольнения и поток перебежчиков, бегущих от нового порядка. В итоге остался только один иероглифический программист: moi! Большинство программистов присоединились бы к исходу и не брали на себя грехи других отцов, но, как я уже говорил, я программная шлюха и горжусь этим. Тем не менее, даже софтверные шлюхи не должны закончить так, как может быть только один, Горец. Насколько я помню, большинство этих дуэлей на шпагах кончались довольно плохо.
Запах кода № 4: массивные подпрограммы с обширной областью действия имен.
Поскольку ядовитые пары уже перекрыли нам подачу воздуха, мы должны были остановиться на месте, но мы продолжали сражаться, потому что вонючая система таунтаун сделала что-то важное, а альтернативы были недоступны. Корпорация осознала это и начала ряд параллельных проектов по изучению Нового Вонючего Таутона. Мне не посчастливилось работать ни в одном из параллельных проектов. Пришлось забраться в стойло и перелопатить таунтаунский навоз.
Когда мы начали работу над Вонючим таунтауном, мы не были в полной неосведомленности. Мы осознали ненадежное ограничение ресурсов программиста, связанное с иероглифами, и попытались разделить работу на блоки, которые облегчили ее. Мы решили реализовать часть новых возможностей на другом языке программирования и вызывать новый модуль из старой системы. Была надежда, что это разделит работу и, возможно, создаст что-то, что можно будет использовать за пределами Вонючей Системы Таунтаун. Эта часть проекта прошла достаточно хорошо. Новый модуль представляет собой совершенно новый код и работает очень хорошо. К сожалению, это была небольшая часть больших усилий по внедрению новых функций в систему Вонючего таунтауна.
Вонючий код Таунтауна авторитетен в своем монолитном безумии. Иероглифический язык программирования известен своим лаконичным стилем кодирования, однако основная процедура в системе Вонючего Таунтауна состоит почти из 10 000 строк! Я никогда не видел иероглифических программ такой длины. Я видел сопоставимые программы всего несколько раз за свою боевую карьеру. Будучи студентом лета, я восхищался программой на Фортране, состоящей из 20 000 строк и одной подпрограммой. Сначала я подумал, что это результат какого-то кросс-компилятора, но нет, какой-то сумасшедший правительственный беспилотник (я работал в правительственном агентстве в западной Канаде) закодировал его вручную — на чертовых перфокартах! Такая ошеломляющая некомпетентность встречается редко: большинство программистов мимолетно знакомятся с модульным проектированием и знают достаточно, чтобы пересматривать вещи, когда код выходит из-под контроля. У всех нас разные пороги для суждения вышло из-под контроля, для меня это любая рутина, которая длиннее шестидесяти строк, включая чертовы комментарии.
Упражнение на 10 000 строк — это монументальный красный флаг, но длина The Stinking Tautaun не была самой большой проблемой. Есть такая штука, которую программисты называют «область охвата». Область действия отмечает границы имени. Он устанавливает ограничения на то, где имена имеют значение или значение. В идеале область действия имени ограничена до наименьшей возможной степени. Вам действительно не нужны глобальные имена! Вы абсолютно не хотите, чтобы глобальные имена, такие как «X», «i» или «T», скакали в вашем коде! Большинство загадочных имен в Системе Вонючих Таунтаунов имели широкое распространение. Огромные области действия затрудняют безопасное внесение локальных изменений. Это делает рискованным, опасным и трудоемким изменение кода. Большие области также увеличивают нагрузку на тестировщиков. Если крошечные изменения имеют далеко идущие последствия, вам придется повторно тестировать большие части системы каждый раз, когда вы ее настраиваете. Все это отнимает время и истощает чистые телесные жидкости ИТ-персонала.
Запах кода № 5: основные предположения о том, что возможно, быстро оказываются неверными.
Было темно. Робкие души побежали бы, но мы шли дальше. Наша наивная надежда основывалась на теории, что мы можем изменить несколько точек касания в кодовой базе Вонючего таунтауна, а затем выйти из Dodge до того, как темный лес кладжей сомкнется. Моя первая оценка того, сколько процедур мне придется коснуться, было около двадцати. . За два месяца работы над проектом я уже переделал более сотни, и конца этому не видно. Небольшое ортогональное изменение, которое мы надеялись внести, оказалось невозможным, потому что Система Вонючих Таунтаунов не могла разумно делать одну вещь в одном месте. Он делал то же самое во многих местах. Вы не можете внести небольшое изменение и добиться разумного потока во всей системе. Я работал над изоляцией и модульным беспорядком, но я должен был просто махнуть рукой и провести дни в LinkedIn в поисках другой работы.
Запах кода № 6: культура разработки, пропитанная контрпродуктивными церемониями.
Помимо всех этих визжащих сирен, кричащих «стоп», были и другие препятствия. Я работаю в среде, насыщенной SOX. Читатели моего блога знают, что я считаю SOX одной из самых больших куч идиотизма DC, когда-либо навязываемых американским компаниям. Как и многие «государственные решения», SOX не осушил задуманное болото, но навсегда обременил нас бессмысленной тратой времени церемониями и совершенно глупыми уровнями микроменеджмента. Действительно ли управление Active Directory является заботой гребаного правительства? Каким-то образом он стал одним! Одним из моих любимых следствий SOX является религиозное упорядочивание сред разработки и таинства поощрения изменений кода. Во время долгого мучительного проекта Stinking Tauntaun многие релизы сводились к тому, что я вносил изменения в один файл! Отправка новой версии для тестирования должна была быть простой копией файла.
Конечно, это не могло быть так просто. Многочисленные «билеты» должны были быть утверждены. Другой отдел ИТ, который был еще более загружен и страдал от более высоких уровней оборота, чем наш, был привлечен для выполнения одной тривиальной копии файла. Во многих случаях в результате всей этой бессмысленной траты времени было сгенерировано больше байтов, чем я изменил в одном файле. Конечно, все это требовало времени, и сколько бы я ни искал категорию бесполезной траты времени в нашей онлайн-системе учета рабочего времени, я не смог ее найти. Есть мантра менеджмента: вы можете улучшить только то, что измеряете. Забавно, что компании никогда не оценивают ерунду.
Оглядываясь назад, мы должны были отказаться от The Stinking Tauntaun System или радикально переписать ее. Это иронично, но что-то вроде этого произойдет. Если бы я был молод, я бы ожесточился, но я заработал на этом проекте. Когда я консультировал, я всегда высматривал Вонючих Таунтаунов: они были чертовски золотыми приисками для тех из нас, кто пристрастился к бодрящему гнилостному дыму гниющего кода.
[1] Если вы относитесь к тому типу людей, у которых завязываются трусики из-за пола гипотетических высших существ, пожалуйста, уходите.
Первоначально опубликовано на сайте bakerjd99.wordpress.com 12 апреля 2015 г.
