C>Пришел в интересную компанию в небольшую команду (5 чел).
C>Проект интересный, сложный, команда распределенная. Первая фаза — еще 6 мес. Дальше доработки еще год как минимум. (чтобы было понятно, что "тяп-ляп" тут будет больно).

Мой случай. Практически во всем.

C>Через месяц понял, что "команда" раз за разом принимает решения, от которых у меня волосы дыбом становятся.

Команда не может принимать решений. Решения принимает руководитель.

C>С одной стороны — ну явно как-то не "по-взрослому", а с другой — если один против всех, то чаще не прав — один?

Совершенно неверно. Впрочем, во внутренней реальности людей с совковыми комплексами это действительно так

C>Хотя не скажу что против всех — как правило я пытаюсь показать недостатки решения кому-то одному

Недостатки надо показывать _шефу_, а не "кому-то одному".

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

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

Когда я вижу такую вот "работу", у меня голова кружится. Почему нет регулярного билдования? почему вообще приоритет отдается дебаг-версиям, как у первокурсника начала 90х, мучающего Турбо Си 2.0?

Практически все нажатия на кнопочку Build (или команды командной строки build и make) должны делаться _в релизную версию_. Дебаг версия строится только тогда, когда уже есть замеченный баг, и без развитых средств отладки с багом не разобраться.

Почему продукт практически никогда не запускается НЕ под средой? Кстати, еще одно преимущество build.exe над средой — нет понятия "запущено под средой", все всегда запускается почти тем же образом, что будет у юзера.

Бардак тут — капитальный. Решения а) процедуры частого билдования и хотя бы минимального тестирования на машине _с пустой ОС без среды_ б) ненавязчивый переход девелоперов на то, чтобы строить и мучать в первую очередь релизные версии.

К вам тоже серьезный вопрос. У вас проект, где "тяп-ляп" будет больно. Почему вы позволяете себе выпустить наспех залатанное в билд продукта, который будет доступен пользователям? почему не была выяснена причина бага? не получается быстро — доклад шефу, пусть он решает. Почему девелопер без шефа берез на себя ответственность выпустить серьезный майлстон с заплаткой наспех?

Тут речь о нахождении баланса между сроками выхода "майлстонного релиза" и качеством, а такой баланс может найти только человек, играющий роль ПМ, а не девелопер и не архитектор.

C>2. (С++ specific) Решение подключать прекомпиленные заголовки (precompiled headers) во все проекты. Я говорю, что у меня есть опыт и хочу это сделать.

А что — у кого-то нет такого опыта?

C>Ответ: «уже этим занимается другой чел. Позвони ему и скажи если есть что посоветовать» Звоню, говорю, что обычно нужно смотреть на результат работы препроцессора и будет ответ что включать в заголовок.

Вместо того, чтобы смотреть на инклюды в исходнике — смотрим на результат препроцессирования. Знаете, это уровень "ковыряюсь отверткой в ухе — звук пропал".

Одна из хороших эвристик, что тянется еще из MFC — в прекомпайл включать только _платформенные_, не вами написанные заголовки, т.е. те заголовки, которые вы никогда не будете редактировать.

C>Поспорили на счет того убирать ли инклуды из исходников (я — за то чтобы оставить).

Не пофиг? время на споры только тратить.

C>

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

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

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

Что это были за заголовки? специфичные для Линукса? тогда разумно.


C>3. Решение изменить output директорию для поектов. Был введено два диска U: и V: на один – объектники, а на другой – бинарники.

Мдаааа.... то есть в систему билдования жестко вшиты конкретные буквы томов? а на Линуксе это как будет работать?

C>

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

Вы оба хороши пользуетесь средствами билдования из Студии, а потом еще сбоку к ним ляпаете руками на соплях вписанные env vars и буквы томов.

Правильно так: а) убедиться, что в студиевском файле проекта вообще нет абсолютных путей б) создать директорию на абы какой машине абы какой глубины как рука возьмет, единственное условие — на машине должна быть Студия в) поставить эту директорию в сорс-контроле как локальную г) взять с сорс-контрола все дерево д) запустить Студию дабл-кликом на файл проекта е) нажать там кнопку Build. Все.

При наличии чужих библиотек, что не дают со Студией, все чуть усложняется.

C>В итоге чела вроде не убедил, но лидер сказал «давай сделаем так, чтобы что-то сетапить не обязательно».

Вот это слова не мальчика, но мужа.

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

Человек не исполнил команду лида, и создал вам проблемы в работе. Вы поставили лида в известность?

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

Правильно. При их подходе тестируется ровно тот же бинарь, что пойдет клиенту. Ваш подход имеет право на существование для тестирования каких-то интересных мест в пределах 1 бинаря, но для тестирования целых бинарей их подход лучше.

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

Тоже они правы. Это лично вам неудобно так писать, а у них так принято.

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