Добрый день.
Те, кто имеет дело с AutoCAD и сторонними решениями для него, наверняка, сталкивались с проблемой прокси объектов, для отображения или перемещения которых требуется установить библиотеки, с помощью которых были созданы данные объекты или так называемые Objects Enablers, от тех же разработчиков. Это достаточно неудобно. Например, получили вы документ от заказчика/субподрядчика и видите только квадраты.

Хочу поделиться с Вами личным опытом создания «нетрадиционного» объекта для AutoCAD. За основу взят анонимный блок. Свойства объекта хранятся отдельно в BlockReference::ExtensionDictionary. Что дает возможность стороннему приложению или скрипту получить к ним доступ и считать их, а при желании изменить, без наличия оригинальных библиотек. Примитивы внутри блока всегда отрисовываются в соответствии со своим состоянием. Да и вообще, устойчивость работы AutoCAD значительно выше. Со стороны все выглядит просто. Но при попытке реализовать данный механизм были выявлены различные «подводные камни». Об этом по порядку.

Я руковожу разработкой ПО уже достаточно много лет. За эти годы мне пришлось провести более тысячи интервью и посчастливилось захантить больше сотни классных программистов. Естественно, у меня сложилась определенная практика проведения технических собеседований, которой я собираюсь поделиться. Возможно, это окажется кому-то полезным.

Ставим задачу

Кого ищем? Ищем эффективных бойцов. Известно, что эффективность программистов со схожим опытом может отличаться в 10 раз (Ф. Брукс) или даже в 27 раз (Р. Гласс). Сразу, оговорюсь, эффективность это не только количество трупов врагов реализованных требований к ПО на единицу трудозатрат, но и умение результативно взаимодействовать с окружающими. Это важно, потому что по моим наблюдениям 50% проектных человеко-часов тратится на коммуникации. У нас это называется «синхронизация ментальных моделей».

Поэтому задача, которую ставим себе при проведении технического собеседования это постараться оценить эффективность бойца.


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