Страница:
Наверное, я излишне перехожу на личности, но факт остается фактом – руководитель, действующий эффективно, оказывает на своих подчиненных определенное влияние. То, каким будет это влияние, зависит от вашей меры ответственности. О том, каким вы останетесь в памяти людей, с которыми работаете, нужно думать не меньше, чем о взаимоотношениях внутри семьи. Если у вас целостный характер, ваш публичный образ станет отражением личностных характеристик. Поймите меня правильно: я не призываю к самолюбованию. Мне просто хочется, чтобы вы осознали некоторые особенности роли лидера и попытались правильно ими воспользоваться. Всем содержанием главы о совещаниях я хотел побудить вас сфокусироваться на отношениях с окружающими.
Консенсус и действия в результате совещаний
Что дальше
Глава 6
Как уразуметь свою техническую роль и придерживаться ее
Конструировать или выращивать
Примат архитектуры
Проектные ограничения в архитектурном планировании
Аналитические позиции как средство управления проектными ограничениями
Консенсус и действия в результате совещаний
В этой главе я упомянул о нескольких типах совещаний. Все они характеризуются единой целью, которая состоит, во-первых, в достижении консенсуса среди участников, и, во-вторых, в составлении плана дальнейших действий. Эти задачи решаются за счет профессионального поведения на любых совещаниях, вне зависимости от того, насколько формальный или неформальный характер они носят. Что я имею в виду под профессиональным поведением? Согласно Вебстеру (Webster), одним из аспектов профессионализма является «последовательное, методичное проведение каких-либо действий». Так и в нашем случае. Последовательность в деле проведения совещаний в конечном итоге приведет вас к успеху. Дискуссии на совещаниях следует поощрять, поскольку на их основе рождаются идеи. Ваша компетенция – еще один аспект профессионализма – в ходе дискуссий, призванных перетекать в конкретные действия, должна быть очевидной.
Попробуем обобщить все вышесказанное. Итак, участвуя в совещаниях или ведя совещания, придерживайтесь следующих принципов.
• Не превращайте совещание в партсобрание. Участие в совещаниях – это тоже работа, и цель состоит в том, чтобы приступить к новой рабочей неделе осмысленно.
• При проведении проектных совещаний обязательно подготавливайте четкий план действий. Руководите разумно и учитывайте фактор группового поведения.
• Проводя беседы с сотрудниками один на один, следуйте принципам, характерным для совещаний в более крупном составе: пытайтесь достичь консенсуса и выстроить план действий.
• Проводя совещания с нетехническими специалистами, помните, что вы олицетворяете образ технаря. Пытайтесь доносить сложные идеи простым языком. Попытки произвести на бухгалтерских работников впечатление, жонглируя таинственными сокращениями, вряд ли прибавят вам уважения. На таких совещаниях ведите себя как педагог. В то же время исполняйте эту роль предусмотрительно, избегайте высокомерия.
• Проводя ретроспективные совещания по проекту, не поддавайтесь соблазну свалить все грехи на другие отделы. Попытайтесь выяснить, в каких областях вы сами и ваши сотрудники могли бы добиться более высокой продуктивности.
• Старайтесь свести количество телеконференций к минимуму. Путем тщательной подготовки и составления четкого плана старайтесь делать их как можно насыщеннее.
Попробуем обобщить все вышесказанное. Итак, участвуя в совещаниях или ведя совещания, придерживайтесь следующих принципов.
• Не превращайте совещание в партсобрание. Участие в совещаниях – это тоже работа, и цель состоит в том, чтобы приступить к новой рабочей неделе осмысленно.
• При проведении проектных совещаний обязательно подготавливайте четкий план действий. Руководите разумно и учитывайте фактор группового поведения.
• Проводя беседы с сотрудниками один на один, следуйте принципам, характерным для совещаний в более крупном составе: пытайтесь достичь консенсуса и выстроить план действий.
• Проводя совещания с нетехническими специалистами, помните, что вы олицетворяете образ технаря. Пытайтесь доносить сложные идеи простым языком. Попытки произвести на бухгалтерских работников впечатление, жонглируя таинственными сокращениями, вряд ли прибавят вам уважения. На таких совещаниях ведите себя как педагог. В то же время исполняйте эту роль предусмотрительно, избегайте высокомерия.
• Проводя ретроспективные совещания по проекту, не поддавайтесь соблазну свалить все грехи на другие отделы. Попытайтесь выяснить, в каких областях вы сами и ваши сотрудники могли бы добиться более высокой продуктивности.
• Старайтесь свести количество телеконференций к минимуму. Путем тщательной подготовки и составления четкого плана старайтесь делать их как можно насыщеннее.
Что дальше
Многое из того, что я рассказываю в этой книге, носит личностный оттенок. Действительно, трудно придумать тему более личностную, чем лидерство при проведении совещаний. В следующей главе я расскажу, как исполнять роль технического лидера. Здесь вам также потребуются навыки группового общения, хотя, располагая обширным опытом взаимодействия с технологиями (по крайней мере, большим, чем общения с людьми), вы, скорее всего, будете чувствовать себя в этой роли более комфортно. Поймите меня правильно – я даже мысли не допускаю, что всю свою жизнь вы прожили в изоляции от общества. Просто технические навыки составляют основу вашего участия в общей деятельности. Не бросайте чтение – следующая глава вам, скорее всего, понравится больше, чем все предыдущие.
Глава 6
Философия и методы технического лидера
Весьма высока вероятность того, что причина, по которой вас сделали руководителем, заключается в ваших успехах на поприще техники. Это свое предположение я уже ранее высказывал. И хотя технические навыки далеко не всегда гарантируют качество руководства, для исполнения роли, которую я намерен описать в этой главе, вы подходите идеально. Многое из того, о чем я рассказывал в предыдущих главах, полагаю, привело вас в уныние своей новизной; материал же этой главы, напротив, скорее всего, покажется вам знакомым и, может быть, даже тривиальным. Это совершенно не означает, что читать главу не надо, – не зря же я ее написал, в конце концов! На самом деле взглянуть на технические проблемы с точки зрения технического лидера очень полезно. Ведь теперь вы не просто «технический руководитель» группы; вы – лидер с большой буквы. Принятие решений – это ваша прерогатива. За последствия принятых решений, сказывающихся на разрабатываемых программных продуктах, вы также несете ответственность, поэтому проблема выбора и принятия решений выходит на первый план.
Каким образом в процессе принятия решения вам поможет эта глава? В ней мы рассмотрим некоторые технические принципы и порассуждаем о деталях – тем самым я попытаюсь привить вам уверенность в своих действиях. С моей точки зрения, главное в нашей высокотехнологичной профессии – сделать так, чтобы лидерство осуществлялось на основе некоего философского видения, раскрывающего технические навыки ведущих программистов. Этой философской основой мы займемся в первую очередь. Не стоит, правда, забывать, что без принципов ее практической реализации полноценное лидерство невозможно, и, соответственно, успешно пасти котов вам также не удастся.
Каким образом в процессе принятия решения вам поможет эта глава? В ней мы рассмотрим некоторые технические принципы и порассуждаем о деталях – тем самым я попытаюсь привить вам уверенность в своих действиях. С моей точки зрения, главное в нашей высокотехнологичной профессии – сделать так, чтобы лидерство осуществлялось на основе некоего философского видения, раскрывающего технические навыки ведущих программистов. Этой философской основой мы займемся в первую очередь. Не стоит, правда, забывать, что без принципов ее практической реализации полноценное лидерство невозможно, и, соответственно, успешно пасти котов вам также не удастся.
Как уразуметь свою техническую роль и придерживаться ее
Роль технического лидера заключается в том, чтобы координировать архитектурные и проектные решения. Архитектура и проектирование – это, как известно, две разные вещи. Да, действительно, программисты иногда воспринимают их как синонимы, но, я вас уверяю, это в корне неправильно. Практикуя техническое лидерство в масштабе своего отдела, вы скоро убедитесь в том, что проектирование компонентов приложений очень сильно отличается от разработки их общей архитектуры. Архитектура направлена на многократное использование проектных решений. В идеале перед сборкой системы из составляющих ее компонентов неплохо было бы макетировать архитектурное понятие. В этом контексте вспомните компонентное конструирование из области объектно-ориентированной технологии – своей основной целью оно провозглашает многократное использование кода. Итак, мы имеем дело с двумя совершенно разными задачами, и по моему скромному, но правильному мнению, многократное использование проектных решений значительно важнее.
Архитектура ориентирована на многократное использование проектных решений.
Сила объектно-ориентированной технологии вне зависимости от языка, на котором она реализуется, – это возможность создания объектов, связывающих прикладные данные с вариантами пользовательского взаимодействия. Детали при этом скрываются. Таким образом, избегая непосредственного соприкосновения с уровнями данных и пользовательского интерфейса, объекты получают открытые интерфейсы, которые, в свою очередь, взаимодействуют со структурой программы и процессами. Итак, мы получаем возможность собирать компоненты, согласующиеся со свойствами и методами, имена которых значимы в контексте проблемной области (в противоположность области решений). К примеру, метод под именем ShowAppointments, наполняя свойство Appointments графического пользовательского интерфейса, способен одновременно скрывать детали – такие как Select * from Appointments where Date = Today. Таким образом, удобочитаемость программ открывает возможности для решения конкретных задач.
Именно в этом высоком уровне понимания кроются огромные преимущества объектно-ориентированных методов, за счет которых последние выгодно отличаются от функциональной декомпозиции и структурных методик, доминировавших в более ранний период компьютерного программирования. В то же время узкое место объектно-ориентированной технологии приходится как раз на создание общей архитектуры системы. С одной стороны, объектно-ориентированные методики позволяют успешно проводить архитектурный анализ; с другой – навыки, полученные при создании компонента, не соответствуют напрямую тем навыкам, которые требуются для организации целостной системы компонентов. Это белое пятно в наборе средств объектно-ориентированной технологии как раз закрывается архитектурными методиками. Ваша задача как технического руководителя состоит в том, чтобы обеспечить создание системной архитектуры до принятия решений по технологии реализации и деталям компонентов, из которых данную систему предполагается конструировать.
Обратимся к аналогии. Классическую архитектурную традицию западной цивилизации принято отсчитывать от древнегреческих и древнеримских строений. Эти здания, простоявшие уже более двух тысяч лет, подобно литературным произведениям талантливых авторов, доносят до непосвященного наблюдателя простое и ясное послание. В то же время при более детальном анализе структуры этих зданий выясняется, что в них скрыты многочисленные свидетельства дотошной творческой работы. Программная архитектура способна на такие же чудеса – демонстрируя внешний блеск, она может заключать в себе невероятную сложность. Впрочем, поскольку наша дисциплина существует всего лишь полвека, до того момента как ее лучшие достижения станут называть классическими, пройдет еще много времени. Как технический лидер вы должны заложить те основы, на которых сотрудникам вашей группы и, возможно, другим разработчикам предстоит заниматься непосредственно конструированием. Да, мы живем в то время, когда популярное искусство необдуманно провозглашается непреходящей ценностью. При этом не следует забывать, что результаты наших трудов над клавиатурой должны пройти проверку временем.
Архитектура ориентирована на многократное использование проектных решений.
Сила объектно-ориентированной технологии вне зависимости от языка, на котором она реализуется, – это возможность создания объектов, связывающих прикладные данные с вариантами пользовательского взаимодействия. Детали при этом скрываются. Таким образом, избегая непосредственного соприкосновения с уровнями данных и пользовательского интерфейса, объекты получают открытые интерфейсы, которые, в свою очередь, взаимодействуют со структурой программы и процессами. Итак, мы получаем возможность собирать компоненты, согласующиеся со свойствами и методами, имена которых значимы в контексте проблемной области (в противоположность области решений). К примеру, метод под именем ShowAppointments, наполняя свойство Appointments графического пользовательского интерфейса, способен одновременно скрывать детали – такие как Select * from Appointments where Date = Today. Таким образом, удобочитаемость программ открывает возможности для решения конкретных задач.
Именно в этом высоком уровне понимания кроются огромные преимущества объектно-ориентированных методов, за счет которых последние выгодно отличаются от функциональной декомпозиции и структурных методик, доминировавших в более ранний период компьютерного программирования. В то же время узкое место объектно-ориентированной технологии приходится как раз на создание общей архитектуры системы. С одной стороны, объектно-ориентированные методики позволяют успешно проводить архитектурный анализ; с другой – навыки, полученные при создании компонента, не соответствуют напрямую тем навыкам, которые требуются для организации целостной системы компонентов. Это белое пятно в наборе средств объектно-ориентированной технологии как раз закрывается архитектурными методиками. Ваша задача как технического руководителя состоит в том, чтобы обеспечить создание системной архитектуры до принятия решений по технологии реализации и деталям компонентов, из которых данную систему предполагается конструировать.
Обратимся к аналогии. Классическую архитектурную традицию западной цивилизации принято отсчитывать от древнегреческих и древнеримских строений. Эти здания, простоявшие уже более двух тысяч лет, подобно литературным произведениям талантливых авторов, доносят до непосвященного наблюдателя простое и ясное послание. В то же время при более детальном анализе структуры этих зданий выясняется, что в них скрыты многочисленные свидетельства дотошной творческой работы. Программная архитектура способна на такие же чудеса – демонстрируя внешний блеск, она может заключать в себе невероятную сложность. Впрочем, поскольку наша дисциплина существует всего лишь полвека, до того момента как ее лучшие достижения станут называть классическими, пройдет еще много времени. Как технический лидер вы должны заложить те основы, на которых сотрудникам вашей группы и, возможно, другим разработчикам предстоит заниматься непосредственно конструированием. Да, мы живем в то время, когда популярное искусство необдуманно провозглашается непреходящей ценностью. При этом не следует забывать, что результаты наших трудов над клавиатурой должны пройти проверку временем.
Конструировать или выращивать
Традиционной метафоре строительства в нашей профессии соответствует термин «конструирование»
[58]. Как часто мы им пользуемся для описания своих действий? По моим наблюдениям, довольно часто. Все начинается с детства. Если вы из моего поколения, то ребенком, наверное, играли с конструкторами – ну а представители поколения X, вероятно, помнят свои экзерсисы с Lego. Обиходное понятие «конструирование программного обеспечения» вполне доходчиво обозначает повседневную деятельность программиста. Попробуем проанализировать эту метафору в буквальном смысле и объяснить, что значит дополнять приложения новыми характеристиками. Можно ли надстроить небоскреб дополнительными десятью этажами и при этом пребывать в уверенности, что фундамент их выдержит? Мне так не кажется; надеюсь, что и вы придерживаетесь моего мнения. Придется обратиться к еще одной метафоре – садоводству. Разбивая сад и выращивая его, вы, естественно, время от времени выкорчевываете одни растения и высаживаете другие. В своей книге о прагматическом программировании Эндрю Хант (Andrew Hunt) и Дэвид Томас (David Thomas) высказываются об этой метафоре следующим образом:
Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.
Метафора садоводства, к тому же, выражает различие между органическим и синтетическим. Все органическое выращивается; синтетические же объекты собираются из конструируемых компонентов. Действительно, конструируя компоненты, мы делаем их синтетическими по самой природе. Однако та среда, в которой их предполагается выращивать, должна выводить целое за рамки суммы компонентов. Кроме того, она должна предусматривать возможность адаптации к изменяющимся коммерческим требованиям и к технологической эволюции.
Итак, пытаясь усвоить материал, который я излагаю в дальнейшем, не забывайте о биологии и старайтесь не зацикливаться на аналогиях со строительной индустрией. Функции метафор ограничены – они просто-напросто помогают применить абстрактные понятия в условиях рутинной технической деятельности. Нельзя писать код, исходя из метафоры. В этом процессе без деталей проектного решения не обойтись. С другой стороны, все эти детали в совокупности формируют образец. А вот образец уже можно рассматривать метафорически, анализируя степень его применимости к решению бизнес-задач. Вы ведь еще не забыли, как важно для нас думать? Штудируя мою книгу, вы должны были уже уяснить, что главное в нашей работе – мыслить. Мыслить широко и ни в коем случае не поверхностно. Никогда не забывайте этот принцип – он вам пригодится.
«Растения в саду высаживаются, с одной стороны, в соответствии с исходным замыслом, а с другой – согласно текущим обстоятельствам. Некоторые из них выживают, другим же суждено превратиться в компост. Растения можно пересаживать, менять их расположение, играя, таким образом, со светом и тенью, ветром и дождем. Переросшие растения подрезают или срезают, а если, к примеру, какой-нибудь цветок по своему цвету не соответствует окружению, его пересаживают в более подходящее (с эстетической точки зрения) место. Занимаясь садоводством, мы выдираем сорняки и удобряем растения, которым нужна дополнительная поддержка. Хороший садовод постоянно наблюдает за здоровьем растений на своем участке и при необходимости вносит разного рода коррективы (удобряет почву, пересаживает растения, придумывает новый вариант разбивки)» [59].Надо сказать, что метафора садоводства значительно лучше соответствует разработке программных средств. Она делает очевидным преходящий характер программных продуктов и акцентирует внимание на архитектуре, гибкость которой подразумевает возможность реализации новых структур. В контексте архитектуры системы конструируются, а непосредственно программные продукты выращиваются. Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.
Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.
Метафора садоводства, к тому же, выражает различие между органическим и синтетическим. Все органическое выращивается; синтетические же объекты собираются из конструируемых компонентов. Действительно, конструируя компоненты, мы делаем их синтетическими по самой природе. Однако та среда, в которой их предполагается выращивать, должна выводить целое за рамки суммы компонентов. Кроме того, она должна предусматривать возможность адаптации к изменяющимся коммерческим требованиям и к технологической эволюции.
Итак, пытаясь усвоить материал, который я излагаю в дальнейшем, не забывайте о биологии и старайтесь не зацикливаться на аналогиях со строительной индустрией. Функции метафор ограничены – они просто-напросто помогают применить абстрактные понятия в условиях рутинной технической деятельности. Нельзя писать код, исходя из метафоры. В этом процессе без деталей проектного решения не обойтись. С другой стороны, все эти детали в совокупности формируют образец. А вот образец уже можно рассматривать метафорически, анализируя степень его применимости к решению бизнес-задач. Вы ведь еще не забыли, как важно для нас думать? Штудируя мою книгу, вы должны были уже уяснить, что главное в нашей работе – мыслить. Мыслить широко и ни в коем случае не поверхностно. Никогда не забывайте этот принцип – он вам пригодится.
Примат архитектуры
За последнее десятилетие появилось множество работ – как фундаментальных, так и прикладных, – доказывающих необходимость применения в процессе разработки программных средств качественной архитектуры. Исследователи, специализирующиеся в этой области, указывают на то, что огромное количество проектов приложений заканчиваются неудачей именно из-за пренебрежения архитектурными вопросами
[60]. В результате выполнения таких проектов, как правило, получаются «прямолинейные» системы. Их последующая адаптация к изменяющимся коммерческим требованиям осуществляется с большими трудностями, поскольку предполагает выделение значительных временных, трудовых и интеллектуальных ресурсов.
Занимаясь проектированием той или иной системы, вы должны уделять первоочередное внимание рискам. Каким видам рисков? Во-первых, риску ухудшения позиций компании на рынке, возникающему, когда в существующий продукт вследствие конкуренции приходится вносить новые непредусмотренные изначально черты; риску неумеренного усложнения процесса сопровождения продуктов, возникающему вследствие жесткой взаимозависимости компонентов-подсистем или негибкости их конфигурации. Еще один вид рисков заключается в неоправданной сложности продукта на верхних уровнях архитектуры. Это обстоятельство чрезвычайно усложняет задачу кодировщиков, не принимавших участия в процессе создания системы, но вынужденных выискивать способы исправления базовых компонентов. Все перечисленные проблемы имеют непосредственное отношение к временным и финансовым затратам, которые ваш начальник, естественно, желает сократить.
Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана [61]. С точки зрения этих авторов, любой архитектор должен:
• в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;
• хорошо разбираться в предметной области клиента – будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;
• получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;
• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;
• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;
• уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.
Не кажется ли вам, что выполнение всех этих требований выходит за рамки ваших скромных обязанностей? Если вы придерживаетесь такой точки зрения, рекомендую вам расширить кругозор, предварительно попытавшись вспомнить все разработанные с вашим участием продукты, которым так и не суждено было продвинуться дальше первой версии. Все мы так или иначе имели дело с продуктами-однодневками. С моей точки зрения, недостаточно комплексное понимание задачи приводит к созданию подобного рода тактических решений, которые на первый взгляд удачны, однако не выдерживают проверки временем.
Архитектор должен уметь решать эту проблему, имея в виду два важных понятия: проектные ограничения (design forces), которые обусловливают все решения, принимаемые относительно программных средств, и аналитические позиции (analysis viewpoints), позволяющие принимать решения в соответствии с проектными ограничениями.
Занимаясь проектированием той или иной системы, вы должны уделять первоочередное внимание рискам. Каким видам рисков? Во-первых, риску ухудшения позиций компании на рынке, возникающему, когда в существующий продукт вследствие конкуренции приходится вносить новые непредусмотренные изначально черты; риску неумеренного усложнения процесса сопровождения продуктов, возникающему вследствие жесткой взаимозависимости компонентов-подсистем или негибкости их конфигурации. Еще один вид рисков заключается в неоправданной сложности продукта на верхних уровнях архитектуры. Это обстоятельство чрезвычайно усложняет задачу кодировщиков, не принимавших участия в процессе создания системы, но вынужденных выискивать способы исправления базовых компонентов. Все перечисленные проблемы имеют непосредственное отношение к временным и финансовым затратам, которые ваш начальник, естественно, желает сократить.
Создание архитектуры – это активный творческий процесс, который отнюдь не ограничивается сидением за клавиатурой, фиксацией коммерческих требований и реализацией компонентов, которые способны эти требования удовлетворить, в коде. В процессе работы над архитектурой вам придется абстрагироваться от своих механистических обязанностей и максимально углубиться в задачу, которую предстоит решить. Спору нет – во многих случаях решение оказывается вполне механистическим, то есть чисто программным. И тем не менее, если вы не разберетесь в задачах, стоящих перед своей компанией, обеспечить продуктам длительное и продуктивное существование вам, скорее всего, не удастся. Марк и Лора Сьюелл (Marc & Laura Sewell) в своей работе о роли архитекторов перечисляют ряд важнейших действий, которые должны предшествовать составлению любого проектного плана [61]. С точки зрения этих авторов, любой архитектор должен:
• в совершенстве владеть искусством выслушивания, опрашивания и наблюдения;
• хорошо разбираться в предметной области клиента – будь то банковское обслуживание, деятельность государственных органов, образование, здравоохранение, розничная торговля или скачки;
• получить стратегическое представление о деятельности предприятия клиента, не ограничиваясь тактическим или рабочим обзором его деятельности;
• иметь комплексные познания в технологической области – для того чтобы при разработке архитектурного плана суметь учесть все без исключения варианты стратегических решений;
• наладить конструктивное взаимодействие с клиентом и специалистом, ответственным за конструирование;
• уяснить видение вопроса клиентом и согласованное с ним проектное решение, следить за их неукоснительным соблюдением.
Не кажется ли вам, что выполнение всех этих требований выходит за рамки ваших скромных обязанностей? Если вы придерживаетесь такой точки зрения, рекомендую вам расширить кругозор, предварительно попытавшись вспомнить все разработанные с вашим участием продукты, которым так и не суждено было продвинуться дальше первой версии. Все мы так или иначе имели дело с продуктами-однодневками. С моей точки зрения, недостаточно комплексное понимание задачи приводит к созданию подобного рода тактических решений, которые на первый взгляд удачны, однако не выдерживают проверки временем.
Архитектор должен уметь решать эту проблему, имея в виду два важных понятия: проектные ограничения (design forces), которые обусловливают все решения, принимаемые относительно программных средств, и аналитические позиции (analysis viewpoints), позволяющие принимать решения в соответствии с проектными ограничениями.
Проектные ограничения в архитектурном планировании
Поскольку в формализованном виде дисциплина архитектурного планирования появилась относительно недавно, в ее рамках существует несколько конкурирующих концепций. Мальво (Malveau) и Маубрей (Mowbray)
[62]– два эксперта в этой области – приводят список основных концепций. Это каркас Закмана (Zachman), открытая распределенная обработка (Open Distributed Processing, ODP), анализ предметной области, модель 4+1 представлений программной архитектуры и, наконец, академическая программная архитектура. Это уже немало. А знакомы ли вы с положениями каждой из них? Если нет, торопитесь – принимайтесь за изучение перечисленных концепций, поскольку они предоставляют любому специалисту прекрасный инструментарий для создания многократно используемых систем.
Разобравшись с положениями различных архитектурных концепций, вы поймете, что все они преследуют общую цель. Она заключается в контроле над проектными ограничениями, которые обуславливают все без исключения программные решения, относящиеся к архитектуре. Проектные ограничения – это те факторы, которые необходимо учитывать с самого начала процесса разработки программного продукта. Они выражают ряд вопросов, на которые любая архитектура должна отвечать. Частично эти вопросы перечислены ниже.
• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?
• Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?
• Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?
• Какой бы продукт ни создавался, в течение нескольких последующих лет его ожидают значительные изменения, причем предпосылки для осуществления этих изменений должны закладываться в фундамент проекта.
• В связи с тем, что ожидается реализация решений в аппаратной части, особое внимание следует уделить созданию, конфигурированию и сопровождению инфраструктуры.
• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании [63]применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?
Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно сформулируйте их и донесите до группы разработчиков – ведь умение четко сформулировать вопросы иногда важнее, чем даже знание правильных ответов на них. Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна. Способов наделать глупостей всегда более чем достаточно, и первый вопрос, который вы должны себе задать, звучит так: «Что я должен делать? Какое решение будет правильным?» Задавая адекватные вопросы, вы сможете организовать создание стройной, мощной и долговечной архитектуры.
Разобравшись с положениями различных архитектурных концепций, вы поймете, что все они преследуют общую цель. Она заключается в контроле над проектными ограничениями, которые обуславливают все без исключения программные решения, относящиеся к архитектуре. Проектные ограничения – это те факторы, которые необходимо учитывать с самого начала процесса разработки программного продукта. Они выражают ряд вопросов, на которые любая архитектура должна отвечать. Частично эти вопросы перечислены ниже.
• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?
• Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?
• Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?
• Какой бы продукт ни создавался, в течение нескольких последующих лет его ожидают значительные изменения, причем предпосылки для осуществления этих изменений должны закладываться в фундамент проекта.
• В связи с тем, что ожидается реализация решений в аппаратной части, особое внимание следует уделить созданию, конфигурированию и сопровождению инфраструктуры.
• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании [63]применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?
Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно сформулируйте их и донесите до группы разработчиков – ведь умение четко сформулировать вопросы иногда важнее, чем даже знание правильных ответов на них. Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна. Способов наделать глупостей всегда более чем достаточно, и первый вопрос, который вы должны себе задать, звучит так: «Что я должен делать? Какое решение будет правильным?» Задавая адекватные вопросы, вы сможете организовать создание стройной, мощной и долговечной архитектуры.
Аналитические позиции как средство управления проектными ограничениями
Чтобы решить проблемы, возникающие благодаря проектным ограничениям, необходимо иметь представление о позициях, с которых анализируются любые корпоративные варианты архитектуры. Аналитическая позиция – это, по сути, точка зрения на проектное решение, исходя из которой оно анализируется. Эта позиция, или точка зрения, изменяется по мере изучения системы с разных сторон, исходя из степени серьезности различных проектных ограничений. Вне зависимости от конкретной концепции создания архитектуры все исследователи выделяют несколько общих аналитических позиций, формулируя их в виде вопросов.
• Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)
• Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?
• Каков механизм взаимодействия компонентов, благодаря которому система функционирует?
• Какие технологии в наибольшей степени приспособлены для создания данного программного обеспечения?
• Как предполагается поставить систему клиенту?
Задаетесь ли вы этими вопросами о предполагаемом продукте в ходе проектных совещаний (о них мы говорили в предыдущей главе)? Без них не обойтись – в противном случае у вас получится случайная архитектура, а это крайне опасный негативный эталон. Не забывайте, что переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты. Этот фактор риска в процессе проектирования следует постоянно иметь в виду.
Переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты.
Держу пари, что вы сомневаетесь: нужно ли вам все это знать? Полагаю, что если вы действительно хотите стать эффективным техническим лидером, это знание необходимо. Если вы пользуетесь языком программирования четвертого поколения (4GL, например, Visual Basic), а не, скажем, С++, то больше внимания следует уделять разработке архитектуры системы. Даже при условии применения С++ создать плохую архитектуру не представляет труда – что уж говорить о языках четвертого поколения! Да, действительно, они позволяют оперативно выстроить механизм взаимодействия пользователя с системой, но это, как вы понимаете, лишь ее оболочка. Термин быстрая разработка приложений (Rapid Application Development, RAD), возникнув на заре создания программных продуктов под Windows, первоначально отражал высокие темпы выхода продуктов на рынок, достигавшиеся средствами языков четвертого поколения. В сегодняшних условиях «быстрая» разработка в большинстве случаев приводит к появлению некачественных программных продуктов. Мне даже кажется, что аббревиатуру RAD сегодня более уместно расшифровывать как «разработка мерзких приложений» (Rotten Application Development). Первоочередное внимание следует уделять, говоря анатомическим языком, скелету, нервной системе и внутренним органам. В противном случае вы рискуете извергнуть очередную халтуру.
Некоторые компании настолько увлекаются скоростью разработки, что рано или поздно им придется столкнуться с долгосрочными последствиями непродуманности архитектуры. Кто знает, быть может, вы работаете в одной из таких компаний, трудитесь себе над продуктом, находящимся в конце цикла разработки, и регулярно выслушиваете от сотрудников группы поддержки отчеты о найденных ошибках. Стремление ввести в продукт новые характеристики естественным образом ограничивается необходимостью вернуться к исправлению найденных ошибок, которые, вполне возможно, возникли именно из-за того, что в процессе разработки был взят слишком высокий темп. Если бы у вас нашлось время поразмыслить над этой проблемой, вы, скорее всего, пришли бы к выводу о том, что быстрая работа существенно увеличивает риск в ближайшее же время столкнуться с неприятностями, обусловленными непродуманностью архитектуры. Процесс конструирования программных продуктов, если обратиться на этот раз к спортивной терминологии, можно сравнить с марафоном, но уж никак не со спринтом. Темп, предусматривающий долговечность конечного результата, есть необходимое условие достижения качества в производстве.
• Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)
• Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?
• Каков механизм взаимодействия компонентов, благодаря которому система функционирует?
• Какие технологии в наибольшей степени приспособлены для создания данного программного обеспечения?
• Как предполагается поставить систему клиенту?
Задаетесь ли вы этими вопросами о предполагаемом продукте в ходе проектных совещаний (о них мы говорили в предыдущей главе)? Без них не обойтись – в противном случае у вас получится случайная архитектура, а это крайне опасный негативный эталон. Не забывайте, что переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты. Этот фактор риска в процессе проектирования следует постоянно иметь в виду.
Переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты.
Держу пари, что вы сомневаетесь: нужно ли вам все это знать? Полагаю, что если вы действительно хотите стать эффективным техническим лидером, это знание необходимо. Если вы пользуетесь языком программирования четвертого поколения (4GL, например, Visual Basic), а не, скажем, С++, то больше внимания следует уделять разработке архитектуры системы. Даже при условии применения С++ создать плохую архитектуру не представляет труда – что уж говорить о языках четвертого поколения! Да, действительно, они позволяют оперативно выстроить механизм взаимодействия пользователя с системой, но это, как вы понимаете, лишь ее оболочка. Термин быстрая разработка приложений (Rapid Application Development, RAD), возникнув на заре создания программных продуктов под Windows, первоначально отражал высокие темпы выхода продуктов на рынок, достигавшиеся средствами языков четвертого поколения. В сегодняшних условиях «быстрая» разработка в большинстве случаев приводит к появлению некачественных программных продуктов. Мне даже кажется, что аббревиатуру RAD сегодня более уместно расшифровывать как «разработка мерзких приложений» (Rotten Application Development). Первоочередное внимание следует уделять, говоря анатомическим языком, скелету, нервной системе и внутренним органам. В противном случае вы рискуете извергнуть очередную халтуру.
Некоторые компании настолько увлекаются скоростью разработки, что рано или поздно им придется столкнуться с долгосрочными последствиями непродуманности архитектуры. Кто знает, быть может, вы работаете в одной из таких компаний, трудитесь себе над продуктом, находящимся в конце цикла разработки, и регулярно выслушиваете от сотрудников группы поддержки отчеты о найденных ошибках. Стремление ввести в продукт новые характеристики естественным образом ограничивается необходимостью вернуться к исправлению найденных ошибок, которые, вполне возможно, возникли именно из-за того, что в процессе разработки был взят слишком высокий темп. Если бы у вас нашлось время поразмыслить над этой проблемой, вы, скорее всего, пришли бы к выводу о том, что быстрая работа существенно увеличивает риск в ближайшее же время столкнуться с неприятностями, обусловленными непродуманностью архитектуры. Процесс конструирования программных продуктов, если обратиться на этот раз к спортивной терминологии, можно сравнить с марафоном, но уж никак не со спринтом. Темп, предусматривающий долговечность конечного результата, есть необходимое условие достижения качества в производстве.