IT-People Pecha-Kucha: первые впечатления

Впечатления от IT-People Pecha-Kucha, прошедшем 1-го декабря.
Disclaimer: это не анализ, это впечатления по быстрому... ;)  

Для чисто технического спеца, который не планирует растить в себе softskills и заниматься хоть каким-то управлением людьми, это мероприятие было бы почти бесполезной тратой времени, потому что было больше ориентировано на работу с людьми. Всё таки не даром в названии торчит "People" :)

Собственно сами впечатления:
Выступление Дмитрия Миндра. Само по себе выступление было неплохим для вводного, но выбор темы был просто непонятен - в кафе и так собрались люди, которые не "сидят на попе ровно" (с)Панкратов. Так что идея о необходимости убеждать пришедших, что стоит вкладываться в самообразование, networking и делать работу качественно, - вызывает сомнения.
«Роль менеджера в гибкой разработке» - внятные впечатления просто не формулируются... Аджайл всегда такой аджайл...
Тим Евграшин и Сергей Бережной - просто качественные презентации. Правда понимание того, что стоит за этим "просто" и "качественно" заставляет снять шляпу перед авторами - хоть сейчас утаскивай это "просто и качественно" как опорный конспект для действий.
Презентация BABOK - прикольный анонс киевской группы BA, сделано весело и так чтобы привлечь внимание, но это пока не в области моих интересов.
Был человек, которому микрофон мешал выступать :) Очень зажигательно, очень быстро - впечатление как от китайской пиротехники: Вспышки, взрывы...Трах-бах! Бздыщ!! Но в конце вопрос: "что ЭТО было??!!" Может поэтому и не запомнил как его зовут?
"Просто и качественно" можно сказать и о Квантоновом скачке Панкратова, но от него ожидал подспудно большего.
Вика Придатко с "Техническим интервью с человеческим лицом" и выступление Орлова - лучшие для меня презентации на этой PechKucha и новый пункт в моё must view для TL или ПМ.

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

Update:
Андрей Анпилогов начал выкладывать записи с мероприятия на youtube

Update2:
Теперь понятно, почему в панкратовской чувствовалось возможность улучшения. Оказывается на ExpertLabs у него был более полный доклад - смотреть здесь.

TDD в условиях плотного использования ATL/COM

Попытки внедрить TDD для проектов, которые активно используют ATL/COM, очень часто заканчивались для меня неудачно из-за сложности задачи, которая приводит к тому, что просто опускались руки из-за того что не знал как подступится к задаче и гугл с яндексом в те моменты молчали и не желали делится мудростью других людей.

И проблема была даже не в том "как протестировать сам COM-компонент?" - это не представляло особой проблемы, потому что был и есть явно заданный интерфейс класса, единственной особенностью которого является то, как создаётся объект этого класса. Дальше всё сводилось к классическому подходу для TDD.
Основной проблемой являлся вопрос "как протестировать класс, который уже активно использует COM-компоненты?"

Почему проблемой являлся именно этот вопрос? В случае, когда уже существует код, который уже активно использует COM, для качественного тестирования нужно предоставить классу набор заглушек для уже используемых комовских компонентов, которые и будут задавать условия для проверяемого поведения внутри компонента.

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

Подсказкой к решению является скрытая причина этой ситуации - у нас уже по всему коду протянута неявная зависимость от реестра системы. Соответственно для удобства в написании тестов я должен обеспечить единую точку доступа и контроля этой зависимости. Что привело меня к следующей идее: введём дополнительный архитектурный слой с единичным контейнером, который контролирует процесс создания COM-компонентов (по аналогии с слоем работы с объектами базы данных).

Единый контейнер прийдёт к нам со всеми своими достоинствами и недостатками:

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

Архитектурная идея с подобными контейнерами не сильно распространена в C++, но она решает свою задачу.

P.S.
Я таки дописал хоть один пост за прошедший год.