Alan Carter - The Programmers Stone (Программистский камень)

• Название: The Programmers Stone (Программистский камень)
• Автор: Alan Carter
• Жанр: Прочая околокомпьтерная литература

Попытка разобраться и понять, как программировать эффективно. С точки зрения авторов, проблема создания эффективных программ скрыта в способе мышления человека при решении задач. Людям свойственны две стратегии мышления — «паковка» (packing) и «отображение» (mapping). Стать хорошим программистом можно лишь освоив «отображение».

© Википедия

---

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

Мы ничего не делаем ради этого.

Программная инженерия — распределенное программирование

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

Мы распределяем программирование по тем же причинам, по которым распределяем любой вид обработки: пригодность (availability), параллелизм и специализация.

Такой взгляд приносит понимание. Мы должны аккуратно выделить различия между задачами. Иногда мы можем получать преимущества от выполнения двух задач одним человеком, когда нас не должно волновать, что они объединены. Например, во многих организациях принята практика разделения идентификации требований и выбора архитектуры, но когда они переходят на технологию моделирования объектов в стиле Буча, то внимают совету и объединяют эти задачи. Когда мы разделяем навыки разработки и тестирования, мы можем извлечь из этого дополнительные преимущества, контролируя взаимодействие между стадиями таким образом, что мышлению инженера-тестера не угрожает мышление проектировщика. Был менеджер проекта, скорее всего паковщик. Он не имел ясного понимания того, что он делал и почему, а отсутствие какой-нибудь позитивной модели своей работы привело его к мысли, что ключевая цель состоит в предотвращении какого бы то ни было взаимодействия. Тестеры не должны были знать, как установить (создать) условия для компонентов, которые они должны были тестировать, а проектировщикам не дозволялось об этом говорить. Яростные споры продолжались днями. Это реально произошло тогда, когда мы потеряли ощущение большой картины.

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

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

Что такое программирование?

Чтобы понять программную инженерию, мы должны понять программиста. Давайте позволим программисту определять требования (идентичные требованиям пользователя) и исследуем сценарий, который заканчивается созданием наипростейшей возможной программы.

Ада сидит в комнате.

Вечером в комнате становится темно.

Ада включает свет.

Это фундаментальное действие программирования. Есть проблемная область (комната), которая динамична (становится темной). В динамике проблемной области есть порядок (темно будет до утра), который можно анализировать. Есть система, которая может функционировать в проблемной области (лампочка), и у этой системы есть семантика (состояние выключателя).

Есть желание (в комнате должно быть светло), и есть понимание (что воздействие на выключатель удовлетворит желание).

Динамические предметные области, системы и семантика детально где-то обсуждаются. Но здесь мы концентрируемся на лучшем осознании, что есть желание и что есть понимание.

Здесь стоит отметить, что мы подразумеваем под словом «программист». Робот, пишущий все ту же RPG 3 для распечатки счетов, все еще не делает никакого реального программирования вообще, но менеджер проекта, используя Excel для получения интуитивного понимания того, когда бюджет сократится и в чем главные причины, несомненно занимается реальным программированием.

Программирование — игра картостроителя

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

Здесь стоит обратить внимание на философский аспект. Для того, чтобы произошло взаимодействие, я должен ссылаться на то, что уже есть в твоей голове. Один из способов, чтобы вещь попала в твою голову, — попасть туда в виде образа чего-то из внешнего мира, а другой — быть частью твоего собственного опыта. Если часть твоего опыта уникальна (например, ассоциация между дымом трубки и вкусом рождественского пудинга, из-за визитов к родным), мы не можем говорить об этом без первоначального определения терминов. Даже после этого у меня нет опыта такой ассоциации, только представление о такой ассоциации. Но если часть твоего опыта разделяется всеми людьми (наша реакция на крик птенца альбатроса [6]), мы можем говорить об ее «объективности», как если бы реакцию на птенца можно было получить с самим птенцом, чтобы взвесить и измерить.

Необходимость ограничится на работе «объективным» языком аргументируют тем, что это ограничение исходит из структуры организации работы [7]. Это просто глупо. Как работают журналисты, архитекторы (гражданского строительства) или даже судьи? Это область, где менеджеры вынуждены использовать свое понимание для уменьшения риска из-за ошибок.

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

Чтобы достичь чего-либо в программировании, мы должны быть вольны обсуждать и улучшать субъективные факторы, а объективные метрики оставлять для отчетов об ошибках.

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

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

Здесь есть паттерн, который соотносит программирование с любым другим требующим творчества занятием (искусством). У нас есть три явления: Проблема, Семантика и Желание (заглавные буквы напоминают о сущностях Платона). Проблема и Семантика не очень интересны для искусственного интеллекта (ИИ) или изучения сознания человека, а Желание — это вообще что-то странное. Эти три сущности выделены или соединены вместе из-за трех видов деятельности программиста. Взгляд заключается в изучении внутренних свойств Проблемы. Смотреть, чтобы понять значение Желания. Описание выявляет Семантику. Взгляд и Описание зависят от предметной области. Поэт может наблюдать за пассажирами, а эколог образцы популяций. Поэт выстраивает структуру из слов, а эколог описывает тщательно отобранный вид. Взгляд один и тот же у всех. Расскажите любому художнику о хороших моментах своей работы.