Благие намерения прокладывают дорогу в ад для разработчиков

Поскольку боксерские груши не покрываются нашим бюджетом на оборудование для домашнего офиса в период блокировки, я решил вместо этого потрудиться над некоторыми письменными размышлениями о том, что стало частым и бюрократическим раздражителем. Обзоры кода.

Исследователь Ким Висенте поделилась ставшей популярной историей о кодифицированных правилах, ограничивающих ценность экспертизы. На некоторых атомных электростанциях, где вы ожидаете повышения квалификации, требуется, чтобы операторы практиковались на симуляторе, чтобы получить сертификат. Часто в таких сложных системах существует множество курсов безопасной практики. И еще больше способов, в которых что-то может пойти не так. Достаточно того, что распознать их можно только через опытных профессионалов. Книги правил становятся несостоятельными. Разочарованные тем, что они измеряются этими узкими правилами, а не реализмом, и предупрежденные за это, некоторые операторы решили следовать им буквально. Курс, за который они получили смехотворную в то время критику за «злонамеренное соблюдение процедур».¹

Я понимаю, что проверка кода является эффективной стратегией предотвращения. Но их поведение определяет, что они предотвращают: ошибки или производительность. Давайте также признаем, что они защищают сложные системы другого типа от своих атомарных собратьев. Тот, где проще свести к минимуму вред от кодифицированных правил: все, что кодифицировано для мира битов, может, в конце концов, быть автоматизировано вне поля зрения, вне разума. Правила — это игровая площадка разработчиков. Как пошутил Эрик Вайнштейн в недавнем подкасте Джо Рогана: «Почему вундеркинды и аспи увлекаются БДСМ? Кто-то сказал: «множество правил».² Проблемы возникают, когда правила не могут быть кодифицированы; когда система позволяет смешивать хорошо мотивированную педантичность с мелкими и непродуктивными проявлениями доминирования.

Педантичность и путаница сами по себе доставляют мелкие неприятности. Мое дело здесь в том, что обзоры действительно начинают приносить в жертву продуктивность, когда они становятся Советом Безопасности ООН в миниатюре. Когда особенности одного рецензента имеют право вето на набор изменений. Будет справедливо признать, что мой код не идеален. Но идеально по какой метрике?

Подобно правилам, идеалы часто кажутся вне контекста. Если мы невнимательны, системы, которые внедряют или реализуют правила и идеалы, проникают в контекст через черный ход. То, как мы решаем — например, используя GitHub — упростить обзоры, оказывает существенное влияние на метрики, которые применяются на практике. Программисты, перефразируя Шелли, стали непризнанными законодателями современного мира.

Внимание к деталям, которое является благом для программистов, когда они исправляют ошибки, может парализовать, когда оно близоруко забывает контекст. Хотя практические требования к проверкам кода будут различаться между большими и малыми проектами, любая проверка может включать в себя несколько основных проверок:

  • Проверка логического потока
  • Соблюдение проектных/корпоративных стандартов кодирования
  • Функциональная правильность

Я перечислил их в порядке возрастания потенциальной непрозрачности. Проверка логического потока требует минимальных знаний предметной области: если рецензент знает язык, он может проверить синтаксис и семантику. На другом конце спектра непрозрачности сложность проверки функциональной правильности проявляется в двух аспектах. Ручной — там, где может быть важен опыт, — и автоматизированный, который, хотя и экономит труд, может нести скрытые расходы.

Соблюдение — паршивая овца в семействе непрозрачности, ее руно потемнело из-за неразумного применения, возможно, неписаных «правил». В отличие от логических и функциональных проверок, которые служат прокси для использования в реальном мире, субъективность рецензентов, подкрепленная правом вето, может быть рецептом контрпродуктивного авторитаризма. Вам может понадобиться не только инженерная экспертиза, но и оттачивание психоаналитических навыков, чтобы своевременно получить одобрение.

В небольших проектах эти факторы могут стать небольшим раздражителем. Но именно с масштабом такие сложности начинают сжиматься. Со сборками и автоматическими тестами чем дольше они выполняются, тем больше у рецензентов возможностей запросить изменения — разумные или нет, кодифицированные стандарты или нет, — что, в свою очередь, может вызвать больше проверок и запросов на изменение до тошноты. Не обращая внимания на контекст, мы завышаем альтернативные издержки для разработчиков и вводим задержки, которые каскадом распространяются по цепочке поставок. В худшем — перетасовываем виртуальные шезлонги на цифровой «Титаник».

Держитесь подальше от виртуальных айсбергов

Хорошо, так что ссылка на Титаник может быть чрезмерной. В защиту статус-кво можно сказать, что легче изменить нашу реакцию на вещи, чем изменить других. Что мое недовольство отзывами — это моя проблема. Тем не менее, как бы верно это ни звучало, оно также игнорирует переменную: мое взаимодействие с другими опосредовано системами с аффордансами, которые определяют наше поведение. Стремление к осознанности не мешает нам одновременно улучшать дизайн системы.

Итак, что в первую очередь приводит нас к виртуальным айсбергам? Рассмотрим еще раз общие для всех проектов проверки: на логичность, соответствие и функциональность. Я подозреваю, что эти проверки служат естественной воронкой, а комплаенс — зоной Златовласки. При дефиците опыта — ситуация более вероятна в более крупных проектах со специализацией — функциональные проверки могут быть нецелесообразными для конкретного рецензента. Логические ошибки также часто выявляются до проверки, что может привести к тому, что рецензенту, который не так хорошо знаком с данной областью кодовой базы, нечего будет проверять кроме соответствия. Возможно, проверки на соответствие также имеют привлекательную силу — медовая ловушка для педантов.

В целом, я достаточно уважаю своих коллег, чтобы признать, что они, как и я, разделяют идеал, предложенный Хэлом Абельсоном: «Программы должны быть написаны для того, чтобы люди могли их читать, и лишь изредка для того, чтобы машины выполняли их». этот человеческий фактор, который делает право вето таким экстремальным инструментом принуждения. влияние требования их.

И здесь система может помочь. Если автор кода оспаривает ценность обзора, система апелляции — возможно, с согласованным тайм-аутом — может призвать других «владельцев кода»⁶ демократически отстаивать право вето. Другим подходом может быть политика, требующая от рецензента предоставления явных предложений по изменению, применение которых может автоматически привести к одобрению этого рецензента. Вместо проверки кода просто привлекать к ответственности авторов кода, эти подходы также требуют большей ответственности от проверяющих. Последний подход также устраняет некоторую субъективность и причину постоянного отказа от изменений.

В конечном счете, проверки кода недостаточно хороши, чтобы измерять код сам по себе. Нам нужно спроектировать их так, чтобы они были лучшими прокси для дикого мира, в который выпускается этот код, как внутри в головах разработчиков, так и снаружи с кремнием и данными клиентов. Это означает разработку систем с использованием опыта как рецензентов, и авторов. И там, где этот опыт ограничен, возможно, найти менее дорогостоящие места для его развития.

¹ Висенте, Ким (1999). Анализ когнитивной работы, стр. xv
² Подкаст Джо Рогана #1453 — Эрик Вайнштейн
³ https://www.goodreads.com/quotes/9168-programs-must -быть-написанным-только-только-только-для-чтения
⁴ Научные рецензии часто обнаруживают аналогичную проблему, пример которой описан в Эпизоде ​​портала #019: Предсказание и ДИСК< br /> ⁵ Хорошо, когда стиль приходит раньше, чем позже; таким образом, более поздние исправления стиля не скрывают того, что изначально мотивировало определенные строки в базе кода.
⁶ https://help.github.com/en/github/creating-cloning-and-archiving-repositories/ о владельцах кодов