Джим Уолдо - системный дизайн Sun Microsystems, Inc 1 сетевой диск Берлингтон, Массачусетс 01803 1 781 442 0497 jim.waldo@sun.com Аннотация В этом эссе я рассматриваю некоторые из факторов, которые делают все более трудным затрачивать усилия, необходимые для проектирования системы. Из-за изменений в области экономики, как в промышленности, так и в исследованиях, мы стали менее способными тратить время, необходимое для создания реального проекта системы и обучения проектировщиков следующего поколения. Из-за ландшафта интеллектуальной собственности мы не можем обсуждать проектирование системы. Конечным результатом является то, что мы делаем менее хороший дизайн системы, чем раньше, по крайней мере в тех средах, где проектирование системы было наиболее распространенным. Но есть причины для оптимизма в отношении будущего системного проектирования, которое, по-видимому, происходит нетрадиционными способами и в нетрадиционных местах. В частности, одна из интерпретаций популярности как гибких методов, так и проектов с открытым исходным кодом заключается в том, что они дают участникам места, где они могут изучить мастерство проектирования систем. 1. Введение Я начинаю верить, что искусство и ремесло системного дизайна находятся под угрозой потери. Тщательно спроектированные системы, в которых правильные абстракции правильно сочетаются для создания системы, которая проста в освоении, легко изменяется и приятна для использования и работы, вряд ли произойдет с использованием тех методов проектирования, которые популярный сегодня. Мы используем не только методы, которые мешают нам проектировать системы. Мы не можем должным образом подготовить инженеров и ученых к проектированию систем. Экономика отрасли подталкивает нас в направлениях, которые не благоприятствуют дизайну. Реальность финансирования исследований делает маловероятным, чтобы много времени было потрачено на разработку системы. Конечным результатом является то, что ведется менее тщательная работа по проектированию, и мы, как отрасль, профессия и интеллектуальная дисциплина, похоже, не заботимся и не можем с этим поделать. В дальнейшем я попытаюсь описать и объяснить некоторые из этих факторов и попытаться прояснить цену, которую отрасль и дисциплина могут заплатить из-за этих факторов. Я начну с попытки охарактеризовать, что мы подразумеваем под системным дизайном. Что касается характеристики, которую я дам, все программные артефакты, кроме самых тривиальных, имеют дизайн, но только некоторые из них получили этот дизайн сознательно. Затем я перейду к тому, как изучается проектирование системы, и с учетом того, что в качестве основы я буду смотреть на изменения как в промышленности, так и в академических кругах, которые усложнили процесс преподавания или даже разумного подхода к проектированию системы. Я начинаю верить, что искусство и ремесло системного дизайна находятся под угрозой потери. Неспособность сделать или изучить системный дизайн в этих традиционных местах привела к появлению новых областей, где инженеры и ученые могут практиковать и совершенствовать свои навыки в этой области. Я закончу эссе обсуждением некоторых из этих областей, поскольку они дают надежду, что хороший дизайн системы будет и впредь частью того, чему мы учим, учимся и практикуем. 2. Что такое системный дизайн? Одной из самых интересных и самых сложных задач, которые мы можем выполнять в своей карьере в качестве инженеров или компьютерных специалистов, является проектирование всей системы. Система - это набор взаимодействующих частей, обычно слишком больших, чтобы их мог создать один человек, созданный для какой-то конкретной цели. Мы работаем с системами постоянно. Операционные системы, которые управляют нашими машинами, являются системами. Уровни аппаратного и программного обеспечения, которые позволяют программам на этих машинах взаимодействовать друг с другом по сети, являются системами. Даже большинство приложений, которые мы используем, являются системами, независимо от того, знаем мы это или нет. Как инженеры, мы знаем, что способ решения большой проблемы состоит в том, чтобы разбить ее на ряд взаимодействующих мелких проблем. Каждая из этих более мелких проблем может быть разложена на еще более мелкие проблемы, пока после достаточного количества итераций у нас не возникнет проблема, которую можно решить самостоятельно. Каждая декомпозиция дает нам набор компонентов, и решение о том, что это за компоненты и как они сочетаются друг с другом, является задачей проектирования системы. Все разумное программное обеспечение является системой, которая имеет дизайн по этой характеристике. Программное обеспечение будет организовано вокруг методов, процедур или функций или любой другой абстракции для такого рода декомпозиции, поддерживаемой используемым языком. Каждый из этих методов будет представлять декомпозицию и абстракцию проблемы, которая должна быть решена для запуска программного обеспечения. Чем больше объем программного обеспечения, тем больше слоев в дизайне и тем сложнее система. Но сказать, что все программное обеспечение имеет дизайн, не означает, что все программное обеспечение разработано. Проектирование системы требует, чтобы кто-то подумал о правильном способе декомпозиции функциональности и о том, как создать небольшой набор абстракций, которые можно повторно использовать и объединять для обеспечения необходимой функциональности. Представление о том, что все, что показывает какой-то дизайн, является, следовательно, результатом некоторой сознательной деятельности дизайна, является путаницей, основанной на неоднозначности в термине «дизайн». В одном смысле этого слова дизайн - это свойство некоторого объекта. такие как программа, система или тому подобное, которые просто указывают, что есть части, которые взаимодействуют. В другом смысле слова дизайн указывает на деятельность по определению, какими должны быть части некоторого большего целого и как эти части будут совмещаться. Хотя все, что является результатом деятельности дизайна, само по себе будет иметь дизайн, из этого не следует, что все, что имеет свойство дизайна, является, следовательно, результатом деятельности дизайна. Одним из лучших признаков того, что программа является результатом деятельности дизайна, является наличие документа, который описывает этот дизайн, особенно если документ был написан до программы. Но слишком часто мы должны открывать дизайн, проверяя код. Иногда обнаруженный дизайн показывает все отличительные признаки продуманной дизайнерской деятельности, но в других случаях обнаруженный дизайн показывает случайную комбинацию различных абстракций, дублирование функциональности в несколько различных формах и несоответствия в способе, которым абстракции были выбран, реализован и используется. Такие обнаруженные проекты показывают либо отсутствие какой-либо деятельности по проектированию до создания программы, либо то, что действия по проектированию действительно имели место до написания программы, прямо скажем, не очень хорошо. Я не знаю адекватного набора необходимых и достаточных условий для определения, хорош дизайн или нет, но, как и многие другие вещи, связанные со вкусом и эстетикой, мы обычно знаем хороший и плохой дизайн, когда видим его. Операционная система Unix® обладает простотой и симметрией, что свидетельствует о хорошем дизайне; язык программирования сопутствующего Си обладает сочетанием мощи и краткости, которые отражают и дополняют архитектуру PDP-11, для которой он изначально был предназначен. Дизайн системы может меняться и развиваться с течением времени. Оригинальный язык программирования Javatm и связанные с ним библиотеки имели простой и последовательный дизайн. Некоторые из дополнений к библиотекам, связанным со средой с момента ее появления, отражают оригинальный дизайн, а другие ввели другие понятия дизайна. Общая система превратилась в нечто, что в определенной области имеет согласованный дизайн, но в целом гораздо менее унифицировано, чем когда-то было. Более радикальный пример изменения дизайна с течением времени виден в наборах протоколов и языков, определяющих World Wide Web; когда они были впервые представлены, они были просты и имели понятный дизайн. Но коллекция образцов, которые были предложены или которые стали общепринятыми стандартами в последнее десятилетие, не показывают такой последовательности или простоты. Можно сказать, что отдельные их коллекции образуют спроектированную систему, но амальгама, которая формирует общую платформу, - нет. Некоторые из этих примеров хорошего дизайна были продуманы достаточно подробно до того, как были созданы системы. Другие развивались с внедрением самой системы. Но во всех случаях хорошего дизайна, есть довольно простой набор принципов, которые лежат в основе дизайна. В случае Unix идея файла и способность любой программы принимать поток ASCII в качестве входных данных и создавать такой поток в качестве выходных данных, позволяли тем, кто изучает систему, знать, чего ожидать, когда они сталкиваются с новыми частями системы. Бывают моменты, когда дизайн системы, даже когда она является примером хорошего дизайна, нужно будет подталкивать и подталкивать неестественными способами, чтобы получить что-то, что оригинальный дизайн не принял во внимание. В Unix было большим упрощением рассматривать все файлы как потоки ASCII, но введение магических чисел, различных типов заголовков и соглашений, связанных с расширением имени файла, показывает желание наложения типизированной файловой системы в такой системе. , Учитывая мою характеристику системного дизайна, я действительно должен вновь заявить о своей озабоченности по этому вопросу. Поскольку любая система будет иметь дизайн, говорить, что дизайн системы вымирает, было бы то же самое, что говорить, что разработка программного обеспечения вымирает. Это явно не тот случай. Производится все больше программного обеспечения, поэтому появляется все больше систем. Что меня беспокоит, так это упадок спроектированных систем, в том смысле, что существует какой-то согласованный план для системы, к которому приходят люди, работающие над ней, способом, отличным от простого наблюдения за падением кода. вне. Возможно, лучшая характеристика моего беспокойства заключается в том, что процесс разработки системы происходит все реже и реже, и в результате проектирование систем, которые мы производим, становится все более и более случайным, и в результате конструкции становятся все менее и менее последовательными, просто и эстетично. Похоже, мы производим программное обеспечение, в котором общий дизайн можно определить только после факта, взглянув на созданный код. Является ли воспринимаемое отсутствие проектирования систем хорошим или плохим, это то, что мы, как отрасль и как интеллектуальная дисциплина, должны понимать. Я думаю, что изменение конструкции систем вызвано рядом факторов. По отдельности они не могут быть проблемой; вместе они меняют способ создания систем. Частично это связано с образованием; расстаться, если это связано с экономикой; Отчасти это связано с текущими причудами или модами в том, как мы пишем программное обеспечение. В дальнейшем я рассмотрю каждый из этих факторов по очереди. Давайте начнем с некоторых мыслей об образовании. 3. ОБУЧЕНИЕ В СИСТЕМЕ ДИЗАЙНА Как и большинство других промышленных исследовательских лабораторий, Sun Labs летом собирает группы стажеров для работы над различными проектами. Это примерно такая же классическая беспроигрышная ситуация, какую можно найти в бизнесе. Большинство стажеров являются аспирантами, некоторые из них - студенты, а иногда и учащиеся старших классов. Стажеры находят летнюю работу в своей сфере интересов. Лаборатория получает укол энтузиазма, который трудно воспроизвести. Студенты думают, что им переплачивают, а мы получаем то, что считаем дешевой рабочей силой. Студенты не знают, что нельзя сделать, и поэтому часто делают, казалось бы, невозможное. Лучше всего то, что стажеры узнают, что такое «реальный мир» 3. Прошлым летом, возвращаясь с обеда примерно на неделю к своей должности, стажер, работавший в моей группе, повернулся ко мне и спросил: «Итак, как вы относитесь к обучению проектированию системы?» уровень наивности, который захватывал дух. Единственный короткий ответ, который я мог дать, был, по сути, то, что вы научились проектировать систему, проектируя системы и выясняя, что работает, а что нет. С тех пор я думал о длинном ответе; Я не уверен, что длинный ответ отличается от короткого ответа гораздо больше, чем длина, но, тем не менее, вот что я придумала. 3.1 Происхождение хорошего дизайна Прежде чем узнать, как обучить кого-то дизайну системы, полезно иметь представление о происхождении хорошего дизайна. Если мы можем знать, что приводит к хорошему дизайну, мы можем попытаться научить людей делать такие вещи в надежде, что хороший дизайн приведет к этому. Там нет недостатка в книгах, семинарах и других учебных пособий, которые утверждают, что помочь в этом квесте. Есть такие методы, как Six Sigma, которые помогают в разработке хорошего дизайна. Есть языки, такие как UML, которые утверждают, что помогают в разработке хорошего дизайна. И нет конца методологиям и процессам, которые утверждают, что позволяют любой команде создать хороший дизайн, который будет удовлетворять потребности клиента, просто повторяя применение правил, составляющих методологию. «Итак, как вы научитесь проектировать систему?» Как и большинство замечательных вопросов, это показало уровень наивности, который захватывал дух. Единственный короткий ответ, который я мог дать, был, по сути, то, что вы научились проектировать систему, проектируя системы и выясняя, что работает, а что нет. Я не сомневаюсь, что истории успеха, на которые ссылается каждый из этих подходов и пособий, являются правдой. В некотором смысле, это просто проблема; полностью несовместимые и противоречивые подходы к проблеме проектирования, как было показано, были дико успешными их сторонниками и дико неудачными сторонниками конкурирующих подходов. Снизу вверх или сверху вниз, водопад или крайний; кажется, что все работают для одних, а не для других. Единственное общеприменимое правило, которое не имеет явных контрпримеров, - это то, которое я впервые услышал, озвученное Фредом Бруксом более десятка лет назад. В своем выступлении на внутреннем семинаре Солнца (расширенная версия которого стала основой для его лекции по премии Тьюринга в 2000 году [3]), Брукс рассказал о работе, которую он делал, чтобы попытаться найти основную общую черту добра дизайн не только в компьютерном оборудовании и программном обеспечении, но и в таких областях, как архитектура, графика и изобразительное искусство. Единственное, что он мог найти, что общего у хороших дизайнов было то, что они были сделаны хорошими дизайнерами. Существует одно прочтение этого понимания, которое является правдивым, но неинтересным, простое тавтологическое утверждение, отражающее непредсказуемую и непостижимую тайну дизайна. В этом чтении единственный способ определить, что дает хороший дизайн, - это подождать, пока он у вас есть, и затем приписать его дизайнеру. Хороший дизайн, с этой точки зрения, происходит случайно. Вы можете на это надеяться, но ничего не можете сделать, чтобы повысить свои шансы на хороший дизайн. Это не чтение, которое, как мне кажется, Брукс намеревался, ни то, которое я нашел убедительным, когда впервые услышал речь. Мое прочтение этого принципа заключается в том, что те, кто смог создать хороший дизайн в прошлом, с большей вероятностью смогут создать хороший дизайн в будущем. Нет никаких гарантий, что будущие проекты будут хорошими, но ваши шансы намного лучше. Не существует волшебного процесса, с помощью которого такие дизайнеры создают свои проекты; каждый может по-разному подходить к проблеме дизайна, и дизайнер может подходить к одной проблеме определенным образом, а другой - совершенно по-другому. Суть в том, что хороший дизайн - это способность, которой обладают некоторые люди, а другие просто нет. Является ли это врожденным навыком, с которым люди рождаются, или тем, который совершенствуется с течением времени способами, которые мы не понимаем, - вопрос, который я слишком глубоко для того, чтобы рассмотреть здесь. Я не знаю и не беспокоюсь. Но к тому времени, когда кто-то разрабатывает компьютерную систему, все, что нужно для того, чтобы стать хорошим дизайнером, уже есть или нет. Когда оно есть, его можно развивать и оттачивать. Это может также быть ухудшено или искажено. Но когда его нет, нет техники или процесса, который может восполнить дефицит. Некоторым людям не нравится эта идея. Многие из них являются менеджерами; Я буду обсуждать их дискомфорт позже. Другие неудобны по более философским причинам; они чувствуют, что высказывание о том, что есть те, кто может создавать хорошие замыслы, и те, кто не может, противоречит некоему эгалитарному представлению (что это такое) и каким-то образом элитарным или недемократичным (что, я думаю, нет). Почему мы должны быть удивлены, обнаружив, что есть люди, которые просто не способны заниматься первоклассным проектированием систем? Такие проекты сложны, сложны и требуют большого вкуса, чтобы получить право. Кроме того, они требуют способности иметь дело с большой неопределенностью при формировании дизайна, способности решать целые наборы вопросов, которые дизайнер не может решить, но которые он или она знает или верит в то, что они будут решены. в соответствующее время. Учитывая сложность всех этих задач, не более удивительно, что не каждый может быть великим дизайнером, чем то, что не каждый может быть великим композитором, или великим художником, или великим архитектором, что не случайно все области это своего рода дизайн. Нельзя сказать, что дизайнеры - лучшие люди, чем те, кто не являются великими дизайнерами; действительно, дизайнеры - хорошие или плохие люди примерно в той же пропорции, что и любая другая группа. Но стоит сказать, что некоторые люди являются лучшими дизайнерами, чем другие, и игнорирование этого является одной из многих вещей, которые приводят к плохому проектированию системы. 3.2 Обучение деланием Сказав все это, вопрос о том, как научить проектирование системы, остается открытым. Тот факт, что хороший дизайн исходит от хороших дизайнеров, не говорит нам, откуда берутся хорошие дизайнеры. Хотя это может быть правдой, что не каждый может быть хорошим дизайнером, также верно, что есть некоторое обучение, которое продолжается. Мне вспоминаются плакаты, которые я видел несколько лет назад в Школе дизайна в Род-Айленде, плакаты с заголовком «Талант без техники - пустая трата времени». Школа не претендует на то, чтобы сделать кого-либо художником. Но они утверждают, что могут взять кого-то с талантом стать художником и дать ему технику, которая позволит им использовать и направить этот талант. То же самое верно в проектировании системы; может случиться так, что у вас должен быть какой-то талант, чтобы хорошо выполнять задание по проектированию, но также верно и то, что вам необходимо изучить технику, которая позволяет вам направлять и усиливать этот талант. В моем собственном случае инструкция, которую я получил по проектированию системы, пришла в форме обучения у главного дизайнера. Это не было формальным соглашением, и вполне может быть, что человек, которого я считал учеником, не видел наши отношения ни в чем подобном этим терминам. Но, оглядываясь назад, я ясно вижу это таким образом. Более структурированные и корпоративные отношения были связаны с общим архитектором программного обеспечения для основного компонента системы и отдельным участником этой системы. Группа, в которой я находился, отвечала за систему управления окнами и за все видимые для пользователя инструменты для компании Apollo Computer, которая ранее работала на рабочих станциях. Архитектор группы реализовал первую версию этих компонентов самостоятельно, но, как это часто бывает, были разработаны более масштабные планы для второй системы, и небольшая группа была собрана для разработки и реализации. Я был нанят для разработки и реализации библиотеки компонентов, которая будет работать с текстом; были другие, которые имели дело с системой управления окнами, механизмами ввода, интерпретатором оболочки и даже языком сценариев. Общий процесс проектирования для группы потребовал, чтобы владелец каждого компонента написал серию спецификаций для своего компонента. Первым из них был соломенный человек, предназначенный для быстрого наброска различных частей и общей модели компонентов. Последним был железный человек, подробное описание всех точек входа и их функциональности. Раз в месяц вся группа уходила с места, обычно в квартиру менеджера группы, на утро, чтобы рассмотреть одну из спецификаций для какого-либо компонента. Тот факт, что хороший дизайн исходит от хороших дизайнеров, не говорит нам, откуда берутся хорошие дизайнеры. Общий архитектор группы не был одним из наиболее активных участников этих обсуждений. Но когда он говорил, все остальные слушали. Его самая изумительная критика была простой: «Это слишком сложно». Когда говорилось о спецификации, это указывало на то, что вы не выполнили работу, чтобы в достаточной степени понять проблему и свести ее к какому-то простому ядру. Предполагалось, что всегда было какое-то простое ядро, и, сделав предположение, такое ядро ​​обычно находили. Эти обзоры дизайна и постоянное взаимодействие как с архитектором, так и с другими членами группы в течение многолетнего периода времени были тем местом, где оттачивались мои навыки проектирования систем. Именно здесь я узнал о простоте и симметрии, об интерфейсах и проектировании для изменений, а также о множестве других правил и методов, которые я до сих пор использую. Что еще более важно, я узнал, что работает для меня, а что нет, и что то, что работает для меня, может не работать для других. Вместо того, чтобы изучать процесс проектирования, я узнал, как лучше всего проектировать. Первоначально я думал, что этот способ обучения дизайну необычен и является результатом моего академического образования в области, не связанной с информатикой. Но когда я узнал больше и начал общаться с другими людьми, которых я считал хорошими в проектировании систем, я обнаружил, что этот опыт был больше, чем просто обычным явлением; это было почти универсально. У каждого, с кем я разговаривал, была похожая история о главном дизайнере, который сознательно или на собственном примере и с исправлением учил его или ее тому, что они считали важными уроками дизайна. Был период, когда я спрашивал: «С кем вы проходили свое дизайнерское обучение?», Не предоставляя никакого другого контекста. Я ожидал, что некоторые будут смущены этим вопросом, но я обнаружил, что все, кому я задавал вопрос, не только поняли его, но и смогли ответить, не задумываясь. Еще интереснее то, что имена, которые были даны, часто были одинаковыми. Знали ли они это или нет, сравнительно небольшому числу мастеров было поручено обучить гораздо большее число разработчиков систем. Дизайн, если судить по моему опыту, лучше всего усваивается долгим и разнообразным процессом попыток, неудач и повторных попыток под руководством кого-то, кто является экспертом в этой задаче. Вряд ли это был научный обзор, и, как ученые, мы должны позаботиться о том, чтобы сделать убедительные выводы из неофициальных данных. Но я думаю, что это свидетельствует о том, что никто из тех, с кем я говорил, о том, как они проектируют и как они научились проектировать, не указал на класс, который они выбрали, который обучил их любым важным аспектам. Дизайн, если судить по моему опыту, лучше всего усваивается долгим и разнообразным процессом попыток, неудач и повторных попыток под руководством кого-то, кто является экспертом в этой задаче. 3.3 Дизайн и Учебный план То, что никто не изучает проектирование системы из какого-то курса, может вызывать беспокойство. Если проектирование систем действительно является трудной частью того, что мы, инженеры и компьютерные ученые, делаем, не нужен ли нам какой-то систематизированный способ обучения тому, что необходимо для такого дизайна? В Интернете можно найти несколько курсов по системному дизайну, которые преподаются в различных университетах, а также множество курсов, предлагаемых консалтинговыми компаниями. У меня больше, чем просто мимолетный интерес к курсу по системному проектированию по ряду причин, и не в последнюю очередь это то, что я обдумывал преподавать такой курс. Это тот тип курса, который просят студенты; было бы полезно, если бы учащиеся, пришедшие в индустрию, действительно обладали некоторыми навыками проектирования систем; и было бы интересно разработать учебный план и чтения для такого курса. У меня были большие трудности в получении чего-либо вроде набора чтений или согласованного плана для такого класса. Есть некоторые очевидные чтения: Лэмпсон [6] и Брукс [2], а также множество вещей Парнаса [4]. Но мне никогда не удавалось определить понятия, которым нужно учить, и последовательность, в которой эти понятия должны быть представлены. После значительного времени попыток и неудачных попыток прийти к какому-то плану, я понял, что я думаю об этой проблеме неправильно. Более полувека назад философ Гилберт Райл проводил различие между знанием как и знанием этого [8]. Знание, что это отношение между человеком и суждением; это фактическое знание, которое может быть обнаружено, может быть оправдано и может преподаваться с помощью обычных механизмов педагогики. Знать, как это разные вещи; это то знание, которое мы имеем, когда знаем, как ходить, бегать или петь. Это не фактическое знание, а способность, которую мы проявляем в своих действиях. Мы можем знать, как сделать что-то достаточно хорошо или умело. Мы не можем знать, что мир вокруг достаточно хорошо или искусно. Самое важное, что, хотя нас могут научить делать что-то, тип обучения, который имеет место, сильно отличается от вида обучения, необходимого для этого. Академические дисциплины требуют сочетания знания как и знания этого. Чтобы получить полное образование в любой из этих дисциплин, безусловно, необходимо понимать фактические основы этой дисциплины. Но чтобы быть по-настоящему образованным в этой области, необходимо также научиться мыслить особым образом. Каждое поле имеет свою собственную технику или набор техник, которые должны быть изучены так же, как предмет области, если вы действительно хотите быть экспертом в этой области. Академические дисциплины требуют сочетания знания как и знания этого. Различные поля имеют разные комбинации предмета, который требует знания этого, и техники, которая требует знания как. Подавляющее большинство моих формальных занятий было в области философии. Как практикуется в Соединенных Штатах и ​​Англии, то, что иногда называют «англо-американским» или аналитическим подходом к философии, область почти полностью является техникой. Конечно, есть много контента, связанного с историей философии и великими философскими вопросами. Но что действительно важно, так это то, как человек думает, имея дело с концептуальным анализом, построением логических моделей и подходов к аргументации. Хотя очень мало предмета философии был полезен для меня, когда я стал инженером-программистом, я обнаружил, что методы, которые я изучил, столь же актуальны в информатике, как и в той области, в которой я их изучал. Те, кто посещал юридический факультет, говорят мне, что это почти то же самое: приобретение техники или умение мыслить как юрист гораздо важнее, чем реальный предмет права. можно сдать экзамен на адвоката для конкретного штата, проверяя знание предмета закона для этого штата, прежде чем можно будет заниматься юридической практикой. Но знание закона без знания техники не делает юриста адвокатом. Есть и другие предметы, где есть гораздо больше предметов для освоения наряду с техникой. При изучении геологии вам все равно нужно учиться мыслить как геолог, но есть также много предметов, которые необходимо освоить. По этим предметам обучение технике часто является побочным продуктом изучения предмета или, по крайней мере, побочным продуктом педагогики, используемой при обучении предмету. Курсы организованы вокруг кусков предмета, а не вокруг техники. Хорошо продуманная программа будет использовать методику на местах во всех курсах для этой области и использовать изучение предмета в качестве предлога для обучения студентов технике. Курсы, которые пытаются преподавать только технику, имеют тенденцию быть несколько неудачными; в лучшем случае они могут предоставить студентам форум для демонстрации уже освоенной техники. Я полагаю, что академическая дисциплина информатики не очень хорошо справилась с распознаванием различия между техникой и предметом. В то время как есть несколько примеров, в которых методика достаточно хорошо описана (недавняя статья Джинетт Винг [10] проделала большую работу по описанию того, что значит думать как ученый-компьютерщик), казалось бы, непрерывное обсуждение того, что такое учебная программа специализация в области компьютерных наук (см., например, [1]), по-видимому, путает методы, которые мы должны привить, с предметом, который нам нужно преподавать. Мой собственный вывод заключается в том, что проектирование системы на самом деле является вопросом техники, способа мышления, а не предмета, который можно преподавать в определенном курсе. Может быть возможно создать программу, которая обучает системному проектированию, проводя студентов через ряд курсов, которые оттачивают их навыки системного проектирования, поскольку они перемещаются по предмету курсов. Такая серия курсов, по сути, была бы формализованной версией ученичества, которая теперь является способом, которым люди приобретают свою технику проектирования системы. Могут даже быть кафедры информатики, которые имеют именно такую ​​серию курсов. Если так, я не знаю о них. Они, конечно, не будут найдены, если будут искать школы, которые преподают курс по системному дизайну; Все их курсы будут иметь в качестве подтекст системы дизайна. Я думаю, что гораздо более вероятно, что факультеты компьютерных наук преподают проектирование систем во многом так же, как я изучал проектирование систем, - что есть некоторые профессора, которые работают мастерами в этой области для группы студентов, которые обучаются у этих профессоров. Эти студенты будут проходить любой курс, преподаваемый профессором, независимо от предмета и обучения на практике. Но такая тренировка в лучшем случае случайна; часто студентам не рекомендуется брать слишком много курсов у одного преподавателя, что снижает вероятность возникновения такой методики обучения. Что было бы лучше всего, так это ситуация, когда весь факультет осознавал необходимость обучения методике проектирования, и все курсы от любого из инструкторов имели в качестве общепризнанной цели обучение такой технике. Такие учебные планы возможны в других областях проектирования, но их сложно разработать и еще сложнее оценить. До тех пор, пока мы, как дисциплина, не найдем способ сделать такой вид разработки и оценки учебных планов, проектирование системы будет продолжать изучаться как ремесло, через ученичество и за пределами обычных академических каналов. Возможно, это все, чего мы можем ожидать, но во времена оптимизма я думаю, что мы, как поле, могли бы добиться большего. Возможно, нам стоит обратить внимание не на инженерию, а на студийное искусство, чтобы найти руководство по такой учебной программе. Используемый подход заключается в том, что учащиеся выполняют множество дизайнерских проектов различной степени сложности и размера и постоянно подвергаются критике своей работы, как со стороны своих сверстников, так и преподавателей. Эти студенты также видят, как критикуют работу их сверстников, что является еще одним способом изучения дизайна. Это гораздо больше работы, как для студентов, так и для учителей, но, похоже, оказывает некоторое положительное влияние на развитие техники в области, где учат элегантности и вкусу. Я сомневаюсь, что мы могли бы поступить хуже, чем сейчас, если бы мы, как дисциплина, попробовали такой подход. 3.4 Интеллектуальный генофонд Прежде чем перейти к другим темам, есть одна побочная поездка, которую я считаю нужным предпринять, когда речь идет о разработке систем обучения. Это связано с тем, что я считаю неудачным сужением интеллектуального генофонда в нашей области. До тех пор, пока мы, как дисциплина, не найдем способ разработки и оценки такого рода учебных планов, проектирование системы будет продолжать изучаться как ремесло, через ученичество и за пределами обычных академических каналов. Когда я впервые начал писать программное обеспечение, индустрия росла так быстро, и академическая область была настолько новой, что у инженеров-программистов было гораздо больше рабочих мест, чем было кандидатов со степенями в этой области. В результате, много разных фонов были представлены почти в каждой группе разработки программного обеспечения. Например, в группе, в которой я проходил обучение, академическое образование включало в себя степень доктора философии. кандидат физико-математических наук в философии (я), инженер, который выполнил дипломную работу в области психологии, другой, чей опыт работы в антропологии, и два музыканта, а также два инженера, которые имели ученые степени в области компьютерных наук, и один, который вообще не имел никакого образования. В результате всего этого разнообразия фона, было много разных точек зрения на любую проблему, и множество способов взглянуть на любую задачу. Конечным результатом стала одна из самых интересных и инновационных групп, в которой я когда-либо был. Что меня огорчает, так это то, что я очень сомневаюсь в том, что кто-либо из членов этой группы, изучавших что-то кроме компьютерных наук, мог бы получить свою первую работу в качестве инженера-программиста сегодня. Академия всегда настаивала на надлежащих полномочиях в соответствующей области. Это неудивительно, учитывая, что они существуют для выдачи таких учетных данных. Но в настоящее время промышленность требует, чтобы те, кто занимал должность инженера-программиста, прошли обучение в этой области. В результате кандидаты, поступающие на эту профессию, гораздо более однородны в том, как они думают, и в том, как они подходят к проблемам. Много раз им говорили, как правильно решить проблему, и поэтому они просто решают ее таким образом. Системный дизайн - это не то, что может быть рассмотрено в классе, но изучается через гораздо более длительный процесс, который больше похож на ученичество, чем что-либо еще. Такое обучение не является той вещью, которую наша образовательная система настроила для обеспечения (по крайней мере, на уровне бакалавриата), и не будет обеспечено некоторыми изменениями в наборе курсов, составляющих учебную программу. Если бы мы действительно знали, что такое думать, как ученый-компьютерщик или инженер-программист, и знали, как научить людей мыслить таким образом, это не могло бы быть проблемой. Если бы мы на самом деле знали ответы на большинство вопросов, возникающих при производстве программного обеспечения, то получение людей, которые уже знают эти ответы, было бы способом сделать отрасль более эффективной. Но, как я уже говорил в предыдущем разделе, я не думаю, что мы очень хороши в обучении тому, как думать, как ученый-компьютерщик или, по крайней мере, как системный разработчик. Я также не думаю, что у нас есть адекватные решения для многих проблем, связанных с проектированием системы в частности и разработкой программного обеспечения в целом. Мы, безусловно, можем получить более немедленную отдачу от наших инвестиций, наняв только тех студентов, которые имеют ученую степень в области компьютерных наук или смежных областей. Но я боюсь, что мы ограничиваем наш генетический запас идей преждевременно, и в результате дисциплина для этого беднее. 3.5 Образование и системный дизайн Если приведенные выше наблюдения верны, то неудивительно, что проектирование системы является необычным, а хороший дизайн системы - еще более. Хороший дизайн системы требует не только таланта, но и обучения, которое обеспечивает необходимую технику, чтобы соответствовать этому таланту. Системный дизайн - это не то, что может быть рассмотрено в классе, но изучается через гораздо более длительный процесс, который больше похож на ученичество, чем что-либо еще. Такое обучение не является той вещью, которую наша образовательная система настроила для обеспечения, по крайней мере, на уровне бакалавриата, и не будет обеспечиваться некоторыми изменениями в наборе курсов, составляющих учебную программу. Фактически, большинство тех, кто занимается системным проектированием, изучали свое мастерство после того, как они закончили формальное обучение в классе, либо на работе, либо во время исследования диссертации. Но изменения в экономике финансирования исследований и индустрии программного обеспечения сговорились против видов обучения, которые приводят к хорошему проектированию системы. 4. ГДЕ ПРОЕКТИРУЕТСЯ СИСТЕМА Если проектирование системы фактически изучается как часть ученичества, есть два места, где мы должны ожидать такого обучения. Первый - в аспирантуре, где студент может работать с одним преподавателем, его или ее консультантом, который выступает в качестве мастера. Другой - на рабочем месте, изучая искусство проектирования систем, выполняя такой дизайн. Но различные формы давления сделали этот вид обучения все труднее и труднее получить, потому что реальное проектирование все реже или в академических исследованиях или в промышленности. Вместо этого академические исследования стали гораздо более эволюционной задачей, изменением, которое стало непреднамеренным следствием решений финансирующих учреждений, направленных на снижение риска. В то же время проектирование промышленных систем стало более ограниченным, более дорогим и менее рискованным. Результатом обоих явилось не только снижение способности обучать проектированию систем, но и среда, в которой многие неправильные вещи учат тому, как выполнять эту задачу. 4.1 Проектирование промышленной системы Возможно, нас не должно удивлять то, что в промышленности меньше возможностей изучать проектирование систем, если только по той причине, что нужно разрабатывать меньше систем, чем десять или двадцать лет назад. Консолидация и зрелость отрасли изменили необходимость проектирования системы и, следовательно, возможность изучения такого дизайна. Двадцать лет назад было гораздо больше компаний, создающих компьютерные системы, чем сегодня. Кроме того, эти компании конкурировали не только по цене, но и по функциональности, стабильности и изощренности всей системы, которая была собственностью компании. У каждой компьютерной компании были свои микросхемы, собственное оборудование, своя операционная система и собственный язык программирования. Действительно, у IBM было три или четыре каждого. Кроме того, клиентам, покупающим эти системы, потребуется специальное программное обеспечение, выходящее за рамки базовой компьютерной системы, поэтому в разработке этого программного обеспечения была процветающая отрасль. Все эти проекты требовали системного проектирования, поэтому было много шансов попытаться спроектировать систему, и много шансов научиться либо правильно, либо неправильно. На таких конференциях, как USENIX, OOPSLA, HotOS и т. Д., Также происходил интенсивный обмен идеями дизайна. Текущие тенденции в отрасли очень разные. Там, где раньше было много компьютерных компаний, сейчас гораздо меньше. Количество операционных систем было уменьшено до двух, с выбором Windows или одним из вариантов Unix. Клиенты почти никогда не покупают нестандартные программные системы, созданные с нуля на основе спецификаций, выработанных в ходе дискуссий между разработчиками программного обеспечения и самими заказчиками. Вместо этого большинство пользовательских программ написано для обеспечения возможности подключения существующих систем или продолжения этих систем на новом оборудовании или в новых средах. Производство такого рода программного обеспечения происходит не из небольших компаний, которые специализируются на разработке систем, а скорее из консалтинговых услуг существующих компаний или специализированных консалтинговых компаний, и, как правило, ограничивается существующими средами таким образом, чтобы свобода проектирования Создатель программного обеспечения жестко ограничен. Много усилий было уделено поиску способов создания этих пользовательских систем, которые были бы более эффективными и отзывчивыми для клиента. Такие методы, как экстремальное программирование, в которых небольшие изменения вносятся в систему с постоянной обратной связью с клиентом, были разработаны и широко используются. Эти методы подчеркивают необходимость создания быстрых прототипов, а затем их усовершенствования до тех пор, пока не будет произведено то, что хочет клиент. Такие методы являются отличным способом удостовериться, что произведенная система является той, которая действительно нужна клиенту. Но они не являются хорошими методами, если кто-то хочет застраховать какую-либо форму предварительного проектирования системы. Вместо того, чтобы пытаться заранее продумать систему, разложив ее на составные части, эти виды итеративных методов подчеркивают добавление функций путем агрегирования в ядро ​​первого подхода. Дизайн системы может быть улучшен за счет рефакторинга по мере продвижения проекта, и могут быть моменты, когда можно просмотреть всю систему и изменить дизайн. Но ни одно из этих действий не помогает выполнить проект, и часто результат такой работы не виден заказчику. Гораздо более обычно, что проблемы в дизайне закодированы, а не исправлены. Конечным результатом является система, в которой появляется дизайн, а не система, в которой дизайн продуман. Даже хуже, чем незаметность для клиента, работа по проектированию системы не видна руководству компании, которая разрабатывает систему. Несмотря на то, что менеджеры будут недооценивать преподавание Мистического Месяца Человека [2], все еще есть опасения, что инженеры, которые не создают код, не делают ничего полезного. Дело в том, что хороший дизайн системы требует времени; это то, что требует сольного мышления и долгих обсуждений с другими инженерами. Есть дни, когда кажется, что никакого реального прогресса не достигнуто, и другие дни, когда единственным прогрессом является осознание того, что то, что вы считали прогрессом в течение предыдущих нескольких дней или недель, на самом деле было неправильным поворотом, который на самом деле не работает. Такая реализация - прогресс. Фактически, такая реализация может быть наиболее важным видом прогресса, поскольку она может спасти огромные проблемы в дальнейшем в проекте. Но менеджеру может показаться, что он не двигается вперед. Грэди Буч однажды сказал мне, что, по его мнению, величайший вклад, который он и другие разработчики внесли в поддержку процесса проектирования, заключается в том, что они заставили руководителей понять, что дизайнер что-то делает. Возможно, он преувеличивал, но ненамного. Все, что дает конструктору время подумать о системе, прежде чем фиксировать эти мысли в коде, помогает цели хорошо спроектированных систем. Что действительно нужно, так это акт веры со стороны руководства. Разница между кем-то, кто делает успехи в освоении системы, и кем-то, кто отдыхает в офисе, может быть незаметным снаружи. Большинство менеджеров не могут выполнить задачу проектирования самостоятельно (те, которые могут быть реже, чем те, кто может сделать необходимый прыжок веры), и поэтому им приходится доверять разработчику системы. Наличие инженера в качестве дизайнера, который был успешным в прошлом, может помочь менеджеру проявить терпение. Но если вы найдете менеджера, который действительно хочет дать вам время на выполнение задания по проектированию, оставайтесь с ним или с ней. Он или она - сокровище, гораздо более редкое, чем золото. 4.2 Дизайн и интеллектуальная собственность Более тонкое изменение, которое оказало влияние на дизайн системы, - это изменение отношения корпораций и, в некоторой степени, университетов к интеллектуальной собственности. Одна из причин, по которой проводились конференции и списки рассылки, в которых документировалась и обсуждалась конструкция системы, заключалась в том, что компании, в которых разрабатывались эти системы, не хотели, чтобы идеи, лежащие в основе этих систем, держались в секрете. Действительно, разработчикам системы вообще рекомендовалось публиковать свои разработки. Такие публикации рассматривались как способы сбыта продукции, поставляемой компанией, а дизайнеры - как способы получения обратной связи и новых идей о дизайне. Это также означало, что были форумы, на которых системные дизайнеры могли посмотреть на работу других дизайнеров, обсудить с ними работу и найти решения, которые могли бы быть включены в их собственные проекты. Но за последнее десятилетие компании, которые финансировали проектные работы, решили, что им нужно платить, когда другие использовали результаты дизайна. На первый взгляд, это не плохо. Если компании инвестировали и получили результат, разумно, чтобы они были вознаграждены за инвестиции. Если эти компании увидят, что есть вознаграждение, они с большей вероятностью продолжат инвестиции. Это предпосылка патентной системы в частности и прав интеллектуальной собственности в целом, поэтому, возможно, мы должны быть удивлены, что был период, когда такого рода мышление не было применено к проектированию системы. Было много споров о том, являются ли программное обеспечение в целом и конструкции системы в частности подходящими артефактами для патентного процесса. Я не уверен, где я стою по таким вопросам; обсуждение повторения идей в программном обеспечении и сравнение его с повторением других изобретений в форме, к которой можно прикоснуться и манипулировать, а также дискуссии о том, являются ли конструкции программных систем более правильно охваченными патентным законодательством или авторским правом, интересны как способы разжигать разговоры за напитками. Но, как и многие дискуссии, которые по сути философские, я совсем не уверен, что они закончатся реальным выводом. Менее спорным является тот факт, что существующая система не обслуживает ни компании, которые финансируют проектирование, ни область, в которой проектирование имеет место. Является ли это неотъемлемым аспектом системы или случайностью эволюции системы - это вопрос, который я не могу решить. Но последствия вредны в том смысле, в котором я вижу каждый день. Первая проблема связана с тем, как между компаниями, владеющими этими патентами, ведутся переговоры о стоимости патентов. Такие переговоры, как мне говорят те, кто участвовал в них, обычно ведутся по счету, а не по стоимости. То есть компания А будет подсчитывать количество патентов, которые она имеет в некоторой широкой области, такой как компьютерное оборудование и программное обеспечение. Компания Б будет делать то же самое. Какая бы компания ни владела большим количеством патентов, тот будет заплачен другим, а размер платежа определяется размером разницы. Конечным результатом является то, что каждая компания перекрестно лицензирует все свои соответствующие патенты с другой, и некоторая сумма денег переходит к другому владельцу.