Хорошая композиция и бенефиты

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

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

Логики, изучающие систему аксиом, сталкиваются с тем же самым. Они говорят, что система должна быть "необходимой и достаточной". Необходимость и достаточность позволяют ясно видеть природу рассматриваемого явления и гарантируют, что следствия действительно относятся к рассматриваемой области, а не являются произвольными.

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

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

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

Основная сложность на этом этапе - реалистичная оценка продолжительности очистки. Чем больше мусора, тем больший эффект от очистки, но тем больше риск, что не хватит времени. В таких случаях может помочь вопрос "насколько сложна внешняя функциональность?" - если она небольшая, то можно рассчитывать на постепенное улучшение методом последовательных упрощений, даже если не видно всего пути.

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

Третья линия обороны - "комната скунсов", маленький, часто изолированный исследовательский отдел, функционирующий самостоятельно, практически без контроля начальства. Это страшное оружие может использоваться опытными командами или просвещённым начальством, его работу мы рассмотрим дальше.

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

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

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

Остаётся только одна возможность - использовать понимание, чтобы достичь преимуществ в области информации. "Комната скунсов" иногда воспринимается как отход от процесса в интересах креативности, но это совсем не так. Для такой работы нужна высокая концентрация опытных профессионалов, которые могут заменять понимание, заключённое в процессе, пониманием, заключённым в личном опыте. Это необходимое условие для "комнаты скунсов". Отход от детального процесса с его персональной защитой в виде простых определённых задач несёт неизбежный риск. Все должны понимать, что возможны ошибки, и результаты могут не соответствовать ожиданиям или противоречить существующим методам управления. Но когда это работает, это работает превосходно.

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

Уровень качества

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

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

DWORD WINAPI SecondThread (LPVOID lpwThreadParm) {
BOOL fDone = FALSE;
DWORD dw;

while (!fDone) {
// Wait forever for the mutex to become signaled.
dw = WaitForSingleObject(g_hMutex, INFINITE);

if (dw == WAIT_OBJECT_0) {
// Mutex became signalled.
if (g_nIndex >= MAX_TIMES) {
fDone = TRUE;
} else {
g_nIndex++;
g_dwTimes[g_nIndex - 1] = GetTickCount():
}

// Release the mutex.
ReleaseMutex(g_hMutex);
} else {
// The mutex was abandoned.
break;// Exit the while loop.
}
}
return(0);
}

Однако мы можем сделать это и достичь максимального уровня качества

DWORD TheThread(void *ThreadParm)
{
while(Index < MAX_TIMES &&
WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0)
{
if (Index < MAX_TIMES)
Times[Index++] = GetTickCount():
ReleaseMutex(Mutex);
}
return(0);
}

Причём вместо

hThreads[0] = CreateThread(..., FirstThread, ...);
hThreads[1] = CreateThread(..., SecondThread, ...);

можно писать

hThreads[0] = CreateThread(..., TheThread, ...);
hThreads[1] = CreateThread(..., TheThread, ...);

и тем самым избежать поддержки нескольких версий одного и того же кода.

Атомы моделирования

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

Опытные планировщики проектов знают, что выявление атомов и управление ими очень важно для удержания контроля над проектом. Сначала находятся атомы моделирования. Затем архитектор системы на основе интуиции находит ещё не решённые, но имеющие решение проблемы. Эти проблемы и определяют ход разработки, поскольку никто не хочет заниматься разработкой невозможной или неправильной архитектуры.

Архитектор может начертить границы атомов моделирования. Например, в системе обработки данных проблемы могут касаться структуры базы данных или логики управляющего приложения. Правильное определение атомов помогает контролировать как архитектуру, так и процесс разработки, распределённый между разработчиками. Кажый атом даётся одному разработчику или подгруппе, но каждый может работать с несколькими частями системы, чтобы решать свою задачу. Части системы, таким образом, должны быть хорошо структурированы, чтобы не стать кучей мусора. Определение атомов требует балансировки времени, пространства, общения, риска, навыков, переносимости, времени разработки и всё это должно быть сделано с задачами, сама разрешимость которых ещё не доказана. Для этого архитектор должен видеть корень проблемы и представлять, по крайней мере в голове, возможность компромиссов. Иногда очень трудно показать возможные альтернативы без понимания всей структуры. Сериализация ментальной модели всегда тяжела, её нельзя просто передать по фтп.

На этом уровне программирования "литературная критика" может получить серьёзные преимущества от изучения шаблонов проектирования. Это куски архитектурных приёмов, более крупные, чем обычное управление вычислениями, потоками, обработка исключений и т.д. Также они очень мощные и переносимые. Шаблоны проектирования подробно описаны в книге гаммы, хелма, джонсона и влиссидеса, которые дают такое определение:

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

Тема, которая объединяет этот раздел - эстетическое качество. Мы можем распознать бардак, когда мы его видим, но часто впадаем в ступор и не верим своим глазам от слов "это отвратительно, но это работает". Когда профессионал чувствует эстетический дискомфорт и говорит такое, мы должны это замечать. Стандарты красоты меняются от поколения к поколению, но всегда остаются функциональными. Поэтому создание красивого кода использует огромную базу знаний, которая может даже не осознаваться, и приводит к экономичным решениям. Прекрасный код потребует значительно меньших затрат на поддержку впоследствии. Это и есть красота. Эстетическое качество - возможно единственный из критериев выбора подходящего языка, так же, как импрессионист не может использовать акрил, пусть даже отличного качества.

Ангелы, драконы и философский камень

Наши предки были не менее сообразительными, и когда рано темнело, одним из немногих развлечений была игра с содержимым собственной головы. Понимание некоторых античных головоломок как образцов мышления картёжников прошлого полезно не только как интересный факт, но и как демонстрация возможностей интеллекта. Это то, что может дать нам контроль как над рабочими процессами, так и над всеми жизненными процессами.

Одной из горячих тем была бесконечность. Концептуально бесконечность довольно проста - достаточно сказать "всегда" и понятие готово. Возможная бесконечность несколько сложнее - если поручить кому-то считать всегда, можно получить бесконечный ряд чисел. Однако если получить бесконечное количество каких-то предметов, например, капусты, они заполнят бесконечный объём и больше ни для чего во вселенной места не останется. Но всё ещё есть возможность бесконечного числа бесконечно малых объектов - например, ангелов. Таким образом было бы возможно разместить бесконечное число танцующих ангелов на острие иглы.

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

Что касается драконов, они ревут и изрыгают пламя, их рёв настигает быстрее ветра, они хранят драгоценные камни в подземельях. Они живут в южной америке, китае, уэльсе. Они едят людей. Они черви, и античный символ мироздания - гигантский червь. Они - тот концептуальный сосуд, в котором предки собрали то, что мы называем тектоническими явлениями. У них не было идеи, что мир состоит из твёрдой коры, плавающей вокруг жидкого ядра, но они собрали все эффекты вместе, составив карту на основе прямых наблюдений. Дракон занимал место реальных вещей на их ментальных картах, пока они не изучили реальные процессы, которые производят эффекты драконов.

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

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

Убедитесь, что у вас есть реалистичная оценка ваших возможностей. Чтобы добиться успеха в чём угодно, нужна практика, но уж если вы что-то делаете, то полезно понимать, чего вы вообще можете добиться. Обычно такая оценка нуждается в коррекции вверх.

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

Основные хинты составления карт - 2

7. Интенсивный отдых

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

8. Выход из заколдованного круга.

Чувство возбуждения от эффективного размышления в фоновом режиме отличается от того затхлого тошнотного чувства, когда мозг исчерпал все возможные варианты и нуждается в эмпирической пище. Очевидно, не хватает каких-то ключевых данных или же вся модель кривая. Дайте ему больше данных, поговорите с кем-нибудь. Может быть, надо прочесать проблему частым бреднем. Если это баги в программе, вставьте печать после каждой строчки и сбросьте в лог. Затем внимательно изучите его за чашкой кофе. Конечно, это потребует много времени - а у вас есть идея получше? Если это ужасный набор асинхронных событий, нарисуйте их вручную на листе бумаги. Это позволит рассмотреть каждое по отдельности и возможно даст новые линии в расследовании ещё до середины этого занятия.

9. Ступор и стратегия своппинга

Существуют виды тупизма, свойственные только картёжникам. Они могут впасть в ступор, пытаясь оптимизировать слишком большую последовательность, которая не может уместиться в голове. Например, решить задачу про волка, козу и капусту для целого зоопарка. Современные ОС, когда им не хватает страниц памяти, применяют стратегию своппинга, выгружая ненужные страницы на диск. Это помогает очистить память для более важных процессов. Так что не впадайте в ступор - просто решайте небольшие задачи по очереди.

10. Одевание пододеяльника

Выверните пододеяльник, просуньте руки внутрь и возьмите дальние углы. Затем возьмите углы одеяла через углы пододеяльника и стряхните пододеяльник поверх одеяла. Немного практики, и вы сможете делать это менее чем за 30 секунд.