Пришел в интересную компанию в небольшую команду (5 чел).
Проект интересный, сложный, команда распределенная. Первая фаза — еще 6 мес. Дальше доработки еще год как минимум. (чтобы было понятно, что "тяп-ляп" тут будет больно).
Через месяц понял, что "команда" раз за разом принимает решения, от которых у меня волосы дыбом становятся. Решил спросить стороннего мнения – это я такой «неуживчивый» или действительно решения непрофессиональные. С одной стороны — ну явно как-то не "по-взрослому", а с другой — если один против всех, то чаще не прав — один? Хотя не скажу что против всех — как правило я пытаюсь показать недостатки решения кому-то одному а остальные — заняты своими делами.

Решения, выносимые на ваш суд:

1. На мой вопрос почему не собирается релиз-версия и предложение заняться этим был ответ, что этим занимается другой чел. (Ну не проблема, у меня действительно свои задания есть). Через 3 недели был назначен преальфа релиз и в пятницу, накануне этого релиза оказалось, что релиз-версия падает при запуске. Тот чел начал биться над этой проблемой. Я узнал об этом только ближе к вечеру, позвонил ему и сказал что в таких случаях обычно первым делом отключается оптимизация и по-чуть чуть добавляется отладочная информация. Он сказал, что хорошо, только не падает при запуске под средой и он уже выловил место с помощью трассировки и причина непонятна. После этого я взял проект главного приложения, отключил оптимизацию, добавил отладочную инфу – не падает. Ну, для преальфы сойдет – так и ушло в инсталляцию (не знаю смотрел ли кто-то на проблему после)

2. (С++ specific) Решение подключать прекомпиленные заголовки (precompiled headers) во все проекты. Я говорю, что у меня есть опыт и хочу это сделать. Ответ: «уже этим занимается другой чел. Позвони ему и скажи если есть что посоветовать» Звоню, говорю, что обычно нужно смотреть на результат работы препроцессора и будет ответ что включать в заголовок. Поспорили на счет того убирать ли инклуды из исходников (я — за то чтобы оставить). Видя что аргументов не хватает (действительно для меня это было очевидной вещью, а ведь тяжело придумывать обоснования для очевидного), я выразил сожаление, что он не согласен, но спорить перестал ввиду бесперспективности. В итоге он просто перенес во всех библиотеках include <> из исходников в stdafx.h и на результаты работы препроцессора не смотрел. Это привело к двум проблемам:

a. проекты перестали собираться под Linux (я был уверен, что он делал и для gcc)
b. половина системного кода не была включена в заголоки.
c. Перестали собираться пару минорных проектов, которые не были затронуты измерениями — в них стало не хватать инклудов.

Но больше всего меня поразило то, как была исправлена первая проблема – заголовки были возвращены в исходники, но обернуты #ifndef _Win32 …

3. Решение изменить output директорию для поектов. Был введено два диска U: и V: на один – объектники, а на другой – бинарники. У меня опять волосы дыбом и как-бы аргументов нет. Говорю давайте я переделаю на «переменные сети окружения» — завязался спор – что лучше... Основных аргумента против было два:

a. Для изменения envvar нужна перезагрузка (как минимум VisualStudio), а для диска – «простой subst».
b. Непонятно как менять, ведь $(OutDir) – может быть и абсолютный каталог, и относительный, а проекты лежат на разных уровнях.

Я сказал что моя цель:

a. чтобы собиралось и с переменной и без (т.е. можно не задавать ее вообще)
b. чтобы можно было использовать две версии системы одновременно (- ответ «зачем такая экзотика» – опять волосы дыбом).
c. не создать проблемы тем, у кого на диске U: что-то висит.
d. Проблему b) решить можно

В итоге чела вроде не убедил, но лидер сказал «давай сделаем так, чтобы что-то сетапить не обязательно». И опять делать не мне (наверно правильно новичкам не доверять). Вроде он сделал, но опять что-то не работает, и не особо разбираясь эти изменения откатили и теперь я не могу использовать две версии одновременно и обязвтельно должен иметь диски U и V

5. Организация авто-тестов в DLL. Видя что для юнит-тестов существует один проект (почти самописный NUnit), который будет линковать все остальные DLL, я высказал мнение, что «тест engine» не должен ни от чего зависеть, а тесты – сидеть в тех же библиотеках что и тестируемый код (но компилиться только опционально) увидел полное непонимание со стороны коллег

6. для проверки условий в тестах есть макрос типа Check(explanation_string, condition). Я сказал, что в коде таким пользоваться неудобно: во-первых, если в тесте десятки проверок, то придумывать каждый раз строку для объяснения – непрактично, во-вторых — если вначале строка, а справа — условие, то такой код читать неудобно. Написал свой макрос #define MyCheck(condition) Check(#condition, condition). В ответ – тоже непонимание типа «какждый кто приходит придумывает свои правила». Дыб опять.

Есть еще другие моменты, которые я не до конца понимаю, это было остновное. Например, для связи unmanaged C++ и C# генерятся простые врапперы (они то простые, но кода уже больше 1 KLOC — это в начале разработки.) Вроде хорошо, но в начале след года нужно будет оборачивать в вебсервис и делать ту же работу заново — описывать интерфейсы на формальном языке и генерить врапперы... Не лучше ли это делать сразу и генерировать врапперы и для связи C++ и ВебСервисов и для С++ и С#...

Может ли кто-то сказать: я выпендриваюсь или мои волосы не зря дыбом становятся? (То есть, то, что волосы дыбом становятся при удивлении — не проблема. Вопрос — есть ли причина для удивления?)