Собственно, subj.
Стартовал контракт в одной банке. Народ пишет всю клиентскую часть на VB6. Ну и черт бы с ними, но есть у людей мощная тенденция смешивать суп с мухами, а именно: код, который я сейчас разгребаю, является жуткой смесью логики отображения с бизнесом. Текущему саппорту не подлежит, не то что каким-то обширным изменениям. Я пока даже ума не приложу, как такой код можно тестировать автоматически — а очень хочется!

Вопрос мой больше психологического плана:
Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.
Сразу скажу радикально настроенным личностям — ни дотнет, ни жаба панацеей не являются, тому есть примеры. Если я сейчас начну гнать пургу про современные средства разработки, то мне definitely укажут на дверь.

С уважением,
Александр Федин

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

A>Собственно, subj.
A>Стартовал контракт в одной банке. Народ пишет всю клиентскую часть на VB6. Ну и черт бы с ними, но есть у людей мощная тенденция смешивать суп с мухами, а именно: код, который я сейчас разгребаю, является жуткой смесью логики отображения с бизнесом. Текущему саппорту не подлежит, не то что каким-то обширным изменениям. Я пока даже ума не приложу, как такой код можно тестировать автоматически — а очень хочется!
Надо несколько "по порядку что ли" как-никак саппорт-саппортом с издержками по обработке чендж реквестов, а автотестинг-автотестингом.

A>Вопрос мой больше психологического плана:
A>Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.
Найти способ донести до людей в явной и однозначной форме результаты, являющиеся следствием использования сей парадигмы на конкретно взятом(данном) примере.

A>Сразу скажу радикально настроенным личностям — ни дотнет, ни жаба панацеей не являются, тому есть примеры. Если я сейчас начну гнать пургу про современные средства разработки, то мне definitely укажут на дверь.
А что смена технологий уже дефолтом означает изменение подхода к проектированию систем-подсистем?!

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

A>Стартовал контракт в одной банке. Народ пишет всю клиентскую часть на VB6. Ну и черт бы с ними, но есть у людей мощная тенденция смешивать суп с мухами, а именно: код, который я сейчас разгребаю, является жуткой смесью логики отображения с бизнесом. Текущему саппорту не подлежит, не то что каким-то обширным изменениям. Я пока даже ума не приложу, как такой код можно тестировать автоматически — а очень хочется!

A>Вопрос мой больше психологического плана:
A>Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.

Такие проблемы решаются, имхо, только через начальство. Напиши служебную записку, в которой:

a) опиши все обнаруженные проблемы
б) дай свой прогноз на последствия. Заодно можно ввести в понятие энтропии проекта.
в) опиши, каким способом избежать описанные проблемы. Здесь будет уместным перечислить подходящие XP-шные практики, ввести цитаты и ссылки на "Экстремальное программирование" Бека, "Рефакторинг" Фаулера, а то и "Паттерны проектирования" банды четырех. Опиши ожидаемые бенифиты, не забудь упомянуть экономический аспект.

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

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

A>Вопрос мой больше психологического плана:
A>Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.
A>Сразу скажу радикально настроенным личностям — ни дотнет, ни жаба панацеей не являются, тому есть примеры. Если я сейчас начну гнать пургу про современные средства разработки, то мне definitely укажут на дверь.

Попробуй ввести практику написания Unit Test-ов. Они очень хорошо прочищают мозги, в плане хорошего дизайна.
Ну качество соответственно повышается.
Но за все надо платить, объем работы увеличивается в 1.5-2 раза для client server, 2-2.5 для m-tier и web-app.

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

S>Такие проблемы решаются, имхо, только через начальство. Напиши служебную записку, в которой:

пункт 27

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

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


A>Вопрос мой больше психологического плана:
A>Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.

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

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

A>Собственно, subj.
A>Стартовал контракт в одной банке. Народ пишет всю клиентскую часть на VB6. Ну и черт бы с ними, но есть у людей мощная тенденция смешивать суп с мухами, а именно: код, который я сейчас разгребаю, является жуткой смесью логики отображения с бизнесом. Текущему саппорту не подлежит, не то что каким-то обширным изменениям. Я пока даже ума не приложу, как такой код можно тестировать автоматически — а очень хочется!

Сперва думайте как будете тестировать, а потом пишите — перенимайте части XP.

A>Вопрос мой больше психологического плана:
A>Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.

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

A>Сразу скажу радикально настроенным личностям — ни дотнет, ни жаба панацеей не являются, тому есть примеры. Если я сейчас начну гнать пургу про современные средства разработки, то мне definitely укажут на дверь.

Ну вы ведь код VB не в notepad пишете. И исходники в каком-нибудь SourceSafe лежат, и даже бэкапы делаются — хотя бы раз в неделю — правда? Чем не "современные средства разработки"?

P.S. А вы уверены что эта "правильность" лично вам так уж особо нужна?

Столкнулся с аналогичной проблемой.
Такое ощущение что на VB6 пишут в основном люди, которые начинали с 1С (говорю в основном дабы не обижать никого).

переписали до меня систему с asp + VB6 на asp.net но (!) ничего кроме синтаксиса из .net не взяли. и слово class осталось для них префиксм в названии файла ((.

И как теперь (и кому) сказать что с правильной реализацией ООП живется легче чем с методами по 700 строк? Это ж не просто стиль...это ж упирается все в архитектуру решения.

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

S>>Такие проблемы решаются, имхо, только через начальство. Напиши служебную записку, в которой:

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

Ну, тут уж у разных людей разный жизненный опыт. В первом своем групповом проекте я столкнулся с проблемой низкого (я бы сказал никакого) внутригруппового взаимодействия и низким же качеством применяемых архитектурных решений. Когда попытался поговорить с коллегами на эту тему, получил классический вопрос "А ты кто такой?". Характерно, что чем ниже класс программиста, тем больше вероятность нарваться на агрессивное противодействие. Кое-какие улучшения удалось продавить через PM-а. Вообще, PM своей задницей за продукт отвечает, и если убедительно довести до сведения менеджера, что его задница в опасности, думаю respose будет.

Но готов согласиться, на все случаи жизни мой совет не годится.

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

Выдержка из комментария к функции:
'--------------------------------------------------------------------
' Soliloquy by Lance:
'
' Originally, the settle and trade dates were reset here after having
' gone through 'SetDfltSettleDate' about 10 times. Before resetting,
' the trade date would be set to today and the settle to the default
' for the security.
' Later, Bob bypassed setting the settle date for TBAs as
' part of his roll logic. Which mean if you cancel correct a TBA
' your settle date could change if it wasn't the default without you
' knowing about it.
' To fix that, I put in a check for 'IsRoll'
' instead of all TBAs. That didn't fix the problem, however because the
' next thing the code did was call 'ActiveSecCtl.ReadTradeObject'. That
' sets the cash/call/put option which fires an event which ends up calling
' SetDfltSettleDate again --- thus you end up with the correct trade
' date but the default settle instead of what is on the trade.
'
' So now I have done the following:
' 1) Set the tradedate to what is on the trade, this shouldn't get touched
' after this.
' 2) Call ReadTradeObject which may call SetDfltSettleDate again and thus
' the settle date may not match the trade.
' 3) Reset the settle date to what is on the trade -- except for TBA rolls
' 4) Cross my fingers
'--------------------------------------------------------------------

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

FDS>Надо несколько "по порядку что ли" как-никак саппорт-саппортом с издержками по обработке чендж реквестов, а автотестинг-автотестингом.
Если код представляет из себя атомную смесь из презентационной логики, бизнес-логики, переменные называются "t", "s", "cp"... В качестве code reuse используются вызовы процедур типа "txtFactor_KeyUp":

If NewerFactorExists Then
    cmdUpdateFactor.Visible = True
    txtFactor_KeyUp Asc(vbCr), 0 ' Forces recalc with factor from trade
Else
    cmdUpdateFactor.Visible = False
End If

Это я еще порефакторил, в оригинале имена контролов были cmdUF и txtF...
Просто меня:

1. Блевать тянет разбираться в коде как он есть
   
2. Рефакторинг у них не принят и меня за это по головке не погладят
   
3. Юнит тесты для того кода, который есть, я писать пытался — очень большая взаимозависимость кода и его надо либо тестировать в целом, либо разводить разные сущности по углам (смотри пункт второй). Mock objects строить просто за@бешься. Но даже если и построить — кроме меня это [сейчас] никто поддерживать не будет

A>>Вопрос мой больше психологического плана:
A>>Как, не обижая людей и не подставляя свою задницу, изменить манеру написания кода в команде? Добиться, чтобы люди писали код более структурированно.
FDS>Найти способ донести до людей в явной и однозначной форме результаты, являющиеся следствием использования сей парадигмы на конкретно взятом(данном) примере.

A>>Сразу скажу радикально настроенным личностям — ни дотнет, ни жаба панацеей не являются, тому есть примеры. Если я сейчас начну гнать пургу про современные средства разработки, то мне definitely укажут на дверь.
FDS>А что смена технологий уже дефолтом означает изменение подхода к проектированию систем-подсистем?!
Для меня — не означает, но я уже получил такой совет

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

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

S>Такие проблемы решаются, имхо, только через начальство. Напиши служебную записку, в которой:

S>a) опиши все обнаруженные проблемы
S>б) дай свой прогноз на последствия. Заодно можно ввести в понятие энтропии проекта.
S>в) опиши, каким способом избежать описанные проблемы. Здесь будет уместным перечислить подходящие XP-шные практики, ввести цитаты и ссылки на "Экстремальное программирование" Бека, "Рефакторинг" Фаулера, а то и "Паттерны проектирования" банды четырех. Опиши ожидаемые бенифиты, не забудь упомянуть экономический аспект.
Хорошие и правильные слова, книги, ссылки, практики... но не в начале работы в западном банке на проекте в production...

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

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

V>Столкнулся с аналогичной проблемой.
V>Такое ощущение что на VB6 пишут в основном люди, которые начинали с 1С (говорю в основном дабы не обижать никого).
Впечатление интересное, но нереальное — страна другая. Скорее они писали на Коболе или еще каком-нибудь местном аналоге 1С

V>переписали до меня систему с asp + VB6 на asp.net но (!) ничего кроме синтаксиса из .net не взяли. и слово class осталось для них префиксм в названии файла ((.

V>И как теперь (и кому) сказать что с правильной реализацией ООП живется легче чем с методами по 700 строк? Это ж не просто стиль...это ж упирается все в архитектуру решения.
Вот я и спрашиваю: как и кому сказать? Если ответите — начальству — не факт. Был у меня прецедент несколько лет назад... Начальник просто позвонил в мою контору и попросил замену. Ну не нужен ему человек, знающий больше него!

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

O>Неинтересно это начальству, для него главное что бы очередной релиз был готов в срок, а уж качество кода его интересует в последнюю очередь. Так что данный вопрос надо решать внутри команды.
В этом-то и прикол, Олег. На свои письма я получаю ответ минимум через неделю. Или вообще не получаю...
Есть бизнес-аналисты, есть teammates, есть в конце концов менеджер. И такое ощущение, что им до 3.14зды на почту. Такого я еще не встречал!

V>>И как теперь (и кому) сказать что с правильной реализацией ООП живется легче чем с методами по 700 строк? Это ж не просто стиль...это ж упирается все в архитектуру решения.
A>Вот я и спрашиваю: как и кому сказать? Если ответите — начальству — не факт. Был у меня прецедент несколько лет назад... Начальник просто позвонил в мою контору и попросил замену. Ну не нужен ему человек, знающий больше него!

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

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

V>с другой стороны....система работает (скорее всего как надо)...а что еще руководству надо?и им не важно че да как...
А руководству надо добавить новый тип бондов. Или еще какую херь. И сделать это надо так, чтобы ничего не упало. А оно не может не упасть по причине "тесной интеграции" одного с другим. Про юнит-тесты я писал.
Написал письмо аналистам (они в другом здании), жду ответа уже второй день. Кстати, выяснил одну вещь: почту здесь люди почти не читают. Как выяснил? Не путем запроса на подтвержение о прочтении. Просто решил письмо, отправленное позавчера, немного изменить и отправить снова. В Аутлуке есть опция "отозвать письмо и заменить новым". Отзыв письма работает, если письмо еще не читали. Два дня прошло, но отзыв письма сработал!

V>у меня ситуация сложна тем, что чел который навоял ЭТО уходит через месяц...объяснять или писать доку не хочет (в коде ничего нет вообще)....мол много времени...пол года минимум говорит. (кстати по его словам и в коде комменты ставить это непозволительная роскошь по времени). А всякие нормализации и абстракции это вообще не для бухгалтерии а для умных книг, из которых он "одну какую-то прочитал и даже че-то с этими абстракциями написал, но ничего не работало так как надо"
По поводу непозволительной роскоши комментариев и всего остального:
From: Evans, Mark (cib tech)

Sent: Thursday, March 24, 2005 2:31 PM
To: Sec20Dev; SEC20QA
Cc: Fedin, Alexander
Subject: FW: Good stuff to use in development...

While reviewing Harvest/deployment functionality with Celia and Alexander, Alexander mentioned several good tools that sound like they could be of good use in automating our dev/test/deployment cycle. Maybe somebody with some “spare time” can look into them.

Думаешь, это свободное время у кого-нибудь нашлось?

-----Original Message-----
From: Jonathan Goldman
Sent: Fri 3/25/2005 9:12 AM
To: David Hunter; David Cohen; David Rader; George McDonald; Santosh Kumar Chintakayala; Dean Rucinski; Santanu Bhattacharya
Cc: Alex Fedin
Subject: RE: new employee

Welcome aboard, Alex!

I agree with Dr. Hunter's opinion, especially with regards to Cruise Control. I, too, banged my head against the wall for about an hour trying to get it to go and gave up.

While WinMerge is a better tool than, say, WinDiff... I'm old school. Give me vi, diff, and cvs and I'm good.

Jonathan J. Goldman, Architect

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

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

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

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

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

O>>Неинтересно это начальству, для него главное что бы очередной релиз был готов в срок, а уж качество кода его интересует в последнюю очередь. Так что данный вопрос надо решать внутри команды.
A>В этом-то и прикол, Олег. На свои письма я получаю ответ минимум через неделю. Или вообще не получаю...
A>Есть бизнес-аналисты, есть teammates, есть в конце концов менеджер. И такое ощущение, что им до 3.14зды на почту. Такого я еще не встречал!

пункт 19
здесь

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

A>А руководству надо добавить новый тип бондов. Или еще какую херь. И сделать это надо так, чтобы ничего не упало. А оно не может не упасть по причине "тесной интеграции" одного с другим. Про юнит-тесты я писал.

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

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

S>Кое-какие улучшения удалось продавить через PM-а. Вообще, PM своей задницей за продукт отвечает, и если убедительно довести до сведения менеджера, что его задница в опасности, думаю respose будет.

Похоже на то, что далеко не каждый ПМ в состоянии провести логическую цепочку "хреновый код->задница ПМ-а", а объяснить ему это так же малореально, как жене то, что бабло надо бы экономить, а не спускать подноль. Т.е. на словах все зашибись, тебе поддакивают, "блаблабла, крута, ты все верно говоришь, так и будем делать", а на деле результаты нулевые. Хотя, конечно, ситуации бывают разные.