понедельник, 19 октября 2009 г.

Бесконечные споры

Существует тонкая грань между свободой подчиненных и балаганом. С одной стороны руководитель должен давать своим подчиненным достаточно свободы, чтобы они могли раскрыть свой потенциал, участвовать в принятии управленческих решений и, таким образом, перенимать опыт руководителя, с другой стороны, подобная свобода действий может привести к хаосу, когда каждый имеет свою точку зрения и ресурсы каждого сотрудника направлены не на движение вперед, а на убеждения всего коллектива в правильности своей точки зрения.
Потрясающий совет в решении подобной проблемы дают авторы книги Adrenaline Junkies and Template Zombies в шаблоне поведения под названием "Endless Huddle" (Бесконечные совещания).
Основную мысль этого шаблона авторы позаимствовали из документа "Warfighing, United States Marine Corps":

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

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

понедельник, 12 октября 2009 г.

[Visual C++ 2008] Duplicate cpp filename

Я все еще занимаюсь переводом старого С++ проекта с VS2003 на VS2008 и в процессе перевода столкнулся с одной интересной проблемой.

Если в проекте содержится несколько файлов с одинаковыми именами (естественно, в различных папках), то линковаться такой проект не будет.

Проблема в том, что при компиляции файла с именем Foo.cpp студия генерирует объектный файл с именем Foo.obj, а если такой файл уже существует, то просто перезаписывает старый файл. В результате одного (или нескольких, в зависимости от количества cpp-файлов с одинаковыми именами) объектного файла будет не хватать, о чем любезно и сообщит линковщик.

Для проверки достаточно создать простое консольное приложение добавить Foo.h и Foo.cpp в корень и в подпапку, указать различные пространства имен и попробовать в Main.cpp создать объекты обоих классов.

Интересно то, что подобного поведения не было в предыдущих версиях компилятора и подобные проекты успешно компилировались как на VS2005, так и на VS2008. Там эта проблема решалась путем добавления в имя объектного файла чисел 2, 3 и т.д.

Еще более интересным является то, что эта проблема не будет решена до выхода очередной версии Visual C++. Вот один из ответов команды VC++ Team, найденный на MSConnect:

“Unfortunately we will not be able to fix this issue during this release. Please feel free to reactivate the bug if this is a blocking scenario.

Having duplicate file names in the same project is not a supported scenario. As a workaround as you recognize please change the name of the files that are being included in the same project.”

Подробности можно найти здесь и здесь.

Существует по крайней мере два обходных пути (возможны и другие, о которых я не знаю):

1. Избавиться от неуникальных файлов путем переименования.

2. Явно задавая имя объектного файла в свойствах конкретного файла.

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

Update (2009-10-14)

Существует по крайней мере один более изящный способ решения этой проблемы: можно для группы файлов, чьи имена совпадают с другими cpp-файлами в свойствах изменить поле Object File Name с $(IntDir)\ на $(IntDir)\Your Sub Dir\, в результате чего, объектные файлы для этих cpp-файлов будут складываться в указанную подпапку.

вторник, 6 октября 2009 г.

[Visual Studio] Find & Replace

В данный момент я работаю над переводом одного старого проекта, написанного под .Net Framework 1.1 на .Net Framework 3.5. При этом одной из задач является переход с синтаксиса Managed C++, на синтаксис C++/CLI.

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

Итак, задача: переделать свойства с синтаксиса Managed C++ в синтаксис C++/CLI.

Синтаксис свойства на Managed C++:
__property int get_EventType() { return eventType_; }

Синтаксис свойства на С++/CLI:

property int EventType { int get() { return eventType_; } }

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

Шаблон для поиска:

__property:b+{.#}:b*\*@:bget_{:w}\(\):b*(\n*:b*)\{\n*:b*{.*;}:b*\n*:b*\}

Шаблон для замены:

property \1 \2 { \1 get() { \3 } }

Синтаксис регулярных выражений в Visual Studio несколько отличается от общепринятого, но это не слишком важно, т.к. идея остается той же и в msdn прекрасно описаны особенности.

Теперь, запустив в Visual Studio механизм Find & Replace мы будем заменять свойства вида:

__property int get_EventType() { return eventType_;  }

Или

__property int get_EventType()

{

    return eventType;

}

На свойства вида:

property int EventType { int get() { return eventType; } }

Как правильно писал Джон Роббинс, разработчики очень часто плохо отзываются о своих пользователях, поскольку те не читают документацию и слабо используют функционал их приложений, но сами разработчики в этом плане не так уж и далеки от своих пользователей, когда речь касается об использовании функционала среды разработки.  Visual Studio содержит множество функций и инструментов, способных существенно упростить жизнь каждому разработчику, но мало кто из них (из нас) считает нужным изучать подобные возможности. Функция Find & Replace не является исключением. Представленный шаблон для преобразования синтаксиса свойств не претендует  на полноту, он подходит под тот формат записи, который применяется у меня, но возможно потребует некоторых изменений для вас. Но я и не хотел сделать инструмент, подходящий на все случаи жизни, а, скорее, продемонстрировать возможности инструмента, который всегда рядом и вполне может помочь для решения повседневных задач кодирования.