Интервью с экспертами группы Patterns & Practices корпорации Microsoft
Все желающие могли в онлайне пообщаться с командой Patterns & Practices, которая завтра будет выступать на киевском PnP симпозиуме.
Как происходит отбор в команду Patterns & Practices?
В принципе, интервью в команду P&P происходит точно так же, как и на любые другие позиции в Microsoft. Конечно же, кандидаты на работу в нашей команде должны обладать большим опытом работы и обширными знаниями в своей области. Чаще всего люди, которых мы берем на работу, обладают большим опытом работы по созданию программных систем - в разных компаниях и разных проектах. При этом в команде Patterns & Practices есть как программисты, так и тестеры, и program managers - т.е. практически все те же роли, что и в обычной команде разработчиков Microsoft.
Есть ли какие-то специфические требования к кандидатам?
Эти требования довольно высоки, т.к. мы ищем лучших в своей предметной области. Но в любом случае, мы рассматриваем как внутренних кандидатов из других групп Microsoft, так и внешних кандидатов.
Работают ли у вас интерны? Если да, как происходит процесс отбора?
Непосредственно в нашей команде - это большая редкость. Как уже упоминалось в ответе на предыдущий вопрос, мы ищем людей с большим опытом, которого у студентов обычно нет. Однако, другие группы Microsoft постоянно набирают интернов на лето или на более длительный срок. Расспросите об этом сотрудников Microsoft Украина, они с удовольствием расскажут вам, как попасть в эту программу :)
Сотрудничаете ли вы с независимыми экспертами, работающими не в Microsoft?
Постоянно и практически в каждом проекте. Мы очень высоко ценим наших независимых экспертов, поскольку они дают нам ценную обратную связь из "реального мира". Некоторые из наших экспертов являются всемирно известными специалистов. Например, Ralph Johnson (один из "Банды четырех") сотрудничал с нами на проекте Parallel Programming Patterns, или Gerard Meszaros (автор xUnit patterns) был специалистом по предметной области на руководстве по приемочному тестированию.
Насколько Microsoft придерживается разработанных вами руководств и best practices?
Многие команды Microsoft используют рекомендации, разработанные командой Patterns & Practices. Например, руководства по безопасности и тестирования производительности находят широкое применение. Кроме того, компоненты, предназначенные для повторного использования, такие как Enterprise Library, применяются во многих внутренних ИТ-системах, а также в самих продуктах Microsoft, например, Microsoft Exchange 2010 и BizTalk 2009.
Какая численность подразделения?
Размер команды постоянно меняется, но в целом, Patterns & Practices не так уж велика - примерно 25 постоянных сотрудников. С учетом сотрудников, привлекаемых на проекты, а также независимых экспертов, о которых мы говорили ранее, получится примерно 60 человек.
Работаете ли вы еще над какими-то продуктами кроме EntLib?
Конечно. Помимо EntLib, мы работаем над такими проектами, как Prism, руководство по Windows Azure, руководство по разработке для SharePoint, руководство по приемочному тестированию, паттерны параллельного программирования и многими другими. С полным каталогом можно познакомиться здесь.
Над чем планируете работать в следующем году? Есть какой-то публичный roadmap?
Практически у каждого проекта, над которым мы работаем, есть опубликованный план работ.
В следующем году мы будем работать над такими проектами, как Prism 4, руководство по разработке для Windows Phone 7, 3-я часть руководства по разработке облачных приложений, composite services и EntLib 5 for Silverlight.
Кстати, при выборе проектов мы постоянно прислушиваемся к мнению сообщества. С такой маленькой командой, как у нас, мы не можем работать над всеми проектами сразу, поэтому мы стараемся работать над проектами, которые интересными широкому кругу программистов. Ваш голос может оказаться решающим :)
Интересно, но я думаю, что руководство по Windows Phone 7 уже было бы неплохо иметь. Все таки мобильная разработка - это одно из приоритетных направлений Microsoft, поэтому такое руководство помогло бы многим разработчикам удачно "стартануть".
Запросто - вот вам ссылка на текущий драфт руководства по разработке для Windows Phone 7 %-))
Лично я считаю, что отрасль столкнулась с достаточно серьезными проблемами, преодолеть которые непросто на текущем уровне развития инструментальных средств и технологий программирования (уязвимости и ошибки в создаваемых решениях, низкий уровень повторного использования кода и производительности труда разработчиков, фрагментация платформ и сложность сопровождения решений и т.д.). Каким может быть выход из этой ситуации?
В первую очередь - пишите unit test'ы для всех создаваемых программ! Это должно стать частью "гигиены программирования", такой же, как чистка зубов по утрам в повседневной жизни.
Во-вторых, мы рекомендуем agile development - не столько потому, что эта методология привнесла что-то радикально новое, сколько из-за того, что она быстро высвечивает проблемы вашего процесса разработки и позволяет бороться со сложностью систем инкрементально.
В-третьих, Microsoft постоянно совершенствует процесс тестирования с целью улучшения покрытия кода тестами, а также генерацией тестовых сценариев. В Microsoft Research было разработано очень интересное средство под названием Pex. Вы можете составить представление о том, что это такое, посетив любопытный сайт под названием Pex For Fun.
Ответ:
Спасибо за ссылочку на Pex - выглядит интересно, поиграюсь в свободное время.
Я говорил не сколько за свои проекты, сколько за индустрию в целом - думаю, ни юнит-тесты, ни agile development не могут в корне решить проблему уязвимостей в коде, эксплуатируемых зловредным ПО. Здесь, наверное, следует развивать идеи, заложенные в Java/.NET Framework и управляемые языки программирования, но не сколько для облегчения программирования (как сделано сейчас), сколько для увеличения защищенности создаваемых решений.
Что касается повтороного использования кода, то стандартные библиотеки классов разрастаются до таких размеров, что в голове разработчика укладываются слабо. Но хуже всего даже не это, а то, что принятые в большинстве современных языков подходы ООП не предоставляют достаточных возможностей для реализации потребностей разработчиков. Типичная ситуация - скажем, какая-нибудь стандартная или сторонняя библиотеке не предоставляет нужной функциональности, но в то же время и не позволяет путем механизма наследования в объектно-ориентированном подходе реализовать ее за счет того, например, что нужный метод задекларирован как "private" или нужный класс "internal". Конечно, можно возразить, что разработчики библиотеки задумали так изначально, но в реальности они скорее не смогли предусмотреть все сценарии ее использования, что, разумеется, попросту невозможно. В итоге оказывается, что написать и сопровождать свою собственную библиотеку бывает проще и дешевле, чем пытаться использовать сторонние библиотеки, которые не вполне подходят под задачу, даже такие замечательные как EntLib. И вина, здесь, разумеется не разработчиков EntLib, которые в силу объективных причин не могут предусмотреть все, а, скорее, уровня развития современных инструментальных средств, которым присущи определенные фундаментальные ограничения.
...что вы можете сказать о существующих парадигмах программирования, в частности доминирующей объектно-ориентированной? Какие принципиальные недостатки и ограничения парадигмы препятствуют созданию все более сложных и совершенных программных решений? Какой может быть из этого выход?
Вопрос настолько широко сформулирован, что на него трудно ответить. Очень многое зависит от контекста проектов. Для разных предметных областей подходят разные парадигмы. Например, параллельные программы значительно проще создавать на функциональных языках, таких как F#.
Хотелось бы узнать, что вы думаете о будущем программирования через 10-20 лет? Каким оно будет? Какие будут использоваться подходы, языки? Каково ваше видение перспектив функционального, аспектно-ориентированного и других подходов? Могут ли некоторые из названных мною в первом вопросе проблем быть разрешены раз и навсегда?
Популярная поговорка гласит, что все языки программирования являются несовершенной реализацией LISP'а :)
Если серьезно, то очень трудно предсказывать, как эволюционирует программирование в будущем. Почти наверняка язык, который будет популярен через 10-20 лет, еще попросту не существует.
Сегодня достаточно популярны и востребованы 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 не занималась данными проектами и на следующий год у нас нет планов, связанных с ними.
Сейчас активно идет обсуждение методов разработки для 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".
Либо уточните контекст вашей устаревшей системы, чтобы смогли дать вам более конкретные рекомендации.
Вторая часть вопроса посвящена борьбе за документацию кода. Это действительно непростая проблема. Лучшим подходом является написание кода в таком стиле, чтобы он был самоочевидным и сопровождался бы хорошими тестами. Особенно если они написаны в стиле Behaviour-Driven Development (паттерн given.. when.. then)
И в завершении традиционный вопрос: ЯК ПРОПАТЧИТИ KDE2 ПІД FREEBSD?
Нам очень приятно отвечать на вопрос, который уже задавали Президентам России, Украины и Казахстана!
В принципе, FreeBSD отлично работает под Windows Azure, так что попробуйте его запустить под Azure. Вдруг оно само пропатчится? :)
Большое спасибо всем участникам онлайн-конференции за интересные вопросы!
Надеемся увидеть вас завтра на Patterns & Practices Symposium в Киеве!
На вопросы отвечали: Крис Кайзер (Program Manager, Microsoft), Эухиньйо Паче (Senior Program Manager, Microsoft), Григорий Мельник (PhD, Senior Program Manager, Microsoft).
Компании из статьи
| Microsoft Украина |  Украинское подразделение компании Microsoft. |