(Окончание этих двух топиков — переводов эссе «Unmaintainable Code». В оставшихся главах автор часто обращается к уже описанным методам, удваивая и утраивая каждый из них; изложение сильно сокращено за счет исключения таких мест.)
Если вы оставите баг-другой в своей программе, то человеку, который придет после вас, будет чем развлечься.
Никогда не тестируйте код, обрабатывающий любые отказы железа или операционной системы. Все равно этот код никогда не выполняется и только задерживает процесс разработки. Кроме того, как вы можете проверить то, как ваш код обрабатывает сбои дисков, ошибки чтения файлов, сбои операционной системы и другие особые ситуации? Ведь для этого вам понадобится либо крайне ненадежный компьютер, либо «песочница», которая будет его симулировать. Современное железо никогда не отказывает, и какой дурак будет писать код только для тестирования? Нет, это неинтересно. Если пользователи жалуются, сваливайте вину на ОС или железо — им-то откуда знать, так ли это?
Если что-то работает недостаточно быстро, посоветуйте клиенту купить более мощный компьютер. Сами подумайте, если вы займетесь нагрузочным тестированием, вы можете найти узкое место, придется менять алгоритмы, а то и полностью переделывать проект. Кому оно надо? Кроме того, проблемы с производительностью, возникающие у заказчика, обеспечат вам бесплатную поездку в какую-нибудь экзотическую местность — главное, держите загранпаспорт наготове.
(Э нет, главное, чтобы проблема возникла на Лазурном берегу или на Бали, а не на Крайнем Севере или еще в какой Тьмутаракани — прим.пер.)
Не тестируйте покрытие кода или покрытие путей. Автоматизированное тестирование — для слабаков. Выясните, какие функции отвечают за 90% обращений к вашему коду и напишите тесты для них. Скорее всего, таким образом вы тестируете около 60% вашего кода и экономите себе остальные 40% усилий. Это позволит вам уложиться в сроки в конце проекта. К тому времени, как кто-нибудь заметит, что какая-то дополнительная возможность не работает, вас уже и след простынет.
Слишком многие программисты боятся — боятся босса, клиентов, почты, потерять работу или попасть в суд. Этот страх парализует и уменьшает производительность. Исследования показали, что исключение фазы тестирования позволяет выполнять работу с опережением сроков, что исключает большую часть этих страхов. Поэтому храбрые программисты тестированием не занимаются: их цель — написать код, а с исправлением ошибок справятся справочная система и отдел техподдержки.
Если человек полностью уверен в своих способностях программиста, тестирование не нужно. Задумайтесь: очевидно, что тестирование не решает никаких технических проблем, нет, это вопрос эмоциональной уверенности. Значительно эффективнее исключить тестирование и отправить программистов на курсы поднятия самооценки: ведь тестировать придется каждое изменение в коде в течение многих лет, а курсы достаточно пройти только один раз. Выгода очевидна и потрясающа.
Отладочный режим позволяет выполнять в нем команды, не входящие в основной режим. Перенесите часть обязательной логики в отладочный режим, убрав ее из основного. При должной изобретательности основной вариант кода не будет даже компилироваться.
(Кстати, актуально — на эти грабли я наступила совсем недавно, хоть и нечаянно — прим.пер.)
(Это эссе начинало писаться в 1996 году, поэтому точные советы явно неактуальны, да и последовать им смогут очень немногие; приведена только основная идея — прим.пер.)
Общая тенденция развития языков программирования — повышение надежности и качества защиты от дурака. Поэтому не стоит использовать современные языки: настаивайте на самом старом языке, который вам только позволят (но на котором вы все-таки сможете программировать).
Ад — это другие люди
В этом эссе то и дело встречаются намеки на то, как взбесить вашего сопровождающего, как пресечь попытки вашего босса добиться от вас сопровождаемого кода и даже как начать всеобщий холивар на тему форматирования кода в репозитории. Вот еще несколько советов:
Если ваш босс считает, что его двадцатилетний опыт работы на FORTRAN отлично подходит для современного программирования, строго следуйте его рекомендациям. В результате босс будет доверять вам, ваша карьера только выиграет от этого, а сами вы узнаете много новых и интересных способов обфускации кода.
Не отвечайте на телефонные звонки. Забывайте о письмах после присвоения им номера отслеживания.
Никогда не проявляйте бдительность в вопросах типа Y2K. Если вы заметили нечто, что подкрадется в определенный момент и уничтожит жизнь в западном полушарии, не обсуждайте это ни с кем до наступления часа Ч (момент события минус 4 года), когда пора будет паниковать и наживаться на панике.
(Похоже на сценарий фильма-катастрофы, правда? — прим.пер.)
Не говорите друзьям, знакомым или другим компетентным людям, не публикуйте ничего, что могло бы натолкнуть на мысль. Пошлите одну записку (обычного приоритета) вышестоящему руководству, чтобы прикрыть свою задницу. Можно добавить это письмо как приложение к другому, важному и срочному. После этого можете увольняться спокойно, зная, что в час Ч вас будут умолять вернуться с астрономической прибавкой к зарплате.
Выберите авторов, которые слишком заняты написанием книг, чтобы самим программировать. Прочешите местные книжные магазины в поисках книг с массой диаграмм и без примеров кода. Просмотрите полученные книги и выучите несколько сотен непонятных, но красивых слов, которые можно использовать, чтобы запугать ничтожеств, следующих за вами. Ваш код должен впечатлять. Обширный непонятный словарный запас наводит людей на мысль о том, что вы очень умный, а ваши алгоритмы — очень сложны. Для полноты картины избегайте банальных аналогий в объяснениях.
Гении не слишком волнуются о том, поспевают ли их усредненные коллеги за ними (а некоторые еще и испытывают садистское удовольствие от их страданий), и таким образом нередко ведут свой проект к гибели. Ведите себя так же, даже если вы не гений. Хотя бы говорите всем, что будь они достаточно умны, у них не возникало бы проблем с пониманием вашего гениального кода.
(Противоречит предыдущему пункту, зато гораздо проще — прим.пер.)
Одного программиста на С раздражала политика компании, требующей использования именованных констант вместо встроенных численных констант. Он следовал букве, но не духу закона, определив сто констант:
(Все относительно. В компонентах на TopCoder есть аналогичное правило, и его буква важнее духа — да они были бы счастливы заполучить этого программиста — прим.пер.)
Кстати, несложное переопределение константы
надолго развлечет людей, пытающихся сопровождать ваш код.
Вам всегда хотелось писать код системного уровня? Это ваш шанс! Игнорируйте стандартные библиотеки и пишите свои собственные эквиваленты. В вашем резюме это будет смотреться просто потрясающе!
Напишите, например, свой собственный распределитель памяти, который будет просто выделять память в «куче». Вместо написания сложных процедур освобождения занятой памяти требуйте от пользователей периодических перезагрузок, очищающих динамическую память. Единожды согласившись на такую стратегию, они не избавятся от нее никогда.
(Опять же, в 1996 году непривычными языками были совсем не те, что сейчас, поэтому глава сокращена до основной идеи с парой примеров — прим.пер.)
Выберите язык, непривычный для сопровождающего, и по максимуму используйте особенности его синтаксиса. В SQL используйте одно- и двухбуквенные синонимы таблиц или названия других таблиц, не относящихся к делу; по возможности используйте разные варианты синтаксиса — просто чтобы держать окружающих в
тонусе. В Visual Basic объявляйте тип переменной символом: вместо
напишите
Скомпилируйте код в исполняемый файл; убедитесь, что он работает; внесите ряд небольших произвольных изменений в исходный код, но не перекомпилируйте его; оставьте измененный код в репозитории. Когда программа перестанет работать после следующего изменения, будет казаться, что ошибка именно в нем.
Если ваши сотрудники любят пользоваться построчным отладчиком, размещайте по нескольку операторов на одной строке — например, конструкция if-then-else может поместиться на строку целиком.
Часто вносите изменения в ваш код, и требуйте от пользователя регулярных обновлений — вы же не хотите пользоваться неактуальной версией? Не говорите никому, в чем разница между версиями — им незачем знать об ошибках, которые они не заметили сами.
(Странный совет для репозиториев, умеющих сравнивать файлы — прим.пер.)
Не выпускайте версии программ, которые только исправляют ошибки — обязательно добавьте несколько существенных изменений интерфейса, структуры базы данных или формата файлов. Люди, которым действительно мешает эта ошибка, справятся с обновлением, а остальные привыкнут и начнут называть ее не багом, а фичей. Скорее всего, с вас требуют совместимость — хорошо, но обеспечьте ее только в одном направлении. В идеале более старые версии программы должны вообще не узнавать файлы, созданные в более новых версиях (да, некоторые текстовые процессоры приводят отличный пример).
Окно «О программе» может содержать название программы, список авторов, копирайт, несколько мегабайт кода, генерирующего анимированную картинку — но не версию программы, дату последнего обновления или сайт, откуда его можно скачать. Тогда все смогут использовать разные версии, сообщать о давно исправленных ошибках и т.д.
После этого вы можете писать
и кто-нибудь обязательно исправит это на
Для разнообразия можно присвоить TRUE и FALSE одинаковые значения.
(Да-да, я помню, #define TRUE (random()>0.5) — прим.пер.)
Если вы пишете на C++, притворитесь, что не знаете о STL, и пишите все операции с массивами и строками вручную — это позволит вам поддерживать ваши навыки обращения с указателями, а заодно пресечет любые попытки изменений кода посторонними. С другой стороны, включайте в проект сторонние библиотеки — это позволит вам включать их и в свое резюме, оставаясь в неведении относительно них.
Если в вашем компиляторе есть ошибка, убедитесь, что ваш код основан на ней. Раз вы пользуетесь этим инструментом, никто другой не должен искать альтернативы.
Если ваш компилятор предупреждает о наличии неиспользуемых переменных, не удаляйте их, а придумайте, как их использовать. Мой любимый метод — i=i.
Лучшая возможность испытать эти примеры на использующейся программе — за неделю до того, как вы увольняетесь и переезжаете на ПМЖ в другую страну. В других случаях следование этим советам может быть опасно для вашего здоровья. Автор и переводчик не несут ответственности за вред, нанесенный народному хозяйству и отдельным лицам в результате использования советов этой статьи.
Тестирование
Если вы оставите баг-другой в своей программе, то человеку, который придет после вас, будет чем развлечься.
1. Не тестируйте обработчики ошибок
Никогда не тестируйте код, обрабатывающий любые отказы железа или операционной системы. Все равно этот код никогда не выполняется и только задерживает процесс разработки. Кроме того, как вы можете проверить то, как ваш код обрабатывает сбои дисков, ошибки чтения файлов, сбои операционной системы и другие особые ситуации? Ведь для этого вам понадобится либо крайне ненадежный компьютер, либо «песочница», которая будет его симулировать. Современное железо никогда не отказывает, и какой дурак будет писать код только для тестирования? Нет, это неинтересно. Если пользователи жалуются, сваливайте вину на ОС или железо — им-то откуда знать, так ли это?
2. Не делайте нагрузочное тестирование
Если что-то работает недостаточно быстро, посоветуйте клиенту купить более мощный компьютер. Сами подумайте, если вы займетесь нагрузочным тестированием, вы можете найти узкое место, придется менять алгоритмы, а то и полностью переделывать проект. Кому оно надо? Кроме того, проблемы с производительностью, возникающие у заказчика, обеспечат вам бесплатную поездку в какую-нибудь экзотическую местность — главное, держите загранпаспорт наготове.
(Э нет, главное, чтобы проблема возникла на Лазурном берегу или на Бали, а не на Крайнем Севере или еще в какой Тьмутаракани — прим.пер.)
3. Не создавайте контрольные примеры
Не тестируйте покрытие кода или покрытие путей. Автоматизированное тестирование — для слабаков. Выясните, какие функции отвечают за 90% обращений к вашему коду и напишите тесты для них. Скорее всего, таким образом вы тестируете около 60% вашего кода и экономите себе остальные 40% усилий. Это позволит вам уложиться в сроки в конце проекта. К тому времени, как кто-нибудь заметит, что какая-то дополнительная возможность не работает, вас уже и след простынет.
4. Тестирование — для трусов!
Слишком многие программисты боятся — боятся босса, клиентов, почты, потерять работу или попасть в суд. Этот страх парализует и уменьшает производительность. Исследования показали, что исключение фазы тестирования позволяет выполнять работу с опережением сроков, что исключает большую часть этих страхов. Поэтому храбрые программисты тестированием не занимаются: их цель — написать код, а с исправлением ошибок справятся справочная система и отдел техподдержки.
Если человек полностью уверен в своих способностях программиста, тестирование не нужно. Задумайтесь: очевидно, что тестирование не решает никаких технических проблем, нет, это вопрос эмоциональной уверенности. Значительно эффективнее исключить тестирование и отправить программистов на курсы поднятия самооценки: ведь тестировать придется каждое изменение в коде в течение многих лет, а курсы достаточно пройти только один раз. Выгода очевидна и потрясающа.
5. Убедитесь, что работает только отладочный режим
Отладочный режим позволяет выполнять в нем команды, не входящие в основной режим. Перенесите часть обязательной логики в отладочный режим, убрав ее из основного. При должной изобретательности основной вариант кода не будет даже компилироваться.
(Кстати, актуально — на эти грабли я наступила совсем недавно, хоть и нечаянно — прим.пер.)
Выбор языка
(Это эссе начинало писаться в 1996 году, поэтому точные советы явно неактуальны, да и последовать им смогут очень немногие; приведена только основная идея — прим.пер.)
Общая тенденция развития языков программирования — повышение надежности и качества защиты от дурака. Поэтому не стоит использовать современные языки: настаивайте на самом старом языке, который вам только позволят (но на котором вы все-таки сможете программировать).
Работа в команде
Ад — это другие люди
В этом эссе то и дело встречаются намеки на то, как взбесить вашего сопровождающего, как пресечь попытки вашего босса добиться от вас сопровождаемого кода и даже как начать всеобщий холивар на тему форматирования кода в репозитории. Вот еще несколько советов:
1. Жираф большой, ему видней
Если ваш босс считает, что его двадцатилетний опыт работы на FORTRAN отлично подходит для современного программирования, строго следуйте его рекомендациям. В результате босс будет доверять вам, ваша карьера только выиграет от этого, а сами вы узнаете много новых и интересных способов обфускации кода.
2. Никакой техподдержки
Не отвечайте на телефонные звонки. Забывайте о письмах после присвоения им номера отслеживания.
3. Держите язык за зубами
Никогда не проявляйте бдительность в вопросах типа Y2K. Если вы заметили нечто, что подкрадется в определенный момент и уничтожит жизнь в западном полушарии, не обсуждайте это ни с кем до наступления часа Ч (момент события минус 4 года), когда пора будет паниковать и наживаться на панике.
(Похоже на сценарий фильма-катастрофы, правда? — прим.пер.)
Не говорите друзьям, знакомым или другим компетентным людям, не публикуйте ничего, что могло бы натолкнуть на мысль. Пошлите одну записку (обычного приоритета) вышестоящему руководству, чтобы прикрыть свою задницу. Можно добавить это письмо как приложение к другому, важному и срочному. После этого можете увольняться спокойно, зная, что в час Ч вас будут умолять вернуться с астрономической прибавкой к зарплате.
4. Клуб «Книга месяца»
Выберите авторов, которые слишком заняты написанием книг, чтобы самим программировать. Прочешите местные книжные магазины в поисках книг с массой диаграмм и без примеров кода. Просмотрите полученные книги и выучите несколько сотен непонятных, но красивых слов, которые можно использовать, чтобы запугать ничтожеств, следующих за вами. Ваш код должен впечатлять. Обширный непонятный словарный запас наводит людей на мысль о том, что вы очень умный, а ваши алгоритмы — очень сложны. Для полноты картины избегайте банальных аналогий в объяснениях.
5. Притворитесь гением
Гении не слишком волнуются о том, поспевают ли их усредненные коллеги за ними (а некоторые еще и испытывают садистское удовольствие от их страданий), и таким образом нередко ведут свой проект к гибели. Ведите себя так же, даже если вы не гений. Хотя бы говорите всем, что будь они достаточно умны, у них не возникало бы проблем с пониманием вашего гениального кода.
6. Притворитесь идиотом
(Противоречит предыдущему пункту, зато гораздо проще — прим.пер.)
Одного программиста на С раздражала политика компании, требующей использования именованных констант вместо встроенных численных констант. Он следовал букве, но не духу закона, определив сто констант:
#define ONE 1
#define TWO 2
#define THREE 3
:(Все относительно. В компонентах на TopCoder есть аналогичное правило, и его буква важнее духа — да они были бы счастливы заполучить этого программиста — прим.пер.)
Кстати, несложное переопределение константы
#define THOUSAND 999надолго развлечет людей, пытающихся сопровождать ваш код.
7. Самокрутки
Вам всегда хотелось писать код системного уровня? Это ваш шанс! Игнорируйте стандартные библиотеки и пишите свои собственные эквиваленты. В вашем резюме это будет смотреться просто потрясающе!
Напишите, например, свой собственный распределитель памяти, который будет просто выделять память в «куче». Вместо написания сложных процедур освобождения занятой памяти требуйте от пользователей периодических перезагрузок, очищающих динамическую память. Единожды согласившись на такую стратегию, они не избавятся от нее никогда.
Приемы для непривычных языков
(Опять же, в 1996 году непривычными языками были совсем не те, что сейчас, поэтому глава сокращена до основной идеи с парой примеров — прим.пер.)
Выберите язык, непривычный для сопровождающего, и по максимуму используйте особенности его синтаксиса. В SQL используйте одно- и двухбуквенные синонимы таблиц или названия других таблиц, не относящихся к делу; по возможности используйте разные варианты синтаксиса — просто чтобы держать окружающих в
тонусе. В Visual Basic объявляйте тип переменной символом: вместо
dim Color_var as string
dim counter as integerнапишите
Dim Color_var$, counter%Разное
1. Не компилируйте
Скомпилируйте код в исполняемый файл; убедитесь, что он работает; внесите ряд небольших произвольных изменений в исходный код, но не перекомпилируйте его; оставьте измененный код в репозитории. Когда программа перестанет работать после следующего изменения, будет казаться, что ошибка именно в нем.
2. Мешайте отладке
Если ваши сотрудники любят пользоваться построчным отладчиком, размещайте по нескольку операторов на одной строке — например, конструкция if-then-else может поместиться на строку целиком.
3. Совершенствуйтесь
Часто вносите изменения в ваш код, и требуйте от пользователя регулярных обновлений — вы же не хотите пользоваться неактуальной версией? Не говорите никому, в чем разница между версиями — им незачем знать об ошибках, которые они не заметили сами.
(Странный совет для репозиториев, умеющих сравнивать файлы — прим.пер.)
Не выпускайте версии программ, которые только исправляют ошибки — обязательно добавьте несколько существенных изменений интерфейса, структуры базы данных или формата файлов. Люди, которым действительно мешает эта ошибка, справятся с обновлением, а остальные привыкнут и начнут называть ее не багом, а фичей. Скорее всего, с вас требуют совместимость — хорошо, но обеспечьте ее только в одном направлении. В идеале более старые версии программы должны вообще не узнавать файлы, созданные в более новых версиях (да, некоторые текстовые процессоры приводят отличный пример).
4. «О программе»
Окно «О программе» может содержать название программы, список авторов, копирайт, несколько мегабайт кода, генерирующего анимированную картинку — но не версию программы, дату последнего обновления или сайт, откуда его можно скачать. Тогда все смогут использовать разные версии, сообщать о давно исправленных ошибках и т.д.
5. Переопределите TRUE и FALSE
#define TRUE 0
#define FALSE 1После этого вы можете писать
if ( var == TRUE )
if ( var != FALSE )и кто-нибудь обязательно исправит это на
if ( var )
if ( !var )Для разнообразия можно присвоить TRUE и FALSE одинаковые значения.
(Да-да, я помню, #define TRUE (random()>0.5) — прим.пер.)
6. Избегайте библиотек
Если вы пишете на C++, притворитесь, что не знаете о STL, и пишите все операции с массивами и строками вручную — это позволит вам поддерживать ваши навыки обращения с указателями, а заодно пресечет любые попытки изменений кода посторонними. С другой стороны, включайте в проект сторонние библиотеки — это позволит вам включать их и в свое резюме, оставаясь в неведении относительно них.
7. Компиляторозависимый код
Если в вашем компиляторе есть ошибка, убедитесь, что ваш код основан на ней. Раз вы пользуетесь этим инструментом, никто другой не должен искать альтернативы.
8. Неиспользуемые переменные
Если ваш компилятор предупреждает о наличии неиспользуемых переменных, не удаляйте их, а придумайте, как их использовать. Мой любимый метод — i=i.
Эпилог переводчика
Лучшая возможность испытать эти примеры на использующейся программе — за неделю до того, как вы увольняетесь и переезжаете на ПМЖ в другую страну. В других случаях следование этим советам может быть опасно для вашего здоровья. Автор и переводчик не несут ответственности за вред, нанесенный народному хозяйству и отдельным лицам в результате использования советов этой статьи.
