Здравствуйте, Pyromancer, Вы писали:
P>Почему-то именно этот грид все любят переделывать, с чего бы это
Прошу прощения за оффтоп.
1. DataGrid, что DataGridView — чушь собачья, подходит только для самых простых задач. Лучше уж пользоваться коммерческим гридом. А в этих творениях MS много глюков и недоработок.
2. Есть проект (пока мало сотрудников, чтобы им всерьёз заняться) написать свою GUI-библиотеку, соответственно в ней будет свой биндинг (а то MSовский глючный и негибкий). Собственно, грид реализует поддержку этого биндинга.
3. Самое главное. Дело в том, что мы работаем с объектно-ориентированной базой данных. Соответственно, подходы немножко другие, нежели в случае с реляционной. Нам нужна была поддерка некоторых весьма специфических вещей.
Здравствуйте, TafT, Вы писали:
TT>Ситуация в 2-х словах такая:
skipped...
TT>Ваши комментарии.... я просто незнаю что думать. TT>Спаисбо.
Извините, бардак у вас на проекте, и виноват в этом менеджер проета или тимлид.
Начать с того что начали писать свой супер пупер грид. Купить готовый стоит не более 500$, а сейчас посчитайте сколько вы на свой потратили уже денег.
Второе, то что у вас люди работают по выходным — то-же рекомендует процесс разработки не с лучшей стороны.
Третье, наличие такого конфликта говорит о том, что в команде не прописаны правила владения кодом. Если бы была установленна политика индивидуального владения кодом, то один разработчик не стал бы править код другого. Если бы была установлена политика коллективного владения кодом, то другой разработчик не стал бы хамить первому за то что тот поправил код.
Четвертое, по всей видимости процедуры багтэкинга и тестирования у вас тоже не на должном уровне.
И т.д.
Вывод прост. Надо организовывать нормальный процесс разработки и это благотворно скажется на атмосфере в коллективе и на вашем здоровье
Здравствуйте, WhiteDev, Вы писали:
WD>В таких случаях не надо проявлять инициативу, она наказуема WD>Идешь к челу и тыкаешь носом в багу, а там его траблы, через какую Ж ему разруливать. WD>Представь, кто-то написал код с багой, кто-то его поправил не вникая в архитектуру, а после челу надо что-то расширить по новым требованиям, а там всякие кучки творения "с миру по нитке" которые решали только локальные проблемы. Вывод: его обязанность, он правит ты тыкаешь носом, на тебя возложат поддержку и развитие — ты правишь.
описаное показывает, что комманда не владеет кодом. кодом владеет один разработчик — автор.
в случае большого проекта, это ошибка.
Здравствуйте, TafT, Вы писали:
TT>Ситуация в 2-х словах такая: TT>Задумалось у нас на проекте сделать супер-грид, который бы отвечал всем требованиям проэкта, был удобен, что бы быстренько клепать страничци (ASP.NET), и все шикарно работало. Поручили это одному человечку (далее Ч). И вот, через 2 месяца мы имеем то что имеем.. а именно гемморой еще в одном месте, точнее говоря, получилось неплохо, но сыро, и багов много(А заодно и нервов, и матов в курилке от коллег по несчастью связаться с ним). Я могу понять что написать хороший контрол, а тем более грид — задача непростая и баги неизбежны, немогу я понять другого:
TT>Дедал сегодя страничку. Вставляю грид, понадобилось добавить дополнительные(additional) колонки. Добавляю, проверяю — падает. Нахожу багу — внутри грида. (Кстати, надо сказать что Ч. очень много (пусть и не оч хорошо) пишет, делает огромную работу, и даже работает по выходным, (я то работаю потому что студент и сессия)). Что бы все было быстрее, и что бы съэкономить Ч время, я правлю багу, попутно натыкаюсь на еще одну, и тоже правлю. Потом иду к Ч, объясняю ситуацию... "вот я тут исправил, посмотри пожалуста, все ли нормально, ты же лучше его(грид) знаешь.". В ответ слышу TT>- ТЫ ПРАВИЛ ФАЙЛЫ ГРИДА?!!?!? TT>- Да. TT>- Я все равно НЕ возьму изменения!!! TT>- Почему?
TT>далее он предлагает другой способ, как через Ж обойти эту багу, и добавляет: TT>- Мне пофигу, нравится тебе или нет! Я ничего делать не буду!
TT>На этом я ушел. Уже 3-й час не могу отойти.. Я человек не очень то впечатлительный, но отойти от такого не могу. Поначалу тряслись руки, хотелось плакать... Эти слова, они были сказаны с такой ненавистью ко мне... и даже не посмотрел что я делал (кстати, правил я именно ради того. что бы в ту Ж, про которую говорил Ч больше не лазить).
TT>ПС: TT>В остальном у меня отличный коллектив, со всеми прекрастные отношения. Очень нравится проект.
TT>Ваши комментарии.... я просто незнаю что думать. TT>Спаисбо.
Попробуй понять мотивацию человека, я не думаю что он всем и всегда так отвечает.
Если не получится или поймешь, что в любом случае ты не в силах повлиять на него, обращайся к менеджеру.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, TafT, Вы писали:
TT>>Ситуация в 2-х словах такая: S>skipped...
TT>>Ваши комментарии.... я просто незнаю что думать. TT>>Спаисбо.
S>Извините, бардак у вас на проекте, и виноват в этом менеджер проета или тимлид. S>Начать с того что начали писать свой супер пупер грид. Купить готовый стоит не более 500$, а сейчас посчитайте сколько вы на свой потратили уже денег.
Насколько мне известно это купленный грид, который просто подогнан именно под наши требования.
Хммм... не факт, что чел, пишущий грид совсем уж плох — может просто заработался и в отпуск пора, а начальство не пускает. Вот и гавкает. У нас тут тоже народ по 6 месяцев без отпуска — им приносишь баг, а они "это не моя проблема". Тем более, что программеры сильные — идти к медежменту жаловаться на них по таким пустякам, не сильно хорошая идея.
План действий тут уже описали. От себя могу довавить только:
1. Успокоится самому.
2. Еще раз успокоится.
3. Вызвать человека в отдельную комнату или в обед и объяснить ему что:
а) ваша часть проекта горит
б) через неделю вам сдаваться заказчикам
в) его кусок сидит на морде проекта и должен выглядеть хорошо
г) вы знаете, что он сильно завален работой
д) что бы съэекономить ему время вы пофиксили его баги
е) давайте включим эти фиксы в codebase
На ненависть особо внимания не обращать — это пройдет — думаю, тут половина программеров со стажем больше 2 лет будет злиться если студент начнет править их код
Если это не сработает, тогда уже доносить до сведения вышестоящего руководства.
Здравствуйте, stump, Вы писали:
S>Начать с того что начали писать свой супер пупер грид. Купить готовый стоит не более 500$, а сейчас посчитайте сколько вы на свой потратили уже денег.
C остальным согласен. А это оспорю. Мне НИ РАЗУ не попадался грид, который бы отвечал вобщем-то и не очень сложным требованиям(в т.ч. и из коммерческих). А если нужно что-то действительно экзотическое — тут только свой (правда, я искал гриды только для CompactFramework, но учитывая разнообразные требования к гридам, не думаю, что за 500 баксов продается вообще совсем универсальный и для обычного, и тем более для веба).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, B0rG, Вы писали:
BG>Здравствуйте, TafT, Вы писали:
BG>Хммм... не факт, что чел, пишущий грид совсем уж плох — может просто заработался и в отпуск пора, а начальство не пускает. Вот и гавкает. У нас тут тоже народ по 6 месяцев без отпуска — им приносишь баг, а они "это не моя проблема". Тем более, что программеры сильные — идти к медежменту жаловаться на них по таким пустякам, не сильно хорошая идея.
Блин, посмотрел на себя — и правда... Уже полтора года без отпуска, сам мягко но настойчиво посылаю всех с вопросам по поддержке трех прошлых проектов под предлогом "занят". Раньше делал по доброте душевной.
Все, заканчиваю проект, и гулять!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, TafT, Вы писали:
TT>и что бы съэкономить Ч время, я правлю багу, попутно натыкаюсь на еще одну, и тоже правлю. Потом иду к Ч, объясняю ситуацию... "вот я тут исправил, посмотри пожалуста, все ли нормально, ты же лучше его(грид) знаешь.".
ЗАЧЕМ было это делать, не поговорив предварительно с коллегой? Коллега может и не совсем адекватен, но объясни пожалуйста, зачем тебе делать чужую работу? Я бы поступил так: нашел багу -> поговорил с коллегой -> если тот начал бы возражать, пошел бы к начальству. А вообще, если бы кто-нибудь стал править мой код, пусть даже и с багами, _не поговорив предварительно со мной_, я бы как минимум был недоволен.
Здравствуйте, Great_Vova, Вы писали:
G_V>ЗАЧЕМ было это делать, не поговорив предварительно с коллегой? Коллега может и не совсем адекватен, но объясни пожалуйста, зачем тебе делать чужую работу? Я бы поступил так: нашел багу -> поговорил с коллегой -> если тот начал бы возражать, пошел бы к начальству. А вообще, если бы кто-нибудь стал править мой код, пусть даже и с багами, _не поговорив предварительно со мной_, я бы как минимум был недоволен.
уже давольно давно избавился от понятия "мой код".
есть понятие "моя ошибка". а вот "мой код"... это только если "сам пишешь — сам продаешь".
в остальных случаях рекомендую представить ситуацию, когда "владелец кода" однажды не выходит на работу.
бизнес должен встать? ...или лечь?
Здравствуйте, bastrakov, Вы писали:
B>уже давольно давно избавился от понятия "мой код". B>есть понятие "моя ошибка". а вот "мой код"... это только если "сам пишешь — сам продаешь". B>в остальных случаях рекомендую представить ситуацию, когда "владелец кода" однажды не выходит на работу. B>бизнес должен встать? ...или лечь?
Да все правильно. Только в данном случае "владелец кода" на работу выходит. Представь, что ты сидишь в данный момент на работе, рядом с тобой — чел. Чел вдруг тебе говорит: "знаешь, я в твоем модуле исправил то-то, то-то и то-то. скажи мне за это спасибо". Вряд ли это будет выглядеть слишком здорово для тебя.
Здравствуйте, Great_Vova, Вы писали:
G_V>Здравствуйте, bastrakov, Вы писали:
B>>уже давольно давно избавился от понятия "мой код". B>>есть понятие "моя ошибка". а вот "мой код"... это только если "сам пишешь — сам продаешь". B>>в остальных случаях рекомендую представить ситуацию, когда "владелец кода" однажды не выходит на работу. B>>бизнес должен встать? ...или лечь?
G_V>Да все правильно. Только в данном случае "владелец кода" на работу выходит. Представь, что ты сидишь в данный момент на работе, рядом с тобой — чел. Чел вдруг тебе говорит: "знаешь, я в твоем модуле исправил то-то, то-то и то-то. скажи мне за это спасибо". Вряд ли это будет выглядеть слишком здорово для тебя.
не поверишь, это было в обе стороны не раз и не два.
все проблемы решаются чисто административными методами (как уже было сказано выше).
а вообще — я бы присоединился к некоторым высказываниям по поводу первого письма.
попробую от себя еще сформулировать:
1) очень много людей пишут "свой грид". это уже даже не смешнь. я тоже писал, но это было года 4 назад последний раз.
2) давать писать базовый компонент молодому (а значит без большого опыта не только технического, но и командного) человеку холерического типа — загубить команду.
3) человек, который пишет базовые компоненты должен работать не больше (меньше можно) чем 8х5.
4) если не выполняется пункт 3 — "не трогать руками" разработчика. он опасен! вообще если человек (любой член команды) систематически перерабатывает — надо что-то делать. проект под угрозой.
5) комманда — главнее всего. я видел несколько работающих гуру, которые не могли договориться. один студент работает быстрее.
6) делать разницу между работой и своей собственной жизнью. в том числе, понимать, что со своими нервами — ночью спать, а с его кодом — даже не здороваться.
все это было сказано выше не мной, я просто повторил.
