В величественных соборах Европы много арок, поддерживающих своды. В наше время для выполнения расчетов методом конечных элементов мы наверняка использовали бы симметричный мультипроцессор, но у строителей не было компьютеров и алгоритмов. У них не было ни тех замечательных уравнений, которые у нас есть в механике, ни даже написанного Ньютоном на латыни текста. Большинство из них были неграмотны. Но если вы вычислите оптимальную с точки зрения нагрузок/массы форму арки, то обнаружите, что они ее нашли. Они сделали это с помощью только тех инструментов, которые у них были -- их собственным опытом и способностью получить ощущение чего-либо с помощью нейронной сети, расположенной между ушей.
Убедитесь, что у вас есть реалистичное представление о собственных способностях. Обычно требуется его подкорректировать! Достижение успехов в чем-то требует практики, но учитывая, что вы в любом случае будете выполнять работу, хорошо бы знать, чего можно достичь.
Творческий хак и ответственный инженерный труд ортогональны, а не несовместимы. Мы можем получить удовольствие, развивая наши способности до предела, и продолжать выполнять наши обязательства перед коллегами.
Чтобы окончательно прояснить эту позицию, рассмотрим язык ассемблера. Код операции (opcode) может выполнять большинство специфических установок выходов процессора по заданным входным значениям, но мы рассматриваем код операции посредством его мнемоники, например DAA (Десятичная Коррекция Аккумулятора -- Decimal Adjust Accumulator). Даже когда есть взаимное соответствие между кодом операции и мнемоникой, более высокий уровень абстракции мнемоники может скрывать действие кода операции на аккумулятор, который просто преобразует биты в соответствии с алгоритмом. Если мы видим возможности обработки, предоставляемые кодом операции, можем ли мы "злоупотреблять" этим? Ответ зависит от обстоятельств.
Всякий раз, когда мы выясняем различие между намерением и действием, у нас есть возможность посмотреть на эффективность действия и задаться вопросом, что мы можем узнать о намерении, или области намерения исходя из структуры выбранного действия. Может быть, другое действие было бы лучше? Выявляют ли проблемы в действии проблемы в намерении? Когда мы проделываем это с книгами, то называем литературной критикой и беремся за дело всерьез. Если мы должны научиться лучше писать программы, то нам необходимо как можно лучше разобраться в некотором роде литературной критике, поскольку это единственный способ, который у нас есть, чтобы осознанно обсудить взаимодействие структуры и детали, которая характеризует стиль. По настоящему хорошо то, что в отличие от литературной критики прозы, литературная критика программ черпает знания из экспериментальных данных, таких как протоколы ошибок. Это увеличивает удовольствие и отсекает болтовню, но оставляет возможность обучения.
Мы можем получить строгую и элегантную дисциплину из различия между намерением и действием. Рассмотрим следующий фрагмент:
//Search the list of available dealers and find those that
// handle the triggering stock. Send them notification of
// the event.
for(DealerIterator DI(DealersOnline); DI.more(); DI++)
if(DI.CurrentDealer()->InPortfolio(TheEvent.GetStock()))
DI.CurrentDealer()->HandleEvent(TheEvent);
Определения объектов содержат допускаемые намерением варианты использования, выраженные в сжатой форме. Однако реально нет более мелкого дробления, когда мы можем заключить намерение в комментарий, а действие в код без того, чтобы комментарии не стали глупыми.
Если мы перемежаем комментарии и код на этом естественном уровне дробления, мы можем гарантировать, что все строки в программе проинтерпретированы в комментариях. У нас есть стимул проектировать объекты (или функции), которые при таком способе мы можем использовать экономно. Мы находим, что гораздо легче исправить некоторую неэлегантность, чем объяснить ее кому-нибудь.
Осознавая различие между намерением и действием, мы можем сделать их оба одновременно экономными, и удовлетворить цели детального псевдокода проектной документации и комментариев реализации, в то же время способствуя верификации реализации. Размещая все в одном месте, мы содействуем согласованности этих уровней.
Эта концепция развита далее в идее Дональда Кнута (Donald Knuth) о "грамотном программировании" (Literate Programming), которое, чтобы его сделать хорошо, требует средств системной поддержки, типа его Сетевой среды (Web environment) -- прообраза WWW (World Wide Web). Но вам не нужно скупать все гири, чтобы получить удовольствие от спорта. Грамотное программирование -- это скорее отношение (позиция), а не инструмент.
На этом уровне литературной критики мы можем получить серьезные выгоды от изучения паттерновпроектирования (design patterns). Это компоненты архитектурной технологии, которая гораздо сложнее, чем обычный поток управления (flow control) с обработкой ошибок и другими типичными идиомами. Они чрезвычайно мощные и платформонезависимые. Почитайте прекрасную книгу Гаммы, Хелма, Джонсона и Влиссидеса (Gamma, Helm, Johnson, Vlissides), в которой они описывают паттерн как нечто, что
"... описывает проблему, которая возникает вновь и вновь в нашей среде, и затем описывает основу решения этой проблемы таким образом, что вы можете использовать это решение миллион раз, не выполняя одни и те же действия дважды."
Тема, которая лежит в основе обсуждаемых в этом разделе предметов -- Эстетическое Качество. Мы все знаем о той беде, когда мы видим свою часто грозящую парализовать неспособность действовать на основании собственных ощущений, поскольку нет процедурного перевода для: "Это работает, но оно безобразно". Когда опытный профессионал чувствует эстетических дискомфорт и пытается об этом сказать, нам следует всегда обращать на это внимание. Наши стандарты красоты меняются от поколения к поколению, и по какой-то причине всегда соответствуют функции. В этом причина того, что делание кода красивым использует огромную базу знаний, которую мы не можем сознательно интегрировать, и ведет к эффективным по стоимости решениям. Если вещи красивы, то очень маловероятно, что они приведут к громадным затратам на поддержку. В этом состоит красота. Эстетическое качество -- это, вероятно, единственный критерий, против которого можно честно спорить, утверждая, что использован неправильный язык. Попытка изобразить рассвет в стиле импрессионизма, но акриловыми красками, будет выглядеть ужасно, даже если пульверизатор работал прекрасно.
Мы должны смотреть на исходный код, который мы создаем, не как на конечный продукт более интересного процесса, а как на явление со своими собственными правилами. Он должен хорошо выглядеть, если его повесить на стену. Затраты на то, чтобы действительно взглянуть на наш код и изучить закономерности геометрических узоров черного и белого, узоры в синтаксисе и узоры в проблемной области, сами по себе не так уж велики, но иногда позволяют буквально увидеть ошибки с расстояния шести футов.
С точки зрения всей этой литературной критики, что можно сказать о религиозных войнах? Конечно, часто они происходят развлечения ради, и мы не хотим препятствовать удовольствию от нелепых особенностей любимых инструментов и технологий наших друзей! Но иногда разумные программисты впадают в изматывающие и снижающие производительность перебранки, которые просто идут по кругу. Мы забываем, что строго между собой мы можем использовать структурные аргументы. Когда возникает нежелательная религиозная война, задайте следующие вопросы:
Какова глобальная позиция, включающая оба специальных случая?Имеется ли различие намерений между позициями?В чем состоит общая цель?
Например, вы оцениваете возможности мощной интегрированной среды. Вы используете Emacsна работе и доработали его, чтобы он управлял вашей кофеваркой. Я работаю на многих машинах, и, как это ни эксцентрично, я знаю, что на них всегда есть vi. Мы устанавливаем Emacsна новых машинах и обучаем viновичков. Ваш LISP, конечно, sucks.
Это соотнесение возможностей и целей часто дает великолепное примирение мнений у квалифицированных людей. Возможность прийти к соглашению о наилучших идиомах, чтобы сделать работу в хорошо понимаемой среде, не означает, что все должны изменить свое мнение -- они просто соглашаются. В противоположность популярному мнению, часто это правильный ответ. Разговаривая с квалифицированным человеком об идиомах новой среды, можно научится очень многому очень быстро, тогда как использование идиом из старой среды в новой приведет к постоянным стычкам.
Опытные планировщики проектов обнаружили, что распознавание и управление атомами познания в рамках проекта -- решающий начальный шаг. Сначала мы должны распознать атомы познания. Существует взаимосвязь между архитектурой системы и атомами познания, которые она содержит -- архитектор должен применить интуицию и опыт для выявления решаемых, но еще не решенных проблем. Проблемы, которые, как надеется архитектор, могут быть решены при разработке, будут влиять на дизайн, поскольку никто не хочет создавать архитектуру, которую нельзя реализовать!
Поэтому архитектор может очертить границы атомов познания вокруг проблемы. Например, в системах добычи знаний (data mining system), практические комбинаторные проблемы могут быть сконцентрированы в базе данных, либо на более высоком уровне прикладной логики. Правильная идентификация атомов познания будет управлять как архитектурой, так и рабочими пакетами, порученными отдельным членам команды. Каждый атом должен быть передан одному человеку или подгруппе для решения, но они могут обнаружить, что работают над более чем одной частью системы, чтобы разрешить свою проблему. Поэтому части должны быть хорошо разбиты на уровни, так что модули не сталкиваются в бестолковых сражениях. Идентификация атомов обычно требует учета баланса времени, пространства, связи, риска, возможностей команды, переносимости, времени разработки, и все это должно быть проделано при наличии атомов, разрешимость которых неочевидна. Поэтому архитектор должен суметь увидеть ключевую проблему и выразить, по крайней мере в своей собственной голове, природу условий компромиссов. Вполне возможно распознать набор очевидных компромиссов, о котором очень трудно рассказать другому, не обладающему, как картостроитель, способностью видеть структуру. Превращение мысленной модели в последовательность [действий] всегда тяжело, поскольку мы не думаем на языке технических бумаг, которые загружаем по ftp.
Во время идентификации атомов познания очень важно избежать специфических заблуждений, которые повторяются раз за разом. Часто возможно раздробить атом на более мелкие части не сильно задумываясь, и таким образом достигнуть этапа кодирования без больших усилий. Но когда дело доходит до реализации, все ввергается в хаос. Реальные проблемы никуда не деваются, они просто оборачиваются уродливыми API подсистем, проблемами производительности, ненадежностью и т.д. Границы атомов познания сжимаются все сильнее и сильнее, до ... Хоп! Они вновь возникают на уровне всей системы! Идеология упрощающего пошагового уточнения без регулярной сверки с действительностью и попыток найти логические ошибки в проекте ответственна за великое множество трагедий, включая потерю большей части отведенного на проект времени на попытки выполнять текущую проектную работу с чистосердечной неформальной желчностью, за которой следуют отчаянные попытки залатать дыры в программе.
Определение границ атома познания может происходить циклически, а квалифицированный архитектор укажет для них правильное место, где верхний уровень, где нижний, а что посередине. На начальных стадиях это может быть огромный, единый атом познания, который нужно передать в руки ответственного работника и сказать: "Попробуй разобрать эту мешанину, пожалуйста!"
По определению мы не знаем, каков наилучший подход к атому познания. Если бы мы знали, то он не был бы атомом. Из этого следует, что это не может планироваться на основе диаграмм планирования проектов (диаграмм Ганта) в терминах подцелей. Это должно быть одной задачей, а о длительности можно только догадываться. Опытные картостроители поднаторели в догадках, но они не могут объяснить, почему проблема тянет на два дня, неделю, полгода. Поэтому у того, кто дал наилучший прогноз, очень мало аргументов в его защиту. Боязнь последующих объяснений -- важный фактор, который часто отбивает у картостроителей охоту проявлять свои интуитивные способности и выдавать необходимые для планирования проекта цифры.
В результате расщепления атома познания работник обычно может выложить очень детальный набор описаний задач (целей), основанный на твердом понимании того, что должно быть сделано. Таким образом, во многих проектах следует поправить диаграммы Ганта, добавив туда расщепление атомов познания. Мы предполагаем, что большая часть проектов, пытающихся распланировать по Ганту все по дням, демонстрирует всеобъемлющую линейную модель производства. Программисты, работающие по таким диаграммам Ганта, не могут получить выгод из разумного управления атомами познания. Вместо того, чтобы повернуть свой разум к решаемой проблеме, они будут доказывать, что они хорошие работники, под "прессом", как будто унижая их можно заставить думать более ясно. Это грозит стрессом и снижает производительность.
Единственный честный аргумент, который мы можем здесь предложить -- это обещание, что это действительно произойдет. И хотя это ничего не доказывает, все что мы можем сделать -- это показать работающий пример приведения в минимальное состояние. Но это работает -- спросите любого, кто пытался.
В качестве примера возьмем код из прекрасной книги Джеффри Рихтера (Jeffrey Richter's Advanced Windows). Эта книга - полезное чтение для любого, кто пытается писать программы для Win32 API (Application Programming Interface) (поскольку иначе у вас не появится мысленная карта семантики системы).
Рихтер очень четко раскладывает по полочкам вопросы использования Win32, но даже в его примерах (и, в частности, как результат соглашений, которым он следует) появляется сложность, которую мы попробуем убрать. На странице 319 имеется функция SecondThread() Мы просто посмотрим на эту функцию, опустив остальную программу и некоторые глобальные определения:
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);
}
Для начала просто упростим стиль скобок, уберем пробел между ключевым словом и открывающей скобкой, а также многословный комментарий к ReleaseMutex. Мы в курсе, что идет религиозная война между последователями Кернигана и Ритчи (K&R) и последователями Вирта (Wirth) по поводу стиля скобок, но симметрия обрамления блока действительно позволяет лучше увидеть некоторые вещи. Дополнительная строка, которая при этом появляется, даст выигрыш чуть позднее -- следуйте за нами!
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(): } ReleaseMutex(g_hMutex); } else { // The mutex was abandoned. break; // Exit the while loop. } } return(0); }
Очень легко можно избавиться от одной локальной переменной: dwприсваивают значение, а в следующей операции тестируют. Инвертирование смысла проверки помогает локализовать ссылку (проверка, затем изменение g_nIndex). А пока мы здесь, нет смысла инкрементировать g_nIndex просто для того, чтобы вычесть 1 из текущего значения в следующей операции! Мы уже использовали постфиксную форму оператора инкремента языка Cи, который как раз для этого и предназначен.
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; while (!fDone) { // Wait forever for the mutex to become signaled. if (WaitForSingleObject(g_hMutex, INFINITE)==WAIT_OBJECT_0) { // Mutex became signalled. if (g_nIndex < MAX_TIMES) { g_dwTimes[g_nIndex++] = GetTickCount(); } else { fDone = TRUE; } ReleaseMutex(g_hMutex); } else { // The mutex was abandoned. break;// Exit the while loop. } } return(0); }
Прерывание цикла (break) зависит только от результата WaitForSingleObject, поэтому естественно переместить проверку в управляющее выражение, избавляясь от прерывания цикла и одного уровня вложенности:
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; while (!fDone && WaitForSingleObject(g_hMutex, INFINITE)==WAIT_OBJECT_0) { // Mutex became signalled. if (g_nIndex < MAX_TIMES) { g_dwTimes[g_nIndex++] = GetTickCount(); } else { fDone = TRUE; } ReleaseMutex(g_hMutex); } return(0); }
Теперь просто сожмем... Мы знаем - многие стандарты кодирования говорят, что мы всегда должны ставить фигурные скобки, поскольку иногда у глупых людей получается нечитаемая мешанина, но посмотрите, что получается, когда мы пренебрегаем этим правилом и концентрируемся на повышении читаемости кода.
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; while (!fDone && WaitForSingleObject(g_hMutex, INFINITE)==WAIT_OBJECT_0) { if (g_nIndex < MAX_TIMES) g_dwTimes[g_nIndex++] = GetTickCount(); else fDone = TRUE; ReleaseMutex(g_hMutex); } return(0); }
Теперь немного настоящей ереси. Черт возьми, в момент когда мы покончим с этой полной безответственностью, результат окажется совершенно неочевидным. (Здравый смысл поможет сделать лучше, чем правила.)
Ересь в том, что если мы знаем, для чего наши переменные, то мы знаем их типы. Если мы не знаем, для чего предназначена переменная, знание ее типа мало поможет. В любом случае, компилятор все равно сделает проверку типов. Поэтому избавимся от венгерской записи, а заодно и от переопределений типов, которые просто определены ( #define ), но не для нас. Сокрытие разыменования используя typedef - другое бесцельное упражнение, поскольку хотя и позволяет выполнить некоторую инкапсуляцию валюты, этого совершенно недостаточно, чтобы избавиться от беспокойства по этому поводу, поэтому аккуратные программисты вынуждены держать настоящие типы в голове. Поддержка концепции дальних указателей в именах переменных для 32 битного API с плоской адресацией -- тоже довольно глупое занятие.
DWORD SecondThread (void *ThreadParm) { BOOL done = FALSE; while (!done && WaitForSingleObject(Mutex, INFINITE)==WAIT_OBJECT_0) { if (Index < MAX_TIMES) Times[Index++] = GetTickCount(); else done = TRUE; ReleaseMutex(Mutex); } return(0); }
Теперь смотрите. Мы достигнем Плато Качества...
DWORD SecondThread(void *ThreadParm) { while(Index < MAX_TIMES && WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0) { if (Index < MAX_TIMES) Times[Index++] = GetTickCount(): ReleaseMutex(Mutex); } return(0); }
Одиннадцать строк против 26. На один уровень меньшая вложенность, но структура полностью прозрачна. Две локальных переменных исчезли. Нет блоков. Совсем нет вложенных else. Меньше мест, где могут скрываться ошибки.
(Если вы еще не программировали используя потоки (threads), то повторная проверка значения Indexвнутри тела цикла кажется грубой и ненужной. Если же программировали, то повторная проверка естественна и очевидна. Это очень важно: пока текущий поток приостановлен в WaitForSingleObject, другой поток скорее всего будет активен и изменит значение. То, что для вас очевидно, зависит от вашего опыта: еще одна мораль из этого примера -- рассмотрения только структуры куска кода недостаточно.)
Наконец, текст делает совершенно ясным, что разные потоки выполняют функции в разных контекстах. Поэтому совершенно не нужно определять функцию с именем FirstThread(), в точности такую же, как SecondThread(), и вызывать их так:
hThreads[0] = CreateThread(..., FirstThread, ...); hThreads[1] = CreateThread(..., SecondThread, ...);
Когда можно просто
hThreads[0] = CreateThread(..., TheThread, ...); hThreads[1] = CreateThread(..., TheThread, ...);
Почти треть этого примера получена клонированием! Если мы обнаружим ошибку в одной реализации, нам нужно будет не забыть исправить аналогичные ошибки везде. Зачем беспокоиться, когда можно просто слить их в одну. Это хороший способ, когда поджимают сроки.
Причина, по которой важно оценивать результат таким образом, в том, что понимание показывает гораздо более простой способ реализации, чем тот, с которого команда начинала. Классическое поле сражения картостроителей с паковщиками в программировании состоит в том, что картостроители видят, что с тем, что они узнали, повторная реализация может быть сделана быстрее и не будет страдать от проблем сопровождения, вырисовывающихся в существующем коде. Паковщики видят, что картостроители безумствуют, пытаясь разгромить всю их работу (как будто нет резервной копии) и повторить работу нескольких последних месяцев, которые были ужасны, поскольку они, очевидно, не знали, что они делали (они хранят изменяющиеся вещи). Паковщики настраивают одного из своих защитников остановить картостроителей, и организация вынуждена забыть о достигнутом понимании, которое не может быть использовано в контексте существующего кода.
Разумная организация хочет максимального понимания и минимального размера кода, которого только можно достигнуть. Организация, увязшая в модели производства разбухающего кода не учитывает понимание, а подсчитывает свои активы в растущих грудах кода.
Дело в том, что вокруг не должно быть ничего, что не имело бы ясно означенной цели по отношению к другим элементам композиции. Художнику нужно сохранять контроль за сообщением, и если картина содержит случайные предметы, то они будут вызывать в уме зрителя непредсказуемые ассоциации и искажать отношения между важными элементами.
Логики при проверке наборов аксиом сталкиваются с той же самой проблемой. Для этого у них есть гораздо более точный термин, но он происходит просто из компактных формальных структур, в рамках которых делаются наблюдения и доказываются теоремы. Они говорят, что набор аксиом должен быть " необходимым и достаточным". Необходимый и достаточный набор позволяет ясно увидеть "природу" рассматриваемого "мира". Это позволяет удостовериться, что обнаруженные следствия -- это истинные следствия исследуемой области, а не какие-то произвольные предположения.
Ни в одной из этих сфер деятельности не нужно напоминать людям о важности сохранения вещей настолько малыми, насколько это возможно, в противоположность программированию. К сожалению, практическая полезность нашего искусства означает, что люди часто стремятся как можно быстрее увидеть новую функциональность, которую мы пытаемся создать. Будучи создана, эта функциональность становится частью фона, и каждый из нас, от корпораций до отдельных людей, становится заложником наших собственных унаследованных систем.
Убедитесь, что у вас есть реалистичное представление о собственных способностях. Обычно требуется его подкорректировать! Достижение успехов в чем-то требует практики, но учитывая, что вы в любом случае будете выполнять работу, хорошо бы знать, чего можно достичь.
Творческий хак и ответственный инженерный труд ортогональны, а не несовместимы. Мы можем получить удовольствие, развивая наши способности до предела, и продолжать выполнять наши обязательства перед коллегами.
Литературная критика и паттерны проектирования
Существует важное различие между намерением и действием. У писателя может быть намерение показать нам, как ужасен этот плохой парень, и он будет это делать описывая сцены, содержащие отвратительные подробности. Наше намерение может состоять в сигнализации о том, что страница памяти в кэше отныне недоступна, наше действие состоит в установке флага "мусор" (dirty flag).Чтобы окончательно прояснить эту позицию, рассмотрим язык ассемблера. Код операции (opcode) может выполнять большинство специфических установок выходов процессора по заданным входным значениям, но мы рассматриваем код операции посредством его мнемоники, например DAA (Десятичная Коррекция Аккумулятора -- Decimal Adjust Accumulator). Даже когда есть взаимное соответствие между кодом операции и мнемоникой, более высокий уровень абстракции мнемоники может скрывать действие кода операции на аккумулятор, который просто преобразует биты в соответствии с алгоритмом. Если мы видим возможности обработки, предоставляемые кодом операции, можем ли мы "злоупотреблять" этим? Ответ зависит от обстоятельств.
Всякий раз, когда мы выясняем различие между намерением и действием, у нас есть возможность посмотреть на эффективность действия и задаться вопросом, что мы можем узнать о намерении, или области намерения исходя из структуры выбранного действия. Может быть, другое действие было бы лучше? Выявляют ли проблемы в действии проблемы в намерении? Когда мы проделываем это с книгами, то называем литературной критикой и беремся за дело всерьез. Если мы должны научиться лучше писать программы, то нам необходимо как можно лучше разобраться в некотором роде литературной критике, поскольку это единственный способ, который у нас есть, чтобы осознанно обсудить взаимодействие структуры и детали, которая характеризует стиль. По настоящему хорошо то, что в отличие от литературной критики прозы, литературная критика программ черпает знания из экспериментальных данных, таких как протоколы ошибок. Это увеличивает удовольствие и отсекает болтовню, но оставляет возможность обучения.
Мы можем получить строгую и элегантную дисциплину из различия между намерением и действием. Рассмотрим следующий фрагмент:
//Search the list of available dealers and find those that
// handle the triggering stock. Send them notification of
// the event.
for(DealerIterator DI(DealersOnline); DI.more(); DI++)
if(DI.CurrentDealer()->InPortfolio(TheEvent.GetStock()))
DI.CurrentDealer()->HandleEvent(TheEvent);
Определения объектов содержат допускаемые намерением варианты использования, выраженные в сжатой форме. Однако реально нет более мелкого дробления, когда мы можем заключить намерение в комментарий, а действие в код без того, чтобы комментарии не стали глупыми.
Если мы перемежаем комментарии и код на этом естественном уровне дробления, мы можем гарантировать, что все строки в программе проинтерпретированы в комментариях. У нас есть стимул проектировать объекты (или функции), которые при таком способе мы можем использовать экономно. Мы находим, что гораздо легче исправить некоторую неэлегантность, чем объяснить ее кому-нибудь.
Осознавая различие между намерением и действием, мы можем сделать их оба одновременно экономными, и удовлетворить цели детального псевдокода проектной документации и комментариев реализации, в то же время способствуя верификации реализации. Размещая все в одном месте, мы содействуем согласованности этих уровней.
Эта концепция развита далее в идее Дональда Кнута (Donald Knuth) о "грамотном программировании" (Literate Programming), которое, чтобы его сделать хорошо, требует средств системной поддержки, типа его Сетевой среды (Web environment) -- прообраза WWW (World Wide Web). Но вам не нужно скупать все гири, чтобы получить удовольствие от спорта. Грамотное программирование -- это скорее отношение (позиция), а не инструмент.
На этом уровне литературной критики мы можем получить серьезные выгоды от изучения паттерновпроектирования (design patterns). Это компоненты архитектурной технологии, которая гораздо сложнее, чем обычный поток управления (flow control) с обработкой ошибок и другими типичными идиомами. Они чрезвычайно мощные и платформонезависимые. Почитайте прекрасную книгу Гаммы, Хелма, Джонсона и Влиссидеса (Gamma, Helm, Johnson, Vlissides), в которой они описывают паттерн как нечто, что
"... описывает проблему, которая возникает вновь и вновь в нашей среде, и затем описывает основу решения этой проблемы таким образом, что вы можете использовать это решение миллион раз, не выполняя одни и те же действия дважды."
Тема, которая лежит в основе обсуждаемых в этом разделе предметов -- Эстетическое Качество. Мы все знаем о той беде, когда мы видим свою часто грозящую парализовать неспособность действовать на основании собственных ощущений, поскольку нет процедурного перевода для: "Это работает, но оно безобразно". Когда опытный профессионал чувствует эстетических дискомфорт и пытается об этом сказать, нам следует всегда обращать на это внимание. Наши стандарты красоты меняются от поколения к поколению, и по какой-то причине всегда соответствуют функции. В этом причина того, что делание кода красивым использует огромную базу знаний, которую мы не можем сознательно интегрировать, и ведет к эффективным по стоимости решениям. Если вещи красивы, то очень маловероятно, что они приведут к громадным затратам на поддержку. В этом состоит красота. Эстетическое качество -- это, вероятно, единственный критерий, против которого можно честно спорить, утверждая, что использован неправильный язык. Попытка изобразить рассвет в стиле импрессионизма, но акриловыми красками, будет выглядеть ужасно, даже если пульверизатор работал прекрасно.
Мы должны смотреть на исходный код, который мы создаем, не как на конечный продукт более интересного процесса, а как на явление со своими собственными правилами. Он должен хорошо выглядеть, если его повесить на стену. Затраты на то, чтобы действительно взглянуть на наш код и изучить закономерности геометрических узоров черного и белого, узоры в синтаксисе и узоры в проблемной области, сами по себе не так уж велики, но иногда позволяют буквально увидеть ошибки с расстояния шести футов.
С точки зрения всей этой литературной критики, что можно сказать о религиозных войнах? Конечно, часто они происходят развлечения ради, и мы не хотим препятствовать удовольствию от нелепых особенностей любимых инструментов и технологий наших друзей! Но иногда разумные программисты впадают в изматывающие и снижающие производительность перебранки, которые просто идут по кругу. Мы забываем, что строго между собой мы можем использовать структурные аргументы. Когда возникает нежелательная религиозная война, задайте следующие вопросы:
Какова глобальная позиция, включающая оба специальных случая?Имеется ли различие намерений между позициями?В чем состоит общая цель?
Например, вы оцениваете возможности мощной интегрированной среды. Вы используете Emacsна работе и доработали его, чтобы он управлял вашей кофеваркой. Я работаю на многих машинах, и, как это ни эксцентрично, я знаю, что на них всегда есть vi. Мы устанавливаем Emacsна новых машинах и обучаем viновичков. Ваш LISP, конечно, sucks.
Это соотнесение возможностей и целей часто дает великолепное примирение мнений у квалифицированных людей. Возможность прийти к соглашению о наилучших идиомах, чтобы сделать работу в хорошо понимаемой среде, не означает, что все должны изменить свое мнение -- они просто соглашаются. В противоположность популярному мнению, часто это правильный ответ. Разговаривая с квалифицированным человеком об идиомах новой среды, можно научится очень многому очень быстро, тогда как использование идиом из старой среды в новой приведет к постоянным стычкам.
Атомы познания
В любой задаче, требующей понимания, мы всегда будем находить по крайней мере один " атом познания". Атом познания -- это часть проблемы, которая может быть адекватнорассмотрена только при условии загрузки ее элементов, черт, знаков и т.п. в сознание отдельного картостроителя и получения наилучшего возможного результата. Слово "адекватно" здесь очень важно -- существует целый букет проблем, которые, если бы имелись неограниченные ресурсы, могли быть разрешены играючи, но нужно очень хорошо подумать, чтобы решить их для реальных условий. Например, любая толпа идиотов могла бы справиться с задачей смены декораций, которая возникает во время большого музыкального шоу, если на это дано несколько недель. Но сделать то же самое за время, пока конферансье что-то меланхолично бубнит в свете единственного прожектора, требует гениальности.Опытные планировщики проектов обнаружили, что распознавание и управление атомами познания в рамках проекта -- решающий начальный шаг. Сначала мы должны распознать атомы познания. Существует взаимосвязь между архитектурой системы и атомами познания, которые она содержит -- архитектор должен применить интуицию и опыт для выявления решаемых, но еще не решенных проблем. Проблемы, которые, как надеется архитектор, могут быть решены при разработке, будут влиять на дизайн, поскольку никто не хочет создавать архитектуру, которую нельзя реализовать!
Поэтому архитектор может очертить границы атомов познания вокруг проблемы. Например, в системах добычи знаний (data mining system), практические комбинаторные проблемы могут быть сконцентрированы в базе данных, либо на более высоком уровне прикладной логики. Правильная идентификация атомов познания будет управлять как архитектурой, так и рабочими пакетами, порученными отдельным членам команды. Каждый атом должен быть передан одному человеку или подгруппе для решения, но они могут обнаружить, что работают над более чем одной частью системы, чтобы разрешить свою проблему. Поэтому части должны быть хорошо разбиты на уровни, так что модули не сталкиваются в бестолковых сражениях. Идентификация атомов обычно требует учета баланса времени, пространства, связи, риска, возможностей команды, переносимости, времени разработки, и все это должно быть проделано при наличии атомов, разрешимость которых неочевидна. Поэтому архитектор должен суметь увидеть ключевую проблему и выразить, по крайней мере в своей собственной голове, природу условий компромиссов. Вполне возможно распознать набор очевидных компромиссов, о котором очень трудно рассказать другому, не обладающему, как картостроитель, способностью видеть структуру. Превращение мысленной модели в последовательность [действий] всегда тяжело, поскольку мы не думаем на языке технических бумаг, которые загружаем по ftp.
Во время идентификации атомов познания очень важно избежать специфических заблуждений, которые повторяются раз за разом. Часто возможно раздробить атом на более мелкие части не сильно задумываясь, и таким образом достигнуть этапа кодирования без больших усилий. Но когда дело доходит до реализации, все ввергается в хаос. Реальные проблемы никуда не деваются, они просто оборачиваются уродливыми API подсистем, проблемами производительности, ненадежностью и т.д. Границы атомов познания сжимаются все сильнее и сильнее, до ... Хоп! Они вновь возникают на уровне всей системы! Идеология упрощающего пошагового уточнения без регулярной сверки с действительностью и попыток найти логические ошибки в проекте ответственна за великое множество трагедий, включая потерю большей части отведенного на проект времени на попытки выполнять текущую проектную работу с чистосердечной неформальной желчностью, за которой следуют отчаянные попытки залатать дыры в программе.
Определение границ атома познания может происходить циклически, а квалифицированный архитектор укажет для них правильное место, где верхний уровень, где нижний, а что посередине. На начальных стадиях это может быть огромный, единый атом познания, который нужно передать в руки ответственного работника и сказать: "Попробуй разобрать эту мешанину, пожалуйста!"
По определению мы не знаем, каков наилучший подход к атому познания. Если бы мы знали, то он не был бы атомом. Из этого следует, что это не может планироваться на основе диаграмм планирования проектов (диаграмм Ганта) в терминах подцелей. Это должно быть одной задачей, а о длительности можно только догадываться. Опытные картостроители поднаторели в догадках, но они не могут объяснить, почему проблема тянет на два дня, неделю, полгода. Поэтому у того, кто дал наилучший прогноз, очень мало аргументов в его защиту. Боязнь последующих объяснений -- важный фактор, который часто отбивает у картостроителей охоту проявлять свои интуитивные способности и выдавать необходимые для планирования проекта цифры.
В результате расщепления атома познания работник обычно может выложить очень детальный набор описаний задач (целей), основанный на твердом понимании того, что должно быть сделано. Таким образом, во многих проектах следует поправить диаграммы Ганта, добавив туда расщепление атомов познания. Мы предполагаем, что большая часть проектов, пытающихся распланировать по Ганту все по дням, демонстрирует всеобъемлющую линейную модель производства. Программисты, работающие по таким диаграммам Ганта, не могут получить выгод из разумного управления атомами познания. Вместо того, чтобы повернуть свой разум к решаемой проблеме, они будут доказывать, что они хорошие работники, под "прессом", как будто унижая их можно заставить думать более ясно. Это грозит стрессом и снижает производительность.
Плато качества
Когда принята стратегия формирования мысленной карты проблемной области и попыток упростить ее, обычно сталкиваются с проблемой определения момента окончания работы над картой. Эта проблема возникает на каждом уровне проектирования. Сверхъестественно, но почти всегда есть глубокое решение, которое значительно проще всех остальных и очевидно минимальное. (Есть много способов это выразить, но потом этот вывод станет очевидным.) Хотя проповеди типа: "Ты узнаешь это, когда увидишь!" -- несомненная истина, но они не говорят, куда посмотреть.Единственный честный аргумент, который мы можем здесь предложить -- это обещание, что это действительно произойдет. И хотя это ничего не доказывает, все что мы можем сделать -- это показать работающий пример приведения в минимальное состояние. Но это работает -- спросите любого, кто пытался.
В качестве примера возьмем код из прекрасной книги Джеффри Рихтера (Jeffrey Richter's Advanced Windows). Эта книга - полезное чтение для любого, кто пытается писать программы для Win32 API (Application Programming Interface) (поскольку иначе у вас не появится мысленная карта семантики системы).
Рихтер очень четко раскладывает по полочкам вопросы использования Win32, но даже в его примерах (и, в частности, как результат соглашений, которым он следует) появляется сложность, которую мы попробуем убрать. На странице 319 имеется функция SecondThread() Мы просто посмотрим на эту функцию, опустив остальную программу и некоторые глобальные определения:
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);
}
Для начала просто упростим стиль скобок, уберем пробел между ключевым словом и открывающей скобкой, а также многословный комментарий к ReleaseMutex. Мы в курсе, что идет религиозная война между последователями Кернигана и Ритчи (K&R) и последователями Вирта (Wirth) по поводу стиля скобок, но симметрия обрамления блока действительно позволяет лучше увидеть некоторые вещи. Дополнительная строка, которая при этом появляется, даст выигрыш чуть позднее -- следуйте за нами!
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(): } ReleaseMutex(g_hMutex); } else { // The mutex was abandoned. break; // Exit the while loop. } } return(0); }
Очень легко можно избавиться от одной локальной переменной: dwприсваивают значение, а в следующей операции тестируют. Инвертирование смысла проверки помогает локализовать ссылку (проверка, затем изменение g_nIndex). А пока мы здесь, нет смысла инкрементировать g_nIndex просто для того, чтобы вычесть 1 из текущего значения в следующей операции! Мы уже использовали постфиксную форму оператора инкремента языка Cи, который как раз для этого и предназначен.
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; while (!fDone) { // Wait forever for the mutex to become signaled. if (WaitForSingleObject(g_hMutex, INFINITE)==WAIT_OBJECT_0) { // Mutex became signalled. if (g_nIndex < MAX_TIMES) { g_dwTimes[g_nIndex++] = GetTickCount(); } else { fDone = TRUE; } ReleaseMutex(g_hMutex); } else { // The mutex was abandoned. break;// Exit the while loop. } } return(0); }
Прерывание цикла (break) зависит только от результата WaitForSingleObject, поэтому естественно переместить проверку в управляющее выражение, избавляясь от прерывания цикла и одного уровня вложенности:
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; while (!fDone && WaitForSingleObject(g_hMutex, INFINITE)==WAIT_OBJECT_0) { // Mutex became signalled. if (g_nIndex < MAX_TIMES) { g_dwTimes[g_nIndex++] = GetTickCount(); } else { fDone = TRUE; } ReleaseMutex(g_hMutex); } return(0); }
Теперь просто сожмем... Мы знаем - многие стандарты кодирования говорят, что мы всегда должны ставить фигурные скобки, поскольку иногда у глупых людей получается нечитаемая мешанина, но посмотрите, что получается, когда мы пренебрегаем этим правилом и концентрируемся на повышении читаемости кода.
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) { BOOL fDone = FALSE; while (!fDone && WaitForSingleObject(g_hMutex, INFINITE)==WAIT_OBJECT_0) { if (g_nIndex < MAX_TIMES) g_dwTimes[g_nIndex++] = GetTickCount(); else fDone = TRUE; ReleaseMutex(g_hMutex); } return(0); }
Теперь немного настоящей ереси. Черт возьми, в момент когда мы покончим с этой полной безответственностью, результат окажется совершенно неочевидным. (Здравый смысл поможет сделать лучше, чем правила.)
Ересь в том, что если мы знаем, для чего наши переменные, то мы знаем их типы. Если мы не знаем, для чего предназначена переменная, знание ее типа мало поможет. В любом случае, компилятор все равно сделает проверку типов. Поэтому избавимся от венгерской записи, а заодно и от переопределений типов, которые просто определены ( #define ), но не для нас. Сокрытие разыменования используя typedef - другое бесцельное упражнение, поскольку хотя и позволяет выполнить некоторую инкапсуляцию валюты, этого совершенно недостаточно, чтобы избавиться от беспокойства по этому поводу, поэтому аккуратные программисты вынуждены держать настоящие типы в голове. Поддержка концепции дальних указателей в именах переменных для 32 битного API с плоской адресацией -- тоже довольно глупое занятие.
DWORD SecondThread (void *ThreadParm) { BOOL done = FALSE; while (!done && WaitForSingleObject(Mutex, INFINITE)==WAIT_OBJECT_0) { if (Index < MAX_TIMES) Times[Index++] = GetTickCount(); else done = TRUE; ReleaseMutex(Mutex); } return(0); }
Теперь смотрите. Мы достигнем Плато Качества...
DWORD SecondThread(void *ThreadParm) { while(Index < MAX_TIMES && WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0) { if (Index < MAX_TIMES) Times[Index++] = GetTickCount(): ReleaseMutex(Mutex); } return(0); }
Одиннадцать строк против 26. На один уровень меньшая вложенность, но структура полностью прозрачна. Две локальных переменных исчезли. Нет блоков. Совсем нет вложенных else. Меньше мест, где могут скрываться ошибки.
(Если вы еще не программировали используя потоки (threads), то повторная проверка значения Indexвнутри тела цикла кажется грубой и ненужной. Если же программировали, то повторная проверка естественна и очевидна. Это очень важно: пока текущий поток приостановлен в WaitForSingleObject, другой поток скорее всего будет активен и изменит значение. То, что для вас очевидно, зависит от вашего опыта: еще одна мораль из этого примера -- рассмотрения только структуры куска кода недостаточно.)
Наконец, текст делает совершенно ясным, что разные потоки выполняют функции в разных контекстах. Поэтому совершенно не нужно определять функцию с именем FirstThread(), в точности такую же, как SecondThread(), и вызывать их так:
hThreads[0] = CreateThread(..., FirstThread, ...); hThreads[1] = CreateThread(..., SecondThread, ...);
Когда можно просто
hThreads[0] = CreateThread(..., TheThread, ...); hThreads[1] = CreateThread(..., TheThread, ...);
Почти треть этого примера получена клонированием! Если мы обнаружим ошибку в одной реализации, нам нужно будет не забыть исправить аналогичные ошибки везде. Зачем беспокоиться, когда можно просто слить их в одну. Это хороший способ, когда поджимают сроки.
Знание, а не число строк кода (KLOCS)
Программисты дороги. Результаты их работы должны быть собраны и использованы к выгоде их организации. Проблема в том, что традиционный способ паковщика подбить результаты -- подсчитать то, что они могут увидеть. Результаты изучения проблемы командой программистов, пришедшей к пониманию и проверившей это понимание, получив надежный код, выражаются не в числе строк кода (KLOCS), которые они набрали во время изучения. Результаты в окончательном понимании, к которому они пришли, когда закончили.Причина, по которой важно оценивать результат таким образом, в том, что понимание показывает гораздо более простой способ реализации, чем тот, с которого команда начинала. Классическое поле сражения картостроителей с паковщиками в программировании состоит в том, что картостроители видят, что с тем, что они узнали, повторная реализация может быть сделана быстрее и не будет страдать от проблем сопровождения, вырисовывающихся в существующем коде. Паковщики видят, что картостроители безумствуют, пытаясь разгромить всю их работу (как будто нет резервной копии) и повторить работу нескольких последних месяцев, которые были ужасны, поскольку они, очевидно, не знали, что они делали (они хранят изменяющиеся вещи). Паковщики настраивают одного из своих защитников остановить картостроителей, и организация вынуждена забыть о достигнутом понимании, которое не может быть использовано в контексте существующего кода.
Разумная организация хочет максимального понимания и минимального размера кода, которого только можно достигнуть. Организация, увязшая в модели производства разбухающего кода не учитывает понимание, а подсчитывает свои активы в растущих грудах кода.
Хорошая композиция и экспоненциальный рост продуктивности
Определение хорошей композиции, которое часто используют в художественных школах, звучит так: "Если убрать или изменить любой элемент, то изменится и целое". Вероятно, это морской пейзаж, с маяком, задающим с одной стороны сильную вертикаль, приковывающую взгляд и позиционирующуюся относительно волн позади. Ситуация с маяком (и волнами) -- то, что мы распознаем, и тут живопись показывает свою мощь. Если бы вместо величественного маяка стояло приземистое здание, картина говорила бы о чем-то другом. Если бы поверхность воды была гладкой или там резвились купальщики, то картина несла бы еще какие-то сообщения.Дело в том, что вокруг не должно быть ничего, что не имело бы ясно означенной цели по отношению к другим элементам композиции. Художнику нужно сохранять контроль за сообщением, и если картина содержит случайные предметы, то они будут вызывать в уме зрителя непредсказуемые ассоциации и искажать отношения между важными элементами.
Логики при проверке наборов аксиом сталкиваются с той же самой проблемой. Для этого у них есть гораздо более точный термин, но он происходит просто из компактных формальных структур, в рамках которых делаются наблюдения и доказываются теоремы. Они говорят, что набор аксиом должен быть " необходимым и достаточным". Необходимый и достаточный набор позволяет ясно увидеть "природу" рассматриваемого "мира". Это позволяет удостовериться, что обнаруженные следствия -- это истинные следствия исследуемой области, а не какие-то произвольные предположения.
Ни в одной из этих сфер деятельности не нужно напоминать людям о важности сохранения вещей настолько малыми, насколько это возможно, в противоположность программированию. К сожалению, практическая полезность нашего искусства означает, что люди часто стремятся как можно быстрее увидеть новую функциональность, которую мы пытаемся создать. Будучи создана, эта функциональность становится частью фона, и каждый из нас, от корпораций до отдельных людей, становится заложником наших собственных унаследованных систем.