Текст книги "The Programmers' Stone (Программистский камень)"
Автор книги: Alan Carter
Соавторы: Colston Sanger
сообщить о нарушении
Текущая страница: 6 (всего у книги 13 страниц)
Другая область, где на этапе высокоуровневого проектирования действительно очень полезны небольшие фрагменты кода – получение реального ощущения семантики системы, которую вы собираетесь использовать. Мы всегда должны изучить новые API для операционных систем, GUI, библиотек и т.д. Потребуются годы, чтобы действительно полностью освоить правильное использование API. Поэтому заглядывайте в книги, которые обсуждают API, и пишите небольшие программки, демонстрирующие свойства, которые, как вы думаете, вам понадобятся. Это на самом деле помогает сконцентрировать ваш ум на том, что вам нужно, чтобы проследить путь снизу вверх, в то время, пока ваша разработка происходит сверху вниз, и гарантирует, что вы не пытаетесь использовать семантику, которой на самом деле нет. Попытка разработать проект, требующий другого дизайна операционной системы, может оказаться очень сложной, но если вы провели несколько минут за написанием маленькой программки с целью поупражняться с какой-то особенностью, то вы будете использовать ее как есть, и никогда не вспомните, что говорится в документации. Вы отыграете эти минуты во время реализации, поскольку вы можете просто скопировать ваши заготовки в исходный код и немного их поправить.
Посвятите некоторое время просмотру дизайна используемых вами API. Взгляните на их валюту – значения, передаваемые из/в API. Как части этого интерфейса стыкуются друг с другом? Хорошо ли они спроектированы? Какие идиомы предлагают вам использовать их разработчики? API обычно проектируют опытные разработчики, и они похожи на небольшие послания от очень ярких людей о том, как они видят мир. Стиль UNIX API Кена Томпсона (Ken Thompson) прекрасно сохранился за 30 лет. Он сам говорил, что единственное изменение, которое он бы сделал: " Я бы написал creat() c e!" В UNIX API есть что-то очень близкое к тому, как работают компьютеры.
Этот раздел целиком посвящен тому, насколько важно уметь смотреть на один уровень ниже, чем тот, на котором работаешь. Это справедливо несмотря даже на то, что сокрытие деталей реализации – это постоянная цель нашей работы. Чем лучше мы этого добиваемся, тем больше мы выигрываем, но мы еще не настолько умелы, чтобы забывать о нижних уровнях. Понимание того, где компилятор резервирует кучу и стек, позволяет нам обнаружить грубые ошибки, когда мы нарушаем модель языка. Знание имеющегося в нашем распоряжении объема физической памяти (и файла подкачки) позволяет нам писать программы, которые будут работать в ситуациях реального мира. Даже истинно виртуальные машины, такие как виртуальная Java машина, предоставляет сервисы настолько низкого уровня, что мы можем полагаться на то, что их создатели реализуют их разумно, чтобы мы могли предсказать эффективность наших операций.
Концептуальная целостность
В «Мифическом человеко-месяце» Фредерик Брукс (The Mythical Man Month by Fred Brooks) подчеркивает важность концептуальной целостности проекта. Наш глубокий взгляд на программирование предполагает некоторые практические пути достижения концептуальной целостности.
Во-первых, мы знаем о важности мысленных карт. Если каждый член команды разделяет внутренне согласованную мысленную карту создаваемой системы, то возможный вклад каждого будет соответствовать духу всей разработки. Если не разделяет, то не будет, поскольку руководство по стилю, достаточно подробное, чтобы позволить кому-либо сделать все правильно без знания того, что они делают, окажется гораздо сложнее в написании, чем сама система.
Во-вторых, у нас есть картина того, как программист оптимизировал последовательность проектных решений для получения минимального решения и управления сложностью. Поэтому нам нужно посмотреть на виды конструкций, из которых строятся программы, и убедиться, что они общедоступны. Такое руководство по стилю проекта указывает на согласованный набор соглашений об именовании переменных, стратегий обработки ошибок, примеров идиом использования API подсистем и даже стиль комментариев. Можно сказать, что управляя формой кирпичей, архитектор может задать форму здания, оставляя в то же время гибкость в руках конструктора. Структура такого кода, таким образом, гарантирует, что код канонических примеров предсказуем и элегантен. Поэтому примеры кода в руководстве по стилю управляют структурой, а структура управляет кодом. Здесь мы видим еще одно эхо "Хода конем" – если мы используем правильные структуры, то мы можем ввести в игру необходимый и достаточный синтаксис и написать минимум текста. И наоборот, чем более запутанные берутся приемы, тем больше их нужно, чтобы переплести их вместе.
И, наконец, последнее преимущество концептуальной целостности, ценимое профессиональными программистами – очень практичное. Представьте, что вы в работе. Вы увидели способ распределить функциональность, вы нашли элегантные методы обхода всех тех способов, какими ОС может сигнализировать об ошибке, и уже наполовину сделали работу по кодированию, и вам понадобилось имя для новой переменной. В вашей голове застопорилось от перегрузки тривиальностью! Экспоненциальная выгода от сосредоточенности внимания и удержании этого состояния так же велика, как экспоненциальная выгода от минимизации размера кода, поэтому стоит оградить себя от всяких глупых раздражителей, отвлекающих внимание. В местах, где каждый прекращает работу через каждые десять минут для объяснений с руководством, преимущества настоящей концентрации внимания никогда не проявятся, но там, где внешние обстоятельства тщательно отсеиваются, наличие руководства по стилю позволяет часто делать подобные штучки [например, выбор имен для переменных – С.К.] на лету и может существенно увеличить эффективность работы.
Управление настроением
У паковщиков есть правила ведения дискуссий, включающие подсчет очков каждого и демонстрирующие полную незаинтересованность в конечном результате в поведении и языке. Картостроители также имеют правила ведения дискуссий, но они несколько другие.
Картостроителям разрешается подпрыгивать и много кричать. Но это не означает, что они собираются убить друг друга, это означает их причастность. Вероятно, они прервутся только сходив вместе на ланч, продолжив свои выкрики по возвращении.
У каждого будет свой собственный способ говорить о свойствах проблемы, и понадобится согласовать общий жаргон проекта. Сделайте эти согласования по совместной мысленной модели и нацельте группу на созидание и оспаривание части достижений группы, а не на воздвижение стен вокруг замков из песка. Ненавидьте грех, а не грешника!
Если коллега говорит что-то, что вы не понимаете или кажется парадоксальным или нелепым, спросите себя, а что если человек пытается рассказать о части карты, которую вы видите перед собой, с совершенно другой точки зрения. Узнайте, что это значит на языке, который вас устраивает. Начните с предположения, что у него имеется кое-что интересное в голове, и попытайтесь выяснить, что это такое. Этот стиль дискуссий, о котором много думали апологеты зететики (Zetetics), вышедшие из Общества по Исследованию Паранормальных Проявлений (Society for the Investigation of Claims of the Paranormal – SICOP), чтобы исследовать, какими могли бы быть правила доказательства существования паранормальных явлений.
Просто быть группой картостроителей с совместно используемой мысленной моделью совершенно недостаточно, чтобы начать вместе ее изменять. Как и во всех остальных случаях, мы должны явно осознать правильность того, что мы пытаемся сделать. На других этапах проекта команде потребуются другие размышления. Иногда вам захочется собрать вместе все трудности и усложнить модель. В другой раз стратегическими станут организация и упрощение. Иногда вам захочется описать свои потребности, а в другой раз вам нужно будет решить, как объяснить модель заказчику (пользователю).
Если в дискуссии у членов команды разные цели, то мало чего можно достичь. Никто не сможет сконструировать разумное описание технических моментов, если его прерывают люди, которые думают, что цель заключается в максимизации приемлемости для пользователя (maximising customer acceptability).
Это не означает, что все собрания без ясно определенной цели с неизбежностью вырождаются в переход на личности – это происходит только когда произвольно выбранные цели взаимно исключают друг друга. Но даже дискуссии со многими целями могут быть прояснены, если сначала явно сформулировать, в чем эти цели состоят. И ни в коем случае внимание группы не должно удерживаться с ритуальной одержимостью паковщиков, поскольку идея заключается в прояснении дискуссии, а не в избегании ее. Как всегда, мы должны служить цели, а не микрополиции процедуры. Если член команды видит, что что-то уводит от темы (и засоряет весь вид), он должен сказать об этом. И наоборот, если он видит обстоятельство, которое нужно обсудить, но оно не настолько критично, он может записать его на клочке бумаги и заявить о нем как о теме для обсуждения на следующих собраниях.
Управление настроением также распространяется на весь цикл проекта. Идентифицируя специфические настроения и их изменения, лидер команды может обеспечить структуру для деятельности команды и избежать ситуаций, когда каждый день каждый приходит на работу и занимается каким-то кодированием, без какого бы ни было ясного понимания того, как должен проходить нормальный день.
За рамками проекта настроение организации в целом также может влиять на проект. Главная угроза может исходить от того, как организация смотрит на взаимодействие (общение) внутри себя. Некоторые организации установили высокоритуализованные границы между группами, что приводит к значительным затратам времени на управление внутри организации. Когда велика сила устаревших административных процедур, приводящих к росту сложности, и, следовательно, уменьшающих эффективность, существует лишь немного сил, которые могут их упростить. Это происходит потому, что от последствий страдают только люди, связанные с действительностью и реально выполняющие работу, в то время как остальные достигают прогресса в создании круговой поруки, говоря себе при этом, что они делают работу.
Коммуникационный барьер между картостроителями и паковщиками часто заставляет людей говорить, что эффект от навязанных административных накладных расходов ограничен. Имеется три эффекта, которые может вызвать неэффективное администрирование, на высоком уровне абстракции и, следовательно, как знают картостроители, большой разрушительной силы.
Это отнимает время у настоящей работы. Некоторые организации требуют, чтобы работники заполняли отчеты о командировках, такие сложные, что люди на самом деле выделяют полдня в месяц только на заполнение этих отчетов. Да что там – 10% времени (и зарплаты) тратится на тупой ритуальный административный процедурализм! Данные отчетов могли бы собирать гораздо проще, а остальную конторскую обработку, если это так необходимо, могли бы делать клерки, которым платят меньше и которые многочисленнее.
Это прерывает нормальный ход дела. Часто требуется несколько часов, чтобы загрузить проблему в свое сознание, и если некто из отдела кадров постоянно прерывает по поводу проблем с их файловой системой, то разработчик за несколько рабочих дней не найдет нескольких секунд, чтобы упорядочить свои мысли о проблеме. Очень скоро это превращается в пытку водой, когда вывихнутый мозг программиста уходит от обдумывания проблемы, поскольку каждый раз, когда он вкладывает эмоциональную энергию, необходимую для загрузки требующей рассмотрения трудной, неструктурированной проблемы, его уводят в сторону. Это очень неприятный опыт. К алкоголикам подключали электроды и пускали ток, когда они прикасались к бутылке виски. Это то же самое.
Это забивает голову. Быть картостроителем – значит искать ясности и рассматривать множество вещей. Если назойливый и некомпетентный администратор обращает рабочее место в сюрреалистичный кошмар, то удержание фокуса на высоких стандартах ясности, необходимой для программирования, становится очень трудным делом, а если никогда нельзя предсказать, как долго займет покупка нужного программного пакета, то не может быть и речи ни о каком планировании.
Команды могут многое сделать, чтобы изолировать себя от административного хаоса в своих организациях, позволив людям, знающим правила игры, защитить остальных. Как хороший менеджер ограждает от внешнего давления и раздражителей команду разработчиков, чтобы она смогла сконцентрироваться, так и хороший администратор ограждает команду от паршивого администрирования.
Помните, что паковщики в организации не поймут описанные выше эффекты, поскольку они не признают существование такого подхода и состояния ума, с которым мы программируем. Это проблема офиса с открытой планировкой [когда все находятся в одном помещении – С.К.]!
Моделирование ситуаций
Эффективный способ поддержания совместно используемой мысленной карты проблемы, проекта и деятельности группы состоит в регулярном проведении моделирования ситуаций. Это короткие собрания, где один человек за десять минут излагает текущее понимание положения группы. Как и все остальное, это не ритуал, который необходимо выполнять неукоснительно как неизбежную часть работы, он имеет свое назначение. Это означает, что моделирование ситуаций стоит проводить даже если присутствуют не все члены команды, и, более того, его стоит начинать экспромтом, если уж собрались интересные люди.
Книга "Справочник рейнджера Слоана" (Sloane Ranger's Handbook) включает карту мира для рейнджеров Слоана. Около 50% всей карты занято Площадью Слоана, Шотландия соединена с Лондоном узенькой дорожкой M1, а континенты отодвинуты к краям карты. Шутка заключается в том, что у всех нас собственная искаженная карта мира, но карта рейнджеров уж очень сильно искажена по сравнению с географической. Для рейнджеров Слоана это не шутка – это правильное представление их мира, и они утверждают, что их представление не более нереальное, чем какое бы то ни было другое. (Некоторые из них купили книгу, чтобы иметь возможность проверить правильность. Она прошла проверку.)
Точно также, поскольку у нас всех есть своя собственная карта мира, у каждого из нас есть своя точка зрения на проблему и деятельность группы. Выявление различий точек зрения на проблему у разных людей дает больше преимуществ группе в целом, чем если бы просто позволить членам выверять свою точку зрения на своих картах меньшего размера и выявлять качественные и фактические отличия (что моделирование ситуаций тоже делает) в отдельных разговорах. Если взгляд на проблему с разных сторон приносит понимание, выслушивание того, как описывает прикладную программу занимающаяся связью команда, может дать прикладным программистам вещи, о которых они даже не догадывались со своей точки зрения.
Чтобы понять, почему полезно прерываться для моделирования ситуаций на несколько минут в день для общего собрания группы, очень полезно подумать о двух различных физических принципах работы систем хранения изображений. Традиционные фотопленки хранят разные части всего изображения в разных частях поверхности пленки. Соответствие между плоскостью изображения и плоскостью пленки прямое. Оторвите кусочек, и этот кусочек изображения пропадет. Голографические же пластинки хранят преобразование целого изображения в каждой части поверхности пластинки. Отломите кусочек, но изображение сохранится, хотя и понизится разрешение, поскольку кусочек содержал информацию о распределении определенных частотных компонентов изображения.
Команде не нужно концентрировать знание о предмете в отдельных личностях для исключения всего другого знания. Если делать так, то результат будет печальным, поскольку команда не сможет общаться внутри себя. Распределение знания по всей команде должно больше походить на голограмму, чем на фотографию. Я должен знать многое о своей работе и немного о вашей. То немногое, что я знаю должно быть правдивым и истинным, не важно, как бы причудливо я ни выражал это с вашей точки зрения. Тогда вы и я можем говорить друг с другом.
В моделировании ситуаций очень важно выдерживать строгий регламент (лимит времени), иначе вы безнадежно увязнете. Это означает, что у докладчика должно быть лишь несколько минут, чтобы кратко выразить Что На Самом Деле Произошло, оставляя вытекающие последствия за рамками. Это могут быть сравнения точек зрения, в которых члены команды не согласны с докладчиком, поиск возможностей упрощения, когда я узнаю, что я делаю на своем уровне такого, с чем вам приходится бороться на своем, либо получение знания от специалиста.
Также помните, что модель, где каждый имеет свою точку зрения – это групповая модель. Если в свете точки зрения кого-то обнаружился изъян в совместно используемой модели, то нападки на модель не означают нападки на человека, чей новый подход позволил обнаружить изъян, который вы не заметили со своей точки зрения.
Если группа освоится с подходом зететики, то из моделирования ситуаций можно извлечь дополнительные выгоды. Докладчика можно выбирать случайным образом. Это значит, что у каждого будет стимул регулярно прокручивать в своей голове весь проект, чтобы выглядеть элегантным и изобретательным, когда наступит его очередь рассказывать. Результат может быть потрясающим.
Когда последний раз вы делали работу, которая требовала от вас продумывания вашей работы, если вам требовалось писать отчеты о выполнении работы, заполнять многочисленные бланки и формы по контролю качества, заполняющие хранилище истории проекта?
Глава 4. Привычки и практика
Руководства по кодированию
Суть Тотального Управления Качеством (TQM) – в сознательности. Осознание того, что мы делаем, когда выполняем повторяющиеся процедуры или подобную работу, позволяет нам ухватить те редкие моменты озарения, когда мы видим способы сделать работу более эффективно и сообщаем о них нашим коллегам, изменяя наш процесс. Это означает, что определение процесса может содержать скучные вещи, необходимые для поддержания взаимодействия (связи) между группами, но стилистические или определяемые подходом моменты не должны быть великой ценностью, которую стоит передавать в таких документах. Идея этого аспекта процесса – не задавать каждую маленькую операцию, а сохранить знание. Это дает нам критерий, хотя и субъективный, определяющий, какие пункты стоит включать в документ. Например, микроспецификации упорядочивания заголовочных файлов не подходят для включения в стандарт кодирования, поскольку помимо прочего, ими почти всегда пренебрегают на каждой реальной платформе на этапе компиляции кода. Однако, метод использования макросов условной компиляции вокруг всего содержимого включаемого модуля для предотвращения многократного включения является маленьким сокровищем, которое нужно поместить там, где каждый его может увидеть и будет ему следовать.
На автозаводах сборочные цеха подвергаются постоянному совершенствованию, поскольку люди, делающие непродуктивную работу, осознают, что они непродуктивны, и исправляют это. Оригинальная параллель с программной инженерией должна заключаться в том, что руководства по кодированию должны совершенствовать процесс. Одно из наиболее дорогостоящих последствий барьера между картостроителями и паковщиками состоит в том, что паковщики, паникуя из-за "кризиса программного обеспечения", отстаивают утверждение, что "процесс" – это необъяснимый и мистический источник всего хорошего и, будучи таковым, он правильный. В некоторых организациях процесс становится механизмом принудительных попыток внедрить тупой роботизм паковщиков на всех рабочих местах, поскольку он кажется правильным состоянием ума на пути к магическому успеху.
Чтобы осознать масштабы проблемы, рассмотрим эволюцию языков программирования и моделей, средств разработки, инструментов CASE и так далее за последние тридцать лет. На самом деле нет никакого сравнения между концами этого интервала ни в чем, за исключением стандартов программирования. Некоторые аспекты структурного программирования, которые начал обсуждать Дейкстра (Djikstra), были превращены в ритуализированную догму, а затем эта догма перекочевывала из стандарта в стандарт и дошла до наших дней. Действительно, главная черта большинства стандартов кодирования, страстно пропагандируемых их сторонниками, состоит в том, что в них скопированы вещи, взятые откуда-то еще. Это история о том, как продать хлам запуганным и невежественным. Говоря, что угадал нечто, кому-то еще – хороший способ без всяких оснований добавить к чему-нибудь фальшивый источник. Стандарты кодирования создаются менеджерами для программистов, а не открываются во время кодирования и не передаются наверх. Такой оживленной и квалифицированной (если примитивно) дискуссии, которая вела к первоначальным стандартам кодирования, которые были великолепны для своего времени, с тех пор не повторялось. Как только был принят первый стандарт и были замечены улучшения, мир бизнеса паковщиков ухватился за них, обратил их в камень и объявил, что установлена "соответствующая процедура". Споры о стиле скатились до религиозных войн, не были повернуты лицом к потребностям развивающейся индустрии и потому были глупыми. Между тем, существование этой "соответствующей процедуры" неявно отвергало существование новых стилистических явлений, возникавших с появлением новых языков и моделей, которые нуждались в квалифицированных обсуждениях, каких же интенсивных, как обсуждения, развернувшиеся вокруг структурного программирования, для того, чтобы научиться использовать эти новые языки.
Программист, использующий среду разработки типа ParcWorks Smalltalk получает столько же преимуществ от ханжеских разглагольствований о неиспользовании goto и помещении данных, на которые никто не смотрит, в стандартных строках комментариев в начале файла, как и авиадиспетчер, прочитавший во Второзаконии о каре за секс с верблюдами.
Кто украл мою мышку?
Этот раздел посвящен сложности. Мы начнем с мысленного эксперимента, касающегося воображаемой марсианской экологии.
На Марсе (как все знают) есть скалы. Там есть также два вида живых существ. Это марсиане, которые едят мышей, и, что кстати для марсиан, есть мыши. Мыши скрываются среди скал и грызут их.
Мало что происходит на Марсе. В основном марсиане проводят свое время сидя в пустыне и выслеживая снующих между скал мышей. Поскольку скалы на Марсе повсюду, куда ни кинь взгляд, по всем направлениям, то марсианам нужно уметь хорошо видеть сразу во всех направлениях. Поэтому у марсиан характерные направленные в разные стороны четыре больших глаза, каждый на стебельке.
Мало что происходит на Марсе, поэтому эволюция марсиан полностью направлена на совершенствование обнаружения мышей. Сзади каждого огромного глаза расположена огромная мозговая корка, которая может обнаружить мышь за несколько миль в любое время суток (при любой освещенности). Большая часть мозга марсианина состоит из зрительной коры и эти четыре подмозга имеют многочисленные связи, чтобы компенсировать неблагоприятные условия освещенности. Марсиане интенсивно обрабатывают изображение ландшафта в полуавтономных подмозгах, поэтому им на самом деле не требуется "внимание", как людям – вместо этого они сосредоточены на переключении входов между своими "вниманиями".
Обнаружив мышку, марсианин должен подкрасться к ней. Это означает, что нужно преодолеть скалы. Это требует Разума. Вскоре после обретения Разума марсиане изобрели Великую Литературу. Ее выбивали на больших скалах с помощью каменных обломков. Она подчиняется правилам марсианской грамматики и использует Северный голос для эмоций, Южный голос для действия, Восточный голос для речи и Западный голос для обстоятельств. Мало что происходит на Марсе, поэтому наиболее близкий марсианский эквивалент нашего "Преступления и наказания" называется "Кто украл мою мышь?":
Emotion Action Speech Circumstance Grumpy 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, где мы все его предполагаем и ищем его.
Нет абсолютной меры "сложности". Это должно родиться в мозгу, в обсуждениях сложности алгоритмов и стиля кодирования и того, что выдают средства анализа сложности после графического представления системы, которое может оказаться очень полезным. Сложность в этих картинках (после того как систему упростили до необходимой достаточности) не есть Плохая Вещь – это существо лежащей перед вами проблемы. Нам не следует пытаться избегать внутренней (присущей) сложности проблем. Это бесполезная стратегия, которая уводит нас от достижения абстрактного понимания, которое позволит нам упорядочить сложность.
