Руководства по кодированию

      Суть Тотального Управления Качеством (TQM) - в сознательности. Осознание того, что мы делаем, когда выполняем повторяющиеся процедуры или подобную работу, позволяет нам ухватить те редкие моменты озарения, когда мы видим способы сделать работу более эффективно и сообщаем о них нашим коллегам, изменяя наш процесс. Это означает, что определение процесса может содержать скучные вещи, необходимые для поддержания взаимодействия (связи) между группами, но стилистические или определяемые подходом моменты не должны быть великой ценностью, которую стоит передавать в таких документах. Идея этого аспекта процесса -- не задавать каждую маленькую операцию, а сохранить знание. Это дает нам критерий, хотя и субъективный, определяющий, какие пункты стоит включать в документ. Например, микроспецификации упорядочивания заголовочных файлов не подходят для включения в стандарт кодирования, поскольку помимо прочего, ими почти всегда пренебрегают на каждой реальной платформе на этапе компиляции кода. Однако, метод использования макросов условной компиляции вокруг всего содержимого включаемого модуля для предотвращения многократного включения является маленьким сокровищем, которое нужно поместить там, где каждый его может увидеть и будет ему следовать.
      На автозаводах сборочные цеха подвергаются постоянному совершенствованию, поскольку люди, делающие непродуктивную работу, осознают, что они непродуктивны, и исправляют это. Оригинальная параллель с программной инженерией должна заключаться в том, что руководства по кодированию должны совершенствовать процесс. Одно из наиболее дорогостоящих последствий барьера между картостроителями и паковщиками состоит в том, что паковщики, паникуя из-за "кризиса программного обеспечения", отстаивают утверждение, что "процесс" -- это необъяснимый и мистический источник всего хорошего и, будучи таковым, он правильный. В некоторых организациях процесс становится механизмом принудительных попыток внедрить тупой роботизм паковщиков на всех рабочих местах, поскольку он кажется правильным состоянием ума на пути к магическому успеху.
      Чтобы осознать масштабы проблемы, рассмотрим эволюцию языков программирования и моделей, средств разработки, инструментов CASE и так далее за последние тридцать лет. На самом деле нет никакого сравнения между концами этого интервала ни в чем, за исключением стандартов программирования. Некоторые аспекты структурного программирования, которые начал обсуждать Дейкстра (Djikstra), были превращены в ритуализированную догму, а затем эта догма перекочевывала из стандарта в стандарт и дошла до наших дней. Действительно, главная черта большинства стандартов кодирования, страстно пропагандируемых их сторонниками, состоит в том, что в них скопированы вещи, взятые откуда-то еще. Это история о том, как продать хлам запуганным и невежественным. Говоря, что угадал нечто, кому-то еще -- хороший способ без всяких оснований добавить к чему-нибудь фальшивый источник. Стандарты кодирования создаются менеджерами для программистов, а не открываются во время кодирования и не передаются наверх. Такой оживленной и квалифицированной (если примитивно) дискуссии, которая вела к первоначальным стандартам кодирования, которые были великолепны для своего времени, с тех пор не повторялось. Как только был принят первый стандарт и были замечены улучшения, мир бизнеса паковщиков ухватился за них, обратил их в камень и объявил, что установлена "соответствующая процедура". Споры о стиле скатились до религиозных войн, не были повернуты лицом к потребностям развивающейся индустрии и потому были глупыми. Между тем, существование этой "соответствующей процедуры" неявно отвергало существование новых стилистических явлений, возникавших с появлением новых языков и моделей, которые нуждались в квалифицированных обсуждениях, каких же интенсивных, как обсуждения, развернувшиеся вокруг структурного программирования, для того, чтобы научиться использовать эти новые языки.
      Программист, использующий среду разработки типа ParcWorks Smalltalk получает столько же преимуществ от ханжеских разглагольствований о неиспользовании goto и помещении данных, на которые никто не смотрит, в стандартных строках комментариев в начале файла, как и авиадиспетчер, прочитавший во Второзаконии о каре за секс с верблюдами.

Кто украл мою мышку?

      Этот раздел посвящен сложности. Мы начнем с мысленного эксперимента, касающегося воображаемой марсианской экологии.
      На Марсе (как все знают) есть скалы. Там есть также два вида живых существ. Это марсиане, которые едят мышей, и, что кстати для марсиан, есть мыши. Мыши скрываются среди скал и грызут их.
      Мало что происходит на Марсе. В основном марсиане проводят свое время сидя в пустыне и выслеживая снующих между скал мышей. Поскольку скалы на Марсе повсюду, куда ни кинь взгляд, по всем направлениям, то марсианам нужно уметь хорошо видеть сразу во всех направлениях. Поэтому у марсиан характерные направленные в разные стороны четыре больших глаза, каждый на стебельке.
      Мало что происходит на Марсе, поэтому эволюция марсиан полностью направлена на совершенствование обнаружения мышей. Сзади каждого огромного глаза расположена огромная мозговая корка, которая может обнаружить мышь за несколько миль в любое время суток (при любой освещенности). Большая часть мозга марсианина состоит из зрительной коры и эти четыре подмозга имеют многочисленные связи, чтобы компенсировать неблагоприятные условия освещенности. Марсиане интенсивно обрабатывают изображение ландшафта в полуавтономных подмозгах, поэтому им на самом деле не требуется "внимание", как людям -- вместо этого они сосредоточены на переключении входов между своими "вниманиями".
      Обнаружив мышку, марсианин должен подкрасться к ней. Это означает, что нужно преодолеть скалы. Это требует Разума. Вскоре после обретения Разума марсиане изобрели Великую Литературу. Ее выбивали на больших скалах с помощью каменных обломков. Она подчиняется правилам марсианской грамматики и использует Северный голос для эмоций, Южный голос для действия, Восточный голос для речи и Западный голос для обстоятельств. Мало что происходит на Марсе, поэтому наиболее близкий марсианский эквивалент нашего "Преступления и наказания" называется "Кто украл мою мышь?":
       Emotion Action Speech CircumstanceGrumpy Sneak Horrid Martian Cold, Gloomy Determined Bash Die! Die! Die! Old Martian's Cave Ashamed Steal Vole Dead Martian
       Эмоция Действие Речь ОбстоятельстваСердитый Подкрадывается Ужасный марсианин Холодно, мрачно Непреклонно Бить Умри! Умри! Умри! Пещера старого марсианина Стыдно Украсть мышь Мертвый марсианин
      Захватывающе, не правда ли? Этот неожиданный пробел в Восточном голосе, сменяющий Южный голос -- непроизнесенное проклятие, очень реальное само по себе! Я утверждаю, что это помогает получить правильную структуру мозга...
      В чем смысл этой Странной Истории? Хорошо, представим, что марсианский программист мог бы создать теорию взаимодействующих последовательных процессов Ч.Хоара (C.A.R. Hoare's Communicating Sequential Processes -- CSP). Их мозг (легко избегаем рода -- у марсиан 16 полов и для организации брачной ночи требуется десять лет) уже создан таким (hardwired), чтобы позволить им почувствовать сложные отношения между независимыми действиями, поэтому процессы, которые Хоар располагает линейно, используя последовательности символических преобразований и таким образом делая их понятными человеку, становятся непонятными марсианам.
      Попытки разработать систему управления совместного человеко-марсианского космического корабля, в которой множество взаимодействующих последовательных процессов управляют двигателями, фотонными пушками и т.п. столкнутся с проблемами, напоминающими коммуникационный барьер между картостроителями и паковщиками, даже несмотря на то, что доказыватели теорем с помощью CSP могли бы предложить автоматические трансляторы на основе своих идей.
      Дело в том, что сложность находится в глазу зрителя. Нам не требуется инопланетная философия, чтобы заметить различие между тем, как отдельные личности оценивают сложность, -- это полностью сфера мысленных карт. Когда мы открываем структуру, которая позволяет нам понять, что происходит, то мы можем понять истоки гораздо большего числа явлений с одного взгляда. Поразмышляйте над любой сложной ситуацией, в которой вам нужно разобраться, будь это палуба яхты или сцена любительского драматического театра. Когда вы впервые посмотрите на нее, она будет выглядеть как хаос из тросов, блоков, ящиков, трапов, железяк совершенно непонятного назначения. Когда вы получите картину, выяснив назначение каждого предмета, палуба, сцена и все что угодно кажется уже просторнее, аккуратнее, чем когда вы первый раз посмотрели на нее. Но там ничего не изменилось, изменились вы.
      Ни один здравомыслящий шкипер или режиссер не стал бы пытаться действовать таким образом, чтобы любой самый зеленый новичок смог с первого раза понять, что происходит. Даже плавание по бухте или поднятие занавеса требуют некоторого навыка.
      В программной индустрии метод рычага, коммуникационный барьер картостроитель/паковщик и языковая специализация маскируют этот момент. Метод рычага говорит, что преимущество, которое мы получаем перемещая числа вместо кирпичей, означает, что мы можем приложить усилия, чтобы простые числа, описывающие кирпичи, были представлены в доступной всем форме. Индустриальный и коммерческий контекст многих операций программирования подразумевает, что раз специалист организовал свою информацию, то ее сложность управляется сама собой, а, исходя из этого, прогресс кирпичей гарантирован. Все это так, и это вполне правильный подход к информации о кирпичах. Но когда мы подменяем информацией кирпичи, то получаем проблему. Мы не можем абстрагировать от большого безобразного кирпича к информационной "1". Конечно, мы можем абстрагировать, но каждый раз, когда мы делаем это, мы теряем важную информацию, которая позднее может сыграть с нами злую шутку. Мы не можем просто сказать, что специалист упорядочил свои данные, поскольку работа в наше время состоит в организации огромного потока данных, который сваливается на нас. Нам больше не нужны навыки оператора автопогрузчика, но нам необходимы новые навыки. И мы не можем управляться с представлением сложности просто требуя, чтобы представление было простым. Коммуникационный барьер между картостроителями и паковщиками делает обсуждение ситуации с такой неадекватной аналогией между информацией и кирпичами еще более сложным просто потому, что почти в каждом шаге логики кирпичей есть информационный аргумент, но вместо 1% управления и 99% полезной нагрузки, проблема менеджмента скорее в 90% управления и 10% полезной нагрузки. Это соотношение -- то, что отличает все эвристики управления кирпичами, и это то отношение, которое, к сожалению, задают паковщики. Они думают, что они распознали ситуацию, щеголяют пакетом знаний, аккуратным и документирующим все, и на этом останавливаются. Идея о том, что, может быть, они изобрели многоступенчатую ракету, которой никогда не оторваться от земли, поскольку двигатели слишком неэффективны, и понадобится гораздо больше менеджмента менеджмента, чтобы компенсировать недостаток искусности, очень тяжела для осознания теми, кто не обучен рисовать мысленные модели и видеть в них структуру. Наконец, существование специализированных языков (профессиональных жаргонов) способствует появлению такой возможности. Если бы все было так же просто, как SQL. Нужно помнить:
      Это заняло 30 летОбласть применимости очень ограниченаЭто требует большой вычислительной мощности процессоров
      SQL не прост. Это в точности то, что мы описали -- управление известными вещами с помощью идиом -- каждый понимает ужасы внешних связей таблиц (outer joins).
      И вновь здесь возникает "ход конем". Что лучше: разработать действительно сложный код, послать его, и затем получить короткий ответ, или послать простой код и получить длинное сообщение. Каковы предположения о квалификации и опыте администратора базы данных? Насколько мы можем расширить их понимание в документации, чтобы мы могли использовать более "сложные" идиомы? Огромный switch()- обычно довольно ужасный способ управлять процессом, если только вы не пишете цикл обработки событий GUI, где мы все его предполагаем и ищем его.
      Нет абсолютной меры "сложности". Это должно родиться в мозгу, в обсуждениях сложности алгоритмов и стиля кодирования и того, что выдают средства анализа сложности после графического представления системы, которое может оказаться очень полезным. Сложность в этих картинках (после того как систему упростили до необходимой достаточности) не есть Плохая Вещь -- это существо лежащей перед вами проблемы. Нам не следует пытаться избегать внутренней (присущей) сложности проблем. Это бесполезная стратегия, которая уводит нас от достижения абстрактного понимания, которое позволит нам упорядочить сложность.

Рецензии и анонсы

      Фундаментальный элемент взгляда паковщика на работу -- управление посредством угрозы. Выполни действие так и так, и не иначе. Чтобы сделать угрозу эффективной, исполнение правил должно контролироваться (полицейскими методами), поэтому мы должны следить, гарантируя этим следование правилу. Тогда ленивые и ненадежные работники будут знать, что их уволят, и будут выполнять действия как предписано из страха наказания. Действительно, важное соображение, из-за которого отвергают стиль работы картостроителя, поддерживается заблуждением, что работа картостроителя может быть специфицирована по шагам (microspecified), а единственная причина, почему это необходимо делать -- то, что правила должны быть специфицированы. Только для записанных на бумаге правил можно выявить их нарушение программистами, и возможность этого выявления поставлена в центре всей модели!
      Конечно, есть еще одна цель -- в том, что рецензия также может выявить небольшие оплошности, которые необходимо поправить перед тем, как работу можно будет отдать заказчику. Это напоминает осмотр "Роллс-Ройса" и стирание пятнышек на капоте мягкой тряпочкой -- но это не превратит какую-нибудь колымагу в "Роллс-Ройс".
      В программной индустрии у нас есть процессы, которые уделяют значительное внимание рецензиям, что само по себе либо тривиальная либо полицейская акция, но ничего не делают, чтобы обратить основное внимание команды и опыт группы на нахождение наилучшего способа сделать работу. Это приводит к рецензиям, на которые отдельные работники или подгруппы тратят свои лучшие силы, но которые оказываются откровенно плохими, особенно если за дело берутся неопытные программисты. Время на выполнение этой работы потрачено, поэтому если для решения задач, с которыми способна справиться сама операционная система (бесплатно), были выбраны какие-нибудь древние библиотеки процессов уровня приложений со сложными правилами инициализации, то на перепроектирование просто не остается времени. Членам группы рецензирования приходится сговариваться не замечать изъяны логики и сконцентрировать свои усилия на ритуальных предметах, касающихся просто стиля. Это ничего не дает для качества.
      Решение, конечно, картостроительское. Мы должны принять, что программисты любят делать настоящую хорошую работу, если им дать шанс, и нужно инвестировать в помощь им, а не в их запугивание. Вместо того, чтобы тратить полдня на рецензирование, когда уже поздно что-то менять, следует проводить это время над анонсом (preview), в котором мы могли бы оценить условия и согласовать общее направление до того как сделана работа. В такой ситуации от работы по рецензированию можно просто отказаться, поскольку если уж получился "Роллс-Ройс", то финальное рецензирование нужно лишь для проверки, не осталось ли пятнышек на капоте.

Инспектирование кода и пошаговые проверки

      Инспектирование кода составляет важную часть процесса многих организаций. Изначальная причина, почему его делают -- удовлетворить здравый смысл. TQM требует: "Если вы сделали работу, посмотрите на то, что вы сделали, и убедитесь, что с этим пунктом все в порядке". Но в инспектировании кода появляется нечто забавное, часто искажающее его назначение. Это вызвано тем, что инспектирование кода похоже на Рождество. Это старое действо, которое старше структур, с которыми оно имеет дело. И, как и Рождество, содержит множество мишуры, происходящей из Старой Религии.
      Когда-то давно программы приходилось писать на специальных листах, которые передавались операторам для набивки перфокарт. Результат распечатывался для проверки, затем перфокарты загружались в компьютер. И все это имело смысл из-за необычайно высокой стоимости работы компилятора. И это была не просто стоимость работы и амортизации -- время цикла одного прогона могло составлять неделю. Поэтому было мудрым решением выработать привычку посидеть и проверить кодовые листы друг друга перед тем, как отправить их на перфорирование.
      Сейчас у нас на столе мощные редакторы и процессоры, поэтому изначальные мотивы больше неприменимы, но нам по-прежнему нужно продолжать проверять наш код, чтобы можно было идентифицировать логические ошибки до того, как они уронят систему. Здесь заключается причина помрачения сознания. У некоторых организаций так же помрачено сознание, как у того IT менеджера, который недавно сказал, что работники должны выполнять инспектирование кода по листингу перед тем как его компилировать. Чтобы избежать неприятностей, у нас есть стадия проектирования для получения правильной большой картины и компилятор для обнаружения синтаксических ошибок. Ручной просмотр кода в поиске синтаксических ошибок не дает ничего полезного, а является очень дорогим и ненадежным методом поиска синтаксических ошибок, несмотря на то, что так делали всегда! Баланс изменился, и нам нужно свериться с нашими мысленными картами, как и во всем, что нам приходится делать в этой насыщенной информацией игре.
      Хотя в большинстве организаций людям разрешают компилировать и тестировать код перед инспектированием, веточка омелы все еще висит над очагом. Почему это полдюжины людей вдруг вскочили, бросили свои навороченные браузеры классов, средства абстрактного моделирования, среды разработки с графическим интерфейсом и удалились с пачкой листинга на целый день, организация за организацией, день за днем? Пусть это делается на компьютере, чтобы можно было, например, запустить поиск и получить ответ на вопрос, всегда ли эта величина положительна.
      Инспектирование кода очень дорогое удовольствие, и нам следует избавиться от него. Очень хороший способ сделать это (при наличии символического графического отладчика) -- разбить работу на две части. Сначала отдельный программист, который хорошо знаком со структурой и назначением кода, использует отладчик в пошаговом режиме и тестирует программу. Это может казаться очень трудоемким и малопродуктивным, но эффект потрясающий. Программа сама естественным образом отслеживает путь, который проверяет разработчик, а глаза разработчика фокусируются на каждом отдельном шаге логики. И не придется трассировать ошибочную часть, чтобы ее увидеть, поскольку ум работает гораздо быстрее пальца на кнопке мыши, и быстро выявляет такие вещи, если устремлен в правильном направлении. Может оказаться полезным распечатать листинг, разбить его горизонтальными линиями по функциям и блокам кода, и рисовать вертикальные линии на полях листинга по мере проверки. При этом используется знание разработчика, помогает машина, и для этого требуется один человек, хотя выявляется множество проблем. А полная групповая инспекция кода может затем сфокусироваться на вещах, которые может привнести свежая точка зрения, например обнаружение неявных предположений, которые могут оказаться неверными, по мере того, как разработчик объясняет логику.
      Инспектирование кода, организованное таким образом и совмещенное с индивидуальной пошаговой проверкой имеет свое назначение, и маловероятно, что оно деградирует до маразма религиозных войн по поводу стиля комментариев, на которые сейчас тратят свое время многие высокооплачиваемые программисты.

Стандарты кодирования и руководства по стилю

      Стандарты кодирования и руководства по стилю уже несколько раз появлялись в этой работе, и уже сказанное могло сильно отличаться от общепринятых убеждений. Будет полезно изучить эти различия и понять в точности, о чем мы говорим.
      Мы показали, что индустрия программирования часто пытается расположиться между двумя очень различными взглядами на мир. Паковщиков выдрессировали структурировать свои доводы и рассуждения вокруг идентификации ситуации с заученными ответами, а затем исполнения того действия, которое та предписывает. Их поведение в мире основано на том, чтобы делать правильные вещи. На работе им говорят, что делать. Картостроители стремятся получить общее понимание ситуации, применяя известные паттерны там, где они применимы, и создавая новые там, где их нет. Картостроители, если им задана цель, в своих действиях руководствуются своими картами. На работе они понимают проблему и находят оптимальное решение. Мы также увидели, что картостроительный подход -- это то, как создается новое программное обеспечение, и его нельзя создать паковкой.
      Поэтому стандарты кодирования отражают частично мотивацию картостроителей, частично мотивацию паковщиков, и в результате цели создателей стандартов перепутываются. Проявляется коммуникационный барьер между картостроителями и паковщиками, поэтому картостроители рвут на себе волосы, поскольку паковщики растирают сложность, пока она не станет невидимой на каждой отдельной странице, цитируя Пакет Знаний 47684 (Ясность Это Хорошо) и в то же самое время вытирая ясность из работы.
      Если мы примем, что картостроение и TQM -- основы хорошего программирования, и что суть картостроения и TQM - понимание и управление (контроль), мы можем посмотреть на цели и увидеть, что мы можем сделать для улучшения стандартов кодирования и руководств по стилю.
      Сначала о ясности. Есть идея, что использование синтаксического богатства языка -- это Плохая Вещь, поскольку это "сложно". Ни когда составной синтаксис образует идиому. Ни даже когда эта идиома вводится и обсуждается в документации. И вообще не нужна ни при каких условиях. Когда Ньютон писал "Принципы" (Newton's Principia), то написал их словами, хотя мог использовать алгебраические символы, поскольку был сооткрывателем флюксий, или исчислений. В наше время мы решили, что в математике лучше иметь дело с алгебраической нотацией даже при описании. Сейчас то, что потребовало бы нескольких страниц текста, в алгебраической нотации займет всего страницу, и хотя при этом скорость чтения страницы снижается, общее время чтения стопки текста больше, поскольку в стопке текста гораздо труднее проследить мысль. Итак, следует ли нашим программам быть более похожими на прозу по концентрации сложности на страницу или на выражение, либо им следует быть ближе к математике? Мы предполагаем, что если человек -- новичок в языке, то лучше, если он сможет отчетливо увидеть всю структуру и тратить на каждую страницу несколько минут, чем читать каждую идиотскую строчку и не понимать, для чего это написано! Как часто нам приходится видеть напряженных людей, сидящих перед стопкой кода, не имеющих понятия, с чего начать, и думающих, что это их вина.
      Второй момент -- соглашения. Прежде чем принять соглашение, убедитесь в том, что оно даст больше, чем будет стоить. Мы приводили ранее пример, в котором если кто-то не знает назначение переменной, то он ничего не получит от знания ее типа [тут идет речь о венгерской записи - С.К.]. Но это не просто вклад в перегрузку мозга соглашениями, которые, как предполагается, "хорошие" программисты должны хранить в виде пакетов знаний, что само по себе проблема. Дело еще и в том, что наличие слишком большого количества соглашений делает код некрасивым и даже уродливым. Если стремиться к красоте минимального кода, то этого сложнее достичь постоянно натыкаясь на обвешанных мусором уродцев типа gzw_upSaDaisies. Никогда не делайте того, что подавляет стремление команды создать великий продукт. Было место, где думали, что соглашения -- Хорошая Вещь. Несколько людей были назначены Создавать Правила, и они делали это должным образом. Один из них объявил, что длина имен переменных должна ограничиваться 31 символом. Очень разумно -- многие компиляторы могут различать имена не длиннее указанного. Другой объявил, что переменные, описанные в подсистеме, должны начинаться с трехбуквенного альфа-кода подсистемы.