Re[3]: Не выпендриваюсь ли я? - О работе

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

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

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

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

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

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

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

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

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

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

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

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

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. Перестали собираться пару минорных проектов, которые не были затронуты измерениями — в них стало не хватать инклудов.

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

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

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

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

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

C>

C>a. Для изменения envvar нужна перезагрузка (как минимум VisualStudio), а для диска – «простой subst».

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

Вы оба хороши

пользуетесь средствами билдования из Студии, а потом еще сбоку к ним ляпаете руками на соплях вписанные 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% — сказать сложно, очень многое зависит от личности лида и от личных отношений в команде.

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

Во-первых, спасибочки за ответ.

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

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

C>>если один против всех, то чаще не прав — один?
MSS>Совершенно неверно. Впрочем, во внутренней реальности людей с совковыми комплексами это действительно так

Здорово! Я почти враз поменял жизненные взгляды — уже не зря писал письмо

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

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

MSS>Когда я вижу такую вот "работу", у меня голова кружится. Почему нет регулярного билдования?

Я для себя на этот вопрос ответил так: "это будет первое чего я буду добиваться после завершения первого задания (но не дальше чем исп срок закончится)"

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

Да согласен 100%! Ну не так просто попасть в такой проект, ведь такое достижимо только в новеньких проектах (например без паровоза 20-летних шедевров, хотя это другой случай) а реально используется в <5% существующих проектов. В остальных же кто-то работает и не так-то просто даже отработав год сдвинуть машину в это направление...

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

вот решил запустить релиз на второй неделе работы — не собрался...

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

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

Разрешите оправдаться!
Эта преальфа — не имеет никакой функцианальной полезности и выпущена скорее для высшего руководства и чтобы кто хочет поимел представление о том, как все будет выглядеть.
На счет всего остального — шеф — один из нас 5-ти (знал прекрастно и сам пытался побороть) и дальше большой скачек в иерархии до непрограммистского начальства...

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

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

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

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

Да, речь именно об этом. У нас много сторонних библиотек используется (glib, libxml, ... >30), поэтому включать именно все что инклудится с угловыми скобками (<>)
Но проблема может быть то, что я в библиотеке A.dll включаю заголовок из B.dll который включает <xmllib.h>. (что в итоге и было в нашем случае). Узнать о том, что какой-то файл не включен можно только с помощью препроцессора: то, что после stdafx.h и лежит в lib — дирректориях. На анализ у меня уходит 30 сек.

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

Не пофиг

Во-первых, сразу нет возможности собрать не используя pch — например актуально для ночных билдов, чтобы требовать меньше места, а время сборки не так актуально.
Во-вторых, мне, чтобы использовать в тестовом проекте библиотеку-обертку над xmllib.dll нужно инклудить и obertka.h и xmllib.h — а если там еще какие сторонние типы или дефайны используются? — пойди потом гадай что и в какой очередности нужно инклудить стороннего, чтобы простой тестовый проект заработал...
В третьих, если я захочу собрать еще каким-то компилятором, то еще проблемы добавляются...

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

Не знаю, вылетело наверно...Пару минорных проектов — начатый тест-engine, который как-обязателен, но все его отключают и без него все работает (кстати не собирался он именно по причине того, что были удалены системные инклуды...)

C>>Но больше всего меня поразило то, как была исправлена первая проблема – заголовки были возвращены в исходники, но обернуты #ifndef _Win32
MSS>Что это были за заголовки? специфичные для Линукса? тогда разумно.

Нет же, речь идет о сторонних библиотеках. т.е. например xmllib.h

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

у линукса отдельные файлы сборки

MSS>Вы оба хороши

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

Ну, с env vars — все ок: если есть, то используем абсолютный путь (как ниже с ramdisk), если нет, — то какой-то дефолтовый или где-то прописаный...

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

Не кактит в случае если кто-то хочет "пооптимизировать" и использовать для объектников ramdisk (трое хотят) то не получится

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

да видел все шеф, мое ощущение, что чел хотел показать что этот вариант работать не будет. такое ощущение, что на лида это повлияло...

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

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

Ок, не со всем согласен, но здравого смысла тут хватает. Надо будет еше подумать.

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

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

по-моему нечитабельно или я не прав?

Check("Names are not equal", o.name()=="name");
Check("Number of elements in array incorrect", v.array().count()==5);
Check("Number of elements in second array incorrect", v.second_array().count()==6);
Check("Number of elements in First array of first object and Second array of second object are no equal", first.first_aray().count() == sec.second_array().count());

MSS>Краткие выводы:
...

Спасибо большое. Аппликабельно 90%

Здравствуйте, Sealcon190, Вы писали:

S>ИМХО ты не прав.
S>Когда станешь прожект-лидером, тогда и меняй устоявшиеся порядки. На своем опыте убедился — то, что более эффективно по сути, может обернуться проблемами для проекта если люди не привыкли или не умеют так работать. Если каждый программер начинает давать советы по оптимизации труда, ничего кроме геморроя из этого не выходит.

Ок, согласен, но я не хочу работать с проектом, который требует жестко два диска на пустом месте и для того чтобы собрать версию стояшую у клиента и работать над новыми фичами в новой версии нужно делать бекап объектников или пересобирать все заново... Где релиз собирается в последнии день перед выпуском и проекты компилятся на 40% дольше возможного...

Что только два выхода — смириться или уволиться? И какой бы выбрал ты?

Здравствуйте, Cghjcbnm, Вы писали:

C>Ок, согласен, но я не хочу работать с проектом, который требует жестко два диска на пустом месте и для того чтобы собрать версию стояшую у клиента и работать над новыми фичами в новой версии нужно делать бекап объектников или пересобирать все заново... Где релиз собирается в последнии день перед выпуском и проекты компилятся на 40% дольше возможного...

C>Что только два выхода — смириться или уволиться? И какой бы выбрал ты?

Свобода или смерть!? =)
Всегда надо стремиться ХОТЕТЬ работать, а уволиться всегда успеешь.
На мой взгляд в данной ситуации (в смысле работыешь ты не давно (там), не тимлид) ты именно выпендриваешься =) , поработай, притрешься, будешь показывать правильный вектор развития (проект то ведь длинный) и люди за тобой потянуться, в данной ситуации на мой взгляд будешь требовать правильно работать (как ты считаешь ), финал будет один — выгонять в течении месяца-двух.

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

Одно другого не исключает. Значит, _руководитель принял решение_ о том, что мини-решения на данном фронте работ принимает сам исполнитель.

C>То есть вы советуете не связываться с такими сслучаями — это же тоже не выход?

В профессиональном плане вы будете правы, в личностном — вы лезете не в свое дело, да и нарушаете негласно принятые в команде понятия о руководстве (в виде "исполнитель решает сам").

На раннем этапе работы в команде я бы (сейчас в 34 года) в чужие дела бы не лез. Но и ситуаций, когда чья-то халатность привела к тому, что проблемы на работе возникли уже у меня — тоже не допускал бы. Пусть каждый отвечает за свое.

Если команда действительно 100% дисфункциональна (что, в частности, означает профнепригодность лида) — то там карьеры не сделаешь и не вырастешь. В худшем случае — испортишь со всеми отношения, и "уйдут". В лучшем — сам уйдешь.

C>Здорово! Я почти враз поменял жизненные взгляды — уже не зря писал письмо

Немного оффтопика. Совки действительно считают, что все равны. Из гуманистического понятия "все мы люди" они делают вывод "все мы одинаковы". Из него логически следует, что в конфликте большинства с одиночкой всегда неправ одиночка.

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

Но тут много всяких подтекстов. А может, одиночка ничем не более талантлив, все его мега-идеи уже приходили в голову и всем известны, но не воплощены в жизнь по неким причинам? А есть ли смысл переделывать работающее только потому, что можно сделать лучше? Дальше идут всякие "старый конь борозды не испортит" и прочее.

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

Не говорит прямо. Возможно, слабак. Возможно, "афтар" ему уже сел на шею. Все это плохо, и минус не вам, а данной структуре.

C>Да согласен 100%! Ну не так просто попасть в такой проект, ведь такое достижимо только в новеньких проектах (например без паровоза 20-летних шедевров, хотя это другой случай)

Почему? что мешает регулярно билдовать 20летние шедевры? Вон ядро FreeBSD у нас с конца 70х тянется в значительной части, и ничего.

C>вот решил запустить релиз на второй неделе работы — не собрался...

Ну так а кому минус? за 2 недели явно продукт запускался как дебаг под средой раз эдак 500. И из них ни разу — релиз.

Как будто релизный билд есть что-то дополнительное и необязательное. На самом-то деле оно не так, разве не очевидно?

C>Разрешите оправдаться!
C>Эта преальфа — не имеет никакой функцианальной полезности и выпущена скорее для высшего руководства

И что? майлстонный релиз есть майлстонный релиз. Вопросы того, для кого и зачем его выпускают — не вопросы девелопера. Даже высокооплачиваемого software engineer. Для этого ПМ есть в том или ином виде.

А вот поддержание кода всегда в качественном состоянии, чтобы качество никаких билдов не падало ниже какой-то планки — это вот задача девелопера.

C>На счет всего остального — шеф — один из нас 5-ти (знал прекрастно и сам пытался побороть) и дальше большой скачек в иерархии до непрограммистского начальства...

Угу. Знакомо.

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

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

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

Кстати, прекомпайл — это не Си++, в обычном Си тоже вполне применим.

C>Но проблема может быть то, что я в библиотеке A.dll включаю заголовок из B.dll который включает <xmllib.h>. (что в итоге и было в нашем случае). Узнать о том, что какой-то файл не включен можно только с помощью препроцессора: то, что после stdafx.h и лежит в lib — дирректориях. На анализ у меня уходит 30 сек.

Должна быть политика, что куда включать. Скажем, если A.DLL использует libxml как внутреннюю деталь реализации, то башки от libxml не стоит включать в интерфейсную башку от A.DLL.

Но если оная интерфейсная башка ссылается на типы и константы, которые объявлены в башках к libxml — тогда другое дело.

C>Во-первых, сразу нет возможности собрать не используя pch — например актуально для ночных билдов, чтобы требовать меньше места, а время сборки не так актуально.

Все равно с PCH быстрее. Дисковое место под билд в наше время вряд ли кого волнует.

C>Во-вторых, мне, чтобы использовать в тестовом проекте библиотеку-обертку над xmllib.dll нужно инклудить и obertka.h и xmllib.h — а если там еще какие сторонние типы или дефайны используются? — пойди потом гадай что и в какой очередности нужно инклудить стороннего, чтобы простой тестовый проект заработал...

Не добавляющие функционала обертки — как правило зло. Кроме того, можно воткнуть xmllib.h в общий заголовок stdafx.h или там precomp.h, после чего вообще забыть, куда ее нужно включать, куда нет. Тоже вариант.

C>Не знаю, вылетело наверно...Пару минорных проектов — начатый тест-engine, который как-обязателен, но все его отключают

Обязателен, но все отключают.

Эффективность работы как у РФовской власти ельцинских времен.

C>Не кактит в случае если кто-то хочет "пооптимизировать" и использовать для объектников ramdisk

В нормальной команде это делается так:
— идея доводится до руководства.
— руководитель решает, заниматься ли ей, на каком моменте работ ей заниматься, и кто будет заниматься.
— после этого 1 человек (а не кто-то) — делает и так, и так, и замеряет время. Докладывает руководителю.
— руководитель принимает решение, будет ли использоваться рамдиск, причем _у всех_.

Я не верю в сильное ускорение работы с диском под NT или линуксом от использования рамдисков. У них кэширование очень хорошее.

Еще момент. Что мешает при большом ребилде всего проекта взять все исходники с сорс-контрола _на рамдиск_ и билдовать там? тоже вариант.

Сколько времени вообще делается полный ребилд самого большого бинаря в проекте? а всего проекта?

C>да видел все шеф, мое ощущение, что чел хотел показать что этот вариант работать не будет. такое ощущение, что на лида это повлияло...

Да, крепенько ему товарищ на шейку-то сел.

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

C>по-моему нечитабельно или я не прав?
C>

C>Check("Names are not equal", o.name()=="name");
C>Check("Number of elements in array incorrect", v.array().count()==5);
C>Check("Number of elements in second array incorrect", v.second_array().count()==6);
C>Check("Number of elements in First array of first object and Second array of second object are no equal", first.first_aray().count() == sec.second_array().count());
C>

Читабельно. Можно вообще только выражение и номер строки печатать. Все равно первое, что сделает девелопер, увидев такой ассерт — полезет в код, и от номера строки зачастую толку больше, чем от описания.

C>Что только два выхода — смириться или уволиться? И какой бы выбрал ты?

В тактическом плане — смириться, в стратегическом — это место работы не навсегда, и даже не надолго.

Тут, помимо прочего, еще интересная межличностная гниль вырисовывается. Похоже, малопрофессиональные, но давние сотрудники садятся на шею лиду как хотят.

У меня похожая ситуация. В команде работаю чуть больше месяца. Команда разработки софта не большая — 5 человек, а фирма занимается по большей части производством железа. У меня также как и у вас возникла куча вопросов, ответы на которые мне казались очевидны. Например:
1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?
2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???
2. А почему у вас нету Wiki, в качестве базы знаний?
3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!
4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код??? Этот вопрос был результатом 2 часового спора с девелопером который закомител код, и даже не удосужился его скомпилять перед этим.
и т.д.

Но я отношусь к этому терпеливо. Если я действительно прав, тогда рано или поздно это всплывет и у меня будет возможность сказать: "Ну я же вам постоянно об этом говорю, за что боролись на то и напоролись!" Но если потребность в моих предложениях так и не возникнет, то мне самому есть над чем задуматься, ведь мой опыт не был основан на реальной практической потребности. До этого я работал в большой софтверной компании где все уже было настроено и работало, а я только восхищался и говорил "Как все классно сделано!". Теперь я прихожу в другую компанию и начинаю "требовать", чтобы они делали все так как это делалось в моей предыдущей конторе. Я считаю, что так поступать нельзя. Наоборот я радуюсь что у меня есть возможность реально ощутить потребность в моих предложениях и когда это произойдет у меня будет достаточно аргументов чтобы убедить руководство делать именно так как я предлагаю.

Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется

X>У меня похожая ситуация. В команде работаю чуть больше месяца. Команда разработки софта не большая — 5 человек, а фирма занимается по большей части производством железа. У меня также как и у вас возникла куча вопросов, ответы на которые мне казались очевидны. Например:

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

X>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?

Простите, а чем CVS лучше VSS? Чем VSS? Не вижу никаких преимуществ (для VSS есть и клиенты для Linux, лично использовал SourceOffSite). Сейчас использую CVS — в чем-то система не дотягивает до VSS (в CVS насколько я знаю, нет полноценного лока).

X>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???

Потому, что если VC 6.0 прекрасно справляется с поставленной задачей, то нет причин переходить на VS2005.

X>2. А почему у вас нету Wiki, в качестве базы знаний?

Потому, что это "нафиг" никому не нужно.

X>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!

Потому, что на Ваше мнение всем ... пока Ваш вес внутри команды не поднимется до определенного уровня.

X>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код??? Этот вопрос был результатом 2 часового спора с девелопером который закомител код, и даже не удосужился его скомпилять перед этим.
X>и т.д.

Это зависит от политики автоматизации билдов. Если будет ночной автобилд и всем наутро придет письмо, что билд повалил Вася Пупкин, то это быстро излечит его от таких "фокусов". Я часто коммичу "некомпиляемый" код — предварительно добавив #if 0/ #endif

X>Но я отношусь к этому терпеливо. Если я действительно прав, тогда рано или поздно это всплывет и у меня будет возможность сказать: "Ну я же вам постоянно об этом говорю, за что боролись на то и напоролись!" Но если потребность в моих предложениях так и не возникнет, то мне самому есть над чем задуматься, ведь мой опыт не был основан на реальной практической потребности. До этого я работал в большой софтверной компании где все уже было настроено и работало, а я только восхищался и говорил "Как все классно сделано!". Теперь я прихожу в другую компанию и начинаю "требовать", чтобы они делали все так как это делалось в моей предыдущей конторе. Я считаю, что так поступать нельзя. Наоборот я радуюсь что у меня есть возможность реально ощутить потребность в моих предложениях и когда это произойдет у меня будет достаточно аргументов чтобы убедить руководство делать именно так как я предлагаю.

Вот это правильно

X>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется

Логично. Только случаев его полного соблюдения я никогда не видел.

X>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?

Вы точно уверены, что хотите на ходу посреди проекта менять сорс-контрол?

Понятие "все нормальные конторы" выдает узость кругозора. Например — если контора пользуется SourceOffSite, она не нормальная? а если она пользуется TFS? а если она пользуется Perforce?

Не в сорс-контроле дело тут, а в руках и мозгах. Можно и на VSS работать на порядок качественнее, чем обсуждаемая команда. А можно и на TFS запутаться.

X>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???

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

X>2. А почему у вас нету Wiki, в качестве базы знаний?

На 5 человек?

X>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!

Один из ответов "а потому, что мы использует Мантис", или "потому, что мы используем багтрекер от SourceOffSite".

X>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код???

Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".

X>Но я отношусь к этому терпеливо. Если я действительно прав, тогда рано или поздно это всплывет и у меня будет возможность сказать: "Ну я же вам постоянно об этом говорю, за что боролись на то и напоролись!" Но если потребность в моих предложениях так и не возникнет, то мне самому есть над чем задуматься, ведь мой опыт не был основан на реальной практической потребности. До этого я работал в большой софтверной компании где все уже было настроено и работало, а я только восхищался и говорил "Как все классно сделано!". Теперь я прихожу в другую компанию и начинаю "требовать", чтобы они делали все так как это делалось в моей предыдущей конторе. Я считаю, что так поступать нельзя. Наоборот я радуюсь что у меня есть возможность реально ощутить потребность в моих предложениях и когда это произойдет у меня будет достаточно аргументов чтобы убедить руководство делать именно так как я предлагаю.

+1.

X>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется

На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Cghjcbnm, Вы писали:

C>Ок, согласен, но я не хочу работать с проектом, который требует жестко два диска на пустом месте и для того чтобы собрать версию стояшую у клиента и работать над новыми фичами в новой версии нужно делать бекап объектников или пересобирать все заново... Где релиз собирается в последнии день перед выпуском и проекты компилятся на 40% дольше возможного...

C>Что только два выхода — смириться или уволиться? И какой бы выбрал ты?

Если проект мне реально интересен, а атмосфера в команде здоровая, то никакие два диска на пустом месте и другие сопутствующие неудобства погоды не делают. Тем более что по мере зарабатывания авторитета ситуацию можно ненавязчиво менять.

Здравствуйте, AntZ, Вы писали:

X>>У меня похожая ситуация. В команде работаю чуть больше месяца. Команда разработки софта не большая — 5 человек, а фирма занимается по большей части производством железа. У меня также как и у вас возникла куча вопросов, ответы на которые мне казались очевидны. Например:

AZ>Эх, молодежь, все то вы думаете что самые умные. Ничего личного, это я по доброму

X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?

AZ>Простите, а чем CVS лучше VSS? Чем VSS? Не вижу никаких преимуществ (для VSS есть и клиенты для Linux, лично использовал SourceOffSite). Сейчас использую CVS — в чем-то система не дотягивает до VSS (в CVS насколько я знаю, нет полноценного лока).

В CVS идеология работы немного отличается. Например полноценный лок там не нужен по идеологическим причинам

X>>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???

AZ>Потому, что если VC 6.0 прекрасно справляется с поставленной задачей, то нет причин переходить на VS2005.

С этим не поспоришь.

X>>2. А почему у вас нету Wiki, в качестве базы знаний?

AZ>Потому, что это "нафиг" никому не нужно.

Но всетаки я поставил, и оказалось что это очень полезная штука

Например теперь всякую мелоч которая возникает в голове разработчики и тестеры заносят туда. Например идеи, предложения, полезные ссылки и т.д. Такое вот внутриконторное социальное комьюнити или лучше — общая доска куда можно писать. Теперь со стороны начальства возникают пожелания туда еще и все важные документы переносить, а также чтобы система автоматического тестирования туда заносила результаты.

X>>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!

AZ>Потому, что на Ваше мнение всем ... пока Ваш вес внутри команды не поднимется до определенного уровня.

С этим тоже не поспоришь.

X>>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код??? Этот вопрос был результатом 2 часового спора с девелопером который закомител код, и даже не удосужился его скомпилять перед этим.
X>>и т.д.

AZ>Это зависит от политики автоматизации билдов. Если будет ночной автобилд и всем наутро придет письмо, что билд повалил Вася Пупкин, то это быстро излечит его от таких "фокусов". Я часто коммичу "некомпиляемый" код — предварительно добавив #if 0/ #endif

На предыдущих местах работы (а их было 3), везде была аксиома "В системе контроля версий хранится только компилируемый код — не обязательно работающий"

И этому есть достаточно весомые объяснения: к примеру, несколько дней тому назад, у нас в конторе два программиста чуть не подрались из-за того что один закомител код, который предварительно не проверил

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

X>>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется

AZ>Логично. Только случаев его полного соблюдения я никогда не видел.

А я видел, когда "коммитер" мне постоянно отпинывал обратно мои коммиты и говорил что не будет вносить мой код в CVS пока я не выровняю строки по 80 символов

X>В CVS идеология работы немного отличается. Например полноценный лок там не нужен по идеологическим причинам

Было бы интересно, если бы раскрыли идеологию CVS. CVS меня не напрягает, более того перестал пользоваться GUI практически — лочить не надо, а коммитить из командной строки хорошо.

AZ>>Логично. Только случаев его полного соблюдения я никогда не видел.

X>А я видел, когда "коммитер" мне постоянно отпинывал обратно мои коммиты и говорил что не будет вносить мой код в CVS пока я не выровняю строки по 80 символов

80 символов — это лишь малая часть Coding Standards. У нас были десятки правил, только их никто не проверял, потому как автоматической тулзы не было, а ручками это делать никому не хотелось

Здравствуйте, Maxim S. Shatskih, Вы писали:

X>>1. А нафига вы юзаете VSS ведь это отстой по определению, и все нормальные конторы юзают либо CVS либо Subversion?

MSS>Вы точно уверены, что хотите на ходу посреди проекта менять сорс-контрол?

Нет в этом я уже совсем не уверен. Но если проекту 10 лет, то всетаки когдато нужно это делать?

MSS>Понятие "все нормальные конторы" выдает узость кругозора. Например — если контора пользуется SourceOffSite, она не нормальная? а если она пользуется TFS? а если она пользуется Perforce?

MSS>Не в сорс-контроле дело тут, а в руках и мозгах. Можно и на VSS работать на порядок качественнее, чем обсуждаемая команда. А можно и на TFS запутаться.

Согласен.

X>>2. Почему мы еще не перешли на Visual Studio 2005 а все еще юзаем 6.0???

MSS>Мдаа... расскажите нам (аудитории форума), в чем смысл версио-мании и гонки за последними версиями, особенно в условиях, когда речь о большом объеме старого кода.

Ну смысл наверное в том, что время идет, средства меняются в лучшую сторону, новые команды (конкуренты) осваивают новые средства разработки, и скорее всего в этом имеют преимущество перед теми кто уже 10 лет ковыряет старое и боиться переходить на новое. Слово боязнь тут ключевое. Именно боязнь перед всем новым сейчас тормозит развитие в конторе. Когда тим лид говорит не нужно использовать механизм исключений в Си++ потомучто сам с ним не знаком и часть разработчиков тоже — это тоже самое. Такая же боязнь и перед MSVC 2005.

Но всетаки переход запланирован. Причиной оказалось то, что майкрософт больше не поддерживает 6.0

X>>2. А почему у вас нету Wiki, в качестве базы знаний?

MSS>На 5 человек?

Сегодня уже 5 человек путаются и не могут мне объяснить как должно работать приложение. А когда по вашему нужно вводить базу знаний в конторе?
Я не считаю что именно wiki должно быть инструментом, можно и доки писать. Но разработчиков которые привыкли только писать на форумах, проще попросить записывать в wiki чем писать документы и еще кудато выкладывать.

X>>3. А почему вы не используете Jira в качестве багтрэкинга? Ведь по опыту я знаю что это перфект!

MSS>Один из ответов "а потому, что мы использует Мантис", или "потому, что мы используем багтрекер от SourceOffSite".

Хорошо вам. А вот мы используем какую то табличку завязанную на Access

X>>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код???

MSS>Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".

Хороший вопрос. Ответ (как мне кажется): потомучто к старому девелоперу привыкли как и к 6.0-й студии а нового видимо страшно брать, а то начнет еще революционные идеи толкать вместо работы

X>>Но есть вещи на которые я могу привести аргументы в любой момент, например "Codestyle необходим, как и его соблюдение всеми членами команды!", и не одному тимлиду неудастся отвертется

MSS>На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.

Поэтому я предлагаю взять готовый кодестайл и принять его

Здравствуйте, AntZ, Вы писали:

AZ>Было бы интересно, если бы раскрыли идеологию CVS.

здесь

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

X>Ну смысл наверное в том, что время идет, средства меняются в лучшую сторону, новые команды (конкуренты) осваивают новые средства разработки, и скорее всего в этом имеют преимущество перед теми кто уже 10 лет ковыряет старое и боиться переходить на новое.

Все это называется "словеса из глянцевых журналов". Темпы развития ИТ сейчас сильно упали по сравнению с 90ми годами, это раз. С 2000ного года появилась всего одна серьезная новая технология — .NET, все остальное было уже в 2000.

Ну и, понятно, если проект не использует .NET, то толком его технологическая база не изменилась со времен этого самого MSVC 6.

X>Слово боязнь тут ключевое.

Скорее "нежелание гимора", чем боязнь.

X>Именно боязнь перед всем новым сейчас тормозит развитие в конторе.

В обсуждаемой конторе бардак, и она не может нормально работать, перейдут они на новое или нет.

Уж что-что, а версия тулов, которыми пользуется девелопер, вообще дело третьестепенное.

X>Когда тим лид говорит не нужно использовать механизм исключений в Си++ потомучто сам с ним не знаком и часть разработчиков тоже — это тоже самое.

С++ exceptions имеет чудовищные недостатки, которые очевидны как раз тем, кто знает этот механизм хорошо. Он ухудшает понятность кода. Запрещать его совсем? смотря где. В особо ответственном системном или алгоритмическом коде — да. В чем-то вроде UI — нет.

Кстати, при чем тут C++ exceptions, которые появились в начале 90х, и "новое"?

X>Сегодня уже 5 человек путаются и не могут мне объяснить как должно работать приложение.

Так это проблемы _в этих человеках_, а не в наличии или отсутствии базы знаний.

MSS>>Один из ответов "а потому, что мы использует Мантис", или "потому, что мы используем багтрекер от SourceOffSite".

X>Хорошо вам. А вот мы используем какую то табличку завязанную на Access

Если правильная табличка — то все у вас хорошо. Хотя я предпочитаю интранетовские багтрекеры, пусть и на PHP/MySQL написанные.

X>>>4. Вопрос тимлиду: Почему вы разрешаете в VSS комитить некомпилябельный код???

MSS>>Вот это — дело. Тут скорее вопрос — "почему вообще терпите такого слабого девелопера".
X>Хороший вопрос. Ответ (как мне кажется): потомучто к старому девелоперу привыкли как и к 6.0-й студии а нового видимо страшно брать, а то начнет еще революционные идеи толкать вместо работы

Боязнь нового а) в значительной степени преувеличена б) в этой конторе не главное. Главное — профессиональная слабость персонала.

MSS>>На моей бывшей работе codestyle вырабатывали 4 лида целый рабочий день минимум (или два, не помню уж), и консенсусу — кроме совсем основополагающих вещей — не пришли.

X>Поэтому я предлагаю взять готовый кодестайл и принять его

Тогда лиды потратят 2 дня на то, чтобы выяснить, какой именно готовый codestyle они хотят.

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

Кроме того, хорош _любой_ codestyle, если он читаем. Цель введения codestyle — вовсе не унификация, а повышение читаемости кода.

	От:	Cghjcbnm
	Дата:	15.07.07 11:53
	Оценка:

	От:	Maxim S. Shatskih
	Дата:	15.07.07 12:30
	Оценка:	18 (3) +1

	От:	Sealcon190
	Дата:	15.07.07 12:57
	Оценка:	2 (1) +3

	От:	Cghjcbnm
	Дата:	15.07.07 14:00
	Оценка:

	От:	Cghjcbnm
	Дата:	15.07.07 14:08
	Оценка:

От:	xfruit	http://floomby.ru
Дата:	15.07.07 15:34
Оценка:	3 (2) +2

	От:	minorlogic
	Дата:	15.07.07 17:32
	Оценка:	1 (1) +2

	От:	AntZ
	Дата:	16.07.07 07:55
	Оценка:

	От:	SP_
	Дата:	16.07.07 08:55
	Оценка:

	От:	alion
	Дата:	16.07.07 11:32
	Оценка: