`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Онлайн-дискуссия с экспертами группы Patterns&Practices корпорации Microsoft

В этой теме читатели сайта «Компьютерного Обозрения» могут задавать вопросы разработчикам Microsoft, представляющим подразделение Patterns&Practices. Задача этих специалистов состоит в формировании подходов и методов, снижающих сложность и трудоемкость разработки и сопровождения ПО корпорации.

С нашими читателями общаются:

Крис Кайзер (Chris Keyser)
Program Manager, Microsoft

Крис работает над разработкой решений Microsoft SharePoint для архитекторов и разработчиков. В течение семи лет занимал различные позиции в Microsoft – был руководителем программной группы Duet, а также ведущим архитектором команды Global ISV в DPE. До того, как Крис присоединился к команде Microsoft, он был разработчиком и менеджером ряда web-стартапов, проектов по встраиваемому программному обеспечению и серверного ПО. Паттерны и практики команды SharePoint опубликованы в третьем релизе руководства SharePoint 2010. Текущие релизы вы можете найти на http://www.microsoft.com/spg.

Эухиньйо Паче (Eugenio Pace)
Senior Program Manager, Microsoft

Эухиньйо – Senior Program Manager в команде Microsoft P&P. Он отвечает за разработку руководства принципов миграции и построения приложений на платформы Azure Windows и Windows Phone 7. До этого он работал над архитектурными рекомендациями по идентификации на основе заявок (claims-based idenitity) и федеративной идентификации.

Григорий Мельник (Grigori Melnik)
PhD, Senior Program Manager, Microsoft

Григорий Мельник, PhD – Senior Program Manager в департаменте patterns & practices в Microsoft. В настоящее время руководит проектами Microsoft Enterprise Library и Software Testing Guidance. Его профессиональный опыт – более 15 лет. Как инженер-разработчик ПО, научный сотрудник и профессор университета с более 40 публикациями внёс существенный вклад в развитие современных методов разработки, тестирования и внедрения комплексных программных систем (включая Acceptance Test-Driven Development). Постоянный докладчик на индустриальных конференциях по прикладной математике и методам моделирования и разработки ПО во всем мире. Признаный эксперт в гибких методам (agile), системному тестированию и ПО эволюции. Член Cовета IEEE Software Advisory Board. Автор книги “Acceptance Test Engineering”.

Задать вопрос можно в любой момент. В четверг, 9 сентября, в 16.00 эксперты начнут отвечать в порядке очереди, причем в процессе читатели могут задавать дополнительные вопросы, развивать дискуссию и т.п. — до 18.30.

Язык общения — русский, украинский или английский.

Мой вопрос касается разработки и поддержки ПО.
Представим случай: тем или иным способом найден баг в какой-то программе. Есть ли какая-то в Microsoft система, через которую происходит слежение за работой над этим багом? Какие меры предпринимаются для избежания такой проблемы в будущем, т.е. как происходит post-mortem анализ? Сейчас активно разрабатываются системы для open-source разработчиков, например баг-тракер Trac и система ревью кода Google ReviewBoard. Планирует ли Microsoft в ближайшем будущем работу над похожими решениями? Было бы очень приятно увидеть продукт от Microsoft, который легко интегрируется с другими продуктами Microsoft, например, Microsoft Outlook и Visual Studio.

Добрый вечер! Специалисты из Patterns & Practices начинают отвечать на ваши вопросы. У вас есть возможность задавать дополнительные вопросы по ходу онлайн-конференции.

Основным средством отслеживания ошибок в Microsoft является Team Foundation Server. Этот продукт интегрирован с Visual Studio, Outlook, SharePoint, Excel и обладает мощными средствами построения отчетом. Разработчики могут подписываться на получение сообщений об изменениях или новых ошибок. Использование такого набора продуктов позволяет обеспечить эффективную работу и обмен информацией в команде.

Еще вопрос. Сейчас активно идет обсуждение методов разработки для web-приложений. А что вы можете сказать про крупные компании, где ведётся разработка на языках типа С++ уже десятки лет? Вопрос в частности адресован Григорию Мельнику. Григорий, есть ли у вас парочка стандартных советов для компаний с крупной базой старого кода? Что сегодня для компании важнее всего, чтобы оставаться конкурентоспособным software house? Нам часто приводят преимущества Test-Driven Development, но в больших компаниях мы редко имеем достаточно контроля над всей громадной системой, чтобы создать тесты, которые будут хорошо охватывать всю функциональность. Как Microsoft борется с этим? Например, начнём с простого, как в Microsoft борются с нелюбовью разработчиков документировать свой код?

Первая часть вопроса связана с устаревшими системами (legacy systems). Давайте, прежде всего, определим, что мы подразумеваем под "устаревшими системами". Я воспользуюсь определением, которое дал в своей книге Michael Feathers: "С точки зрения Test-Driven Development, устаревшей системой является любая система, у которой нет соответствующих блочных тестов (unit test)". Естественно, для действительно крупных систем практически невозможно написать тесты, которые покрывали бы всю функциональность. Существует множество методов, которые применяются при работе с такими устаревшими системами. Например, одним из популярных подходов является разработка тестов для любой новой функциональности, создаваемой для устаревшой системой или взаимодействующей с ней (sprout method - "метод ростков"). Таких методов десятки и, наверное, не имеет смысла перечислять их все здесь. Для дальнейшего ознакомления с этой темой мы рекомендуем вам книгу Michael Feathers "Working Effectively with Legacy Code".

Либо уточните контекст вашей устаревшей системы, чтобы смогли дать вам более конкретные рекомендации.

Apologies for not being able to participate in the live discussion, due to the timezone difference I was still occupied at work. Nevertheless, I hope my message somehow reaches the P&P team.

Thank you very much for such a detailed answer. Luckily, we had a copy of M. Feathers book in our corporate library. It is a gem long forgotten and my colleagues were very surprised that such a book existed and nobody came across it before. I will definitely have a read through, from the first glance it seems like it deserves to be on C++ programmer's desk next to Scott Meyers and Nicolai M. Josuttis. :)

In this case, we also recommend you to follow @mfeathers on Twitter, as he posts lots of interesting insights there!

Вторая часть вопроса посвящена борьбе за документацию кода. Это действительно непростая проблема. Лучшим подходом является написание кода в таком стиле, чтобы он был самоочевидным и сопровождался бы хорошими тестами. Особенно если они написаны в стиле Behaviour-Driven Development (паттерн given.. when.. then)

Несколько вопросов:
1. Как происходит отбор в команду Patterns & Practices?
2. Есть ли какие-то специфические требования к кандидатам?
3. Работают ли у вас интерны? Если да, как происходит процесс отбора?
4. Сотрудничаете ли вы с независимыми экспертами, работающими не в Microsoft?
5. Насколько Microsoft придерживается разработанных вами руководств и best practices?
6. Какая численность подразделения?
7. Работаете ли вы еще над какими-то продуктами кроме EntLib?

1. Как происходит отбор в команду Patterns & Practices?
2. Есть ли какие-то специфические требования к кандидатам?

В принципе, интервью в команду P&P происходит точно так же, как и на любые другие позиции в Microsoft. Конечно же, кандидаты на работу в нашей команде должны обладать большим опытом работы и обширными знаниями в своей области. Чаще всего люди, которых мы берем на работу, обладают большим опытом работы по созданию программных систем - в разных компаниях и разных проектах. При этом в команде Patterns & Practices есть как программисты, так и тестеры, и program managers - т.е. практически все те же роли, что и в обычной команде разработчиков Microsoft.

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

3. Работают ли у вас интерны? Если да, как происходит процесс отбора?

Непосредственно в нашей команде - это большая редкость. Как уже упоминалось в ответе на предыдущий вопрос, мы ищем людей с большим опытом, которого у студентов обычно нет.

Однако, другие группы Microsoft постоянно набирают интернов на лето или на более длительный срок. Расспросите об этом сотрудников Microsoft Украина, они с удовольствием расскажут вам, как попасть в эту программу :)

4. Сотрудничаете ли вы с независимыми экспертами, работающими не в Microsoft?

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

Некоторые из наших экспертов являются всемирно известными специалистов. Например, Ralph Johnson (один из "Банды четырех") сотрудничал с нами на проекте Parallel Programming Patterns, или Gerard Meszaros (автор xUnit patterns) был специалистом по предметной области на руководстве по приемочному тестированию.

5. Насколько Microsoft придерживается разработанных вами руководств и best practices?

Многие команды Microsoft используют рекомендации, разработанные командой Patterns & Practices. Например, руководства по безопасности и тестирования производительности находят широкое применение. Кроме того, компоненты, предназначенные для повторного использования, такие как Enterprise Library, применяются во многих внутренних ИТ-системах, а также в самих продуктах Microsoft, например, Microsoft Exchange 2010 и BizTalk 2009.

6. Какая численность подразделения?

Размер команды постоянно меняется, но в целом, Patterns & Practices не так уж велика - примерно 25 постоянных сотрудников. С учетом сотрудников, привлекаемых на проекты, а также независимых экспертов, о которых мы говорили ранее, получится примерно 60 человек.

7. Работаете ли вы еще над какими-то продуктами кроме EntLib?

Конечно. Помимо EntLib, мы работаем над такими проектами, как Prism, руководство по Windows Azure, руководство по разработке для SharePoint, руководство по приемочному тестированию, паттерны параллельного программирования и многими другими.

С полным каталогом можно познакомиться здесь.

Над чем планируете работать в следующем году? Есть какой-то публичный roadmap?

Практически у каждого проекта, над которым мы работаем, есть опубликованный план работ.

В следующем году мы будем работать над такими проектами, как Prism 4, руководство по разработке для Windows Phone 7, 3-я часть руководства по разработке облачных приложений, composite services и EntLib 5 for Silverlight.

Кстати, при выборе проектов мы постоянно прислушиваемся к мнению сообщества. С такой маленькой командой, как у нас, мы не можем работать над всеми проектами сразу, поэтому мы стараемся работать над проектами, которые интересными широкому кругу программистов. Ваш голос может оказаться решающим :)

Интересно, но я думаю, что руководство по Windows Phone 7 уже было бы неплохо иметь. Все таки мобильная разработка - это одно из приоритетных направлений Microsoft, поэтому такое руководство помогло бы многим разработчикам удачно "стартануть".

А за это отдельное спасибо :)

Приветствую членов команды Patterns&Practices в Украине, желаю почаще бывать в нашей стране, у нас много талантливых разработчиков, интересующихся перспективными технологиями.

У меня будет несколько вопросов как к опытным разработчикам по поводу текущего состояния разработки ПО и будущего программирования.

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

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

В-третьих, хотелось бы узнать, что вы думаете о будущем программирования через 10-20 лет? Каким оно будет? Какие будут использоваться подходы, языки? Каково ваше видение перспектив функционального, аспектно-ориентированного и других подходов? Могут ли некоторые из названных мною в первом вопросе проблем быть разрешены раз и навсегда?

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

В первую очередь - пишите unit test'ы для всех создаваемых программ! Это должно стать частью "гигиены программирования", такой же, как чистка зубов по утрам в повседневной жизни.

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

В-третьих, Microsoft постоянно совершенствует процесс тестирования с целью улучшения покрытия кода тестами, а также генерацией тестовых сценариев. В Microsoft Research было разработано очень интересное средство под названием Pex. Вы можете составить представление о том, что это такое, посетив любопытный сайт под названием Pex For Fun.

Спасибо за ссылочку на Pex - выглядит интересно, поиграюсь в свободное время.

Я говорил не сколько за свои проекты, сколько за индустрию в целом - думаю, ни юнит-тесты, ни agile development не могут в корне решить проблему уязвимостей в коде, эксплуатируемых зловредным ПО. Здесь, наверное, следует развивать идеи, заложенные в Java/.NET Framework и управляемые языки программирования, но не сколько для облегчения программирования (как сделано сейчас), сколько для увеличения защищенности создаваемых решений.

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

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

Для прочих библиотек, в которых встречаются sealed-классы, обычно существует серьезная причина, по которой авторы не хотят, чтобы данная функциональность изменялась. Если же вам все-таки нужно изменить что-то, то вы всегда можете воспользоваться обертыванием (wrapping) этого класса.

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

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

Вопрос настолько широко сформулирован, что на него трудно ответить. Очень многое зависит от контекста проектов. Для разных предметных областей подходят разные парадигмы. Например, параллельные программы значительно проще создавать на функциональных языках, таких как F#.

Хотелось бы узнать, что вы думаете о будущем программирования через 10-20 лет? Каким оно будет? Какие будут использоваться подходы, языки? Каково ваше видение перспектив функционального, аспектно-ориентированного и других подходов? Могут ли некоторые из названных мною в первом вопросе проблем быть разрешены раз и навсегда?

Популярная поговорка гласит, что все языки программирования являются несовершенной реализацией LISP'а :)

Если серьезно, то очень трудно предсказывать, как эволюционирует программирование в будущем. Почти наверняка язык, который будет популярен через 10-20 лет, еще попросту не существует.

Есть выражение от создателя термина "объектно-ориентированный": "Лучший способ предсказать будущее - изобрести его".

Давайте, перефразируем вопрос так: какое будущее создают члены группы P&P в Microsoft? :)

Традиционный вопрос: ЯК ПРОПАТЧИТИ KDE2 ПІД FREEBSD?

Нам очень приятно отвечать на вопрос, который уже задавали Президентам России, Украины и Казахстана!

В принципе, FreeBSD отлично работает под Windows Azure, так что попробуйте его запустить под Azure. Вдруг оно само пропатчится? :)

а теперь серьезно. Сегодня достаточно популярны и востребованы DDD и CQRS. Microsoft DPE Spain опубликовала свое видение использования стека технологий и продуктов Майкрософт для построения подобных архитектурных решений http://microsoftnlayerapp.codeplex.com/. Rinat Abdullin http://abdullin.com нашел пременение Windows Azure для реализации CQRS с использованием облачных технолоший. Планирует ли команда P&P выпустить Guide по данным тематикам?

Опубликованное руководство по разработке для Windows Azure уже включает в себя некоторые из этих концепций и мы продолжаем изучать возникающие паттерны, в том числе и CQRS.

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

Два года назад Microsoft презентовала CTP технологии Oslo(SQL Server Modeling Services), которая предназначена с одной стороны для создания собственных DSL языков, а с другой для моделирования данных (M Language). Планируется ли обновить Guides связанные с работой данных с учетом этой технологии?

К сожалению, этот вопрос немного не по адресу, так как команда Patterns & Practices не занималась данными проектами и на следующий год у нас нет планов, связанных с ними.

Большое спасибо всем участникам онлайн-конференции за интересные вопросы!

Надеемся увидеть вас завтра на Patterns & Practices Symposium в Киеве!

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT