iv_an_ruА если выпускается средство разработки, то всегда есть риск, что аппдевелопер ненароком написал нечто, зависящее от недокументированных (и потому не тестируемых) особенностей поведения.
В одной хорошей книжке мне запомнилась среди прочего фраза: "Часто говорят, мол, мы должны быть справедливы к старине Джиму, ведь он уже двадцать лет у нас работает. На самом же деле первое, о чём надо думать - мы должны быть справедливы к двадцати талантливым подчинённым старины Джима и дать им адекватного руководителя".

Я понимаю этот аргумент и отношусь к нему примерно так же: надо быть справедливым не только к этому аппдевелоперу, но и к тем, кому станет лучше, если забить на хакера, выкопавшего себе ямку. Скажем, в Оракле времён девятой версии была следующая особенность: если выполнялся оператор select into, то в случае no_data_found переменные сохраняли старые значения, а в случае, например, исключения при вычислении пятого выражения select-а первые четыре успевали попасть в соответствующие переменные. Можно написать как-то ориентирующийся на это код? Можно. Нужно? Нафиг-нафиг. А вот теперь - я бы очень не хотел, чтобы компания Оракл из-за какого-девелопера, заострившегося на эту недокументированную фичу, оставила бы версию 9.2 навечно.

iv_an_ruА теперь memory стало enough, и он стал запускаться успешно :(
У меня в те времена была просто дикая ошибка, я её два года искал. Суть: обработчик 1C состоит из нескольких в принципе независимых блоков. Каждый блок поотдельности - работает. Два, три, четыре в любом порядке - работают как часы. Все вместе - программа чуть поработает и намертво вешает комп. Отключишь один-два случайно выбранных блока - работает как часы.

Повзрослее-поопытнее, наверное, быстро бы справился, а так... уже и не вспомню, как в конце концов сообразил, что изредка, при вызове в неудачный момент времени, не хватает оставшегося места в дос-овском стеке (том, который stacks=10,256), и вероятность этого тем выше, чем больше кода собирается размещать там свои локальные переменные.

iv_an_ruИдея не в том, чтобы 9.2 навечно, а в том, чтобы это при прочих равных не менялось при обновлении с 9.2 на 9.2.1, а осталось стабильным до 10.0.
Если 10.0 при этом выйдет в разумные исторически сроки, я в общем не имею ничего против этой идеи, хотя и не скажу, что "за". Тут, кстати, нетрудно привести обратные примеры интересов между "коробкой" и "разработчиком". Лично мне удобнее, чтобы доработки любого используемого мной инструмента шли частыми небольшими порциями, то есть появилась фича - обдумал - применил - появилась - обдумал - применил. Это по сравнению с "ждёшь - ждёшь - давно надо - ждёшь - обещают, что будет - ждёшь - ждёшь - получаешь вагон всего нового, в котором ещё полгода разбираться". А, например, какому-нибудь бухгалтеру даже та самая кнопка на сантиметр вправо очень нужна, но только после сдачи годового баланса, ни в коем случае не раньше.

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

chpashaкак быть с теми кусками кода, которые хочется переписать именно потому, что их невозможно тестировать?
Что именно подразумевается под "невозможно"? Я вижу разные варианты ответа в зависимости от конкретного смысла "невозможно".

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

Новый Года как быть с тем, что есть code owner,
Смотря что понимать под этим словом. Если "чувак, который сидит задницей на этих файлах", то убивать как концепцию вне всякой зависимости от обсуждаемого вопроса. Если "человек, который лучше других понимает, что здесь, почему и зачем", то мне очень не нравится слово owner, а по сути - если "желающий переписать" чувствует себя недостаточно уверенным, можно и нужно посоветоваться.

Новый Годт.е ответственный за код один человек, а делает фикс другой.
Бред, простите. За код ответственен каждый, особенно тот, кто его меняет.

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

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

Новый ГодCode owner это тот, кто сидит на файлах
Убивать концепцию это вот точно война
Я не вижу смысла обсуждать наилучший материал для лопаток турбин применительно к самолёту с паровым двигателем. Для начала стоит поменять двигатель на тот, что способен летать.

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

А теперь маленькая ремарка, зачем я это рассказал. Всё это происходило в первых числах сентября 1998-го года. Когда вопрос "будет ли клиент, на проекте которого заняты 80% сотрудников фирмы, платить за очередные этапы того, что пойдёт в эксплуатацию в лучшем случае в феврале" был ве-есьма актуальным.

Новый Годно сейчас я в другой ситуации -- в software company top 5 worldwide
Дык в том-то и дело, что чем больше команда и проект, тем больше нельзя "сидеть на файлах".

Новый Годи сложный такой, что за полдня ничего не сделаешь (да и за год тоже)
Вот эти слова я слышал для самых разных проектов :)

Новый Годв такой ситуации не повыпендриваешься
Повыпендриваться можно всегда, но, надеюсь, это не самоцель. Драматичности будет поменьше, но тем не менее, чем больше людей и задач - тем чаще нужно сделать что-то в файле, owner которого в командировке или ближайший месяц загружен другим супер пупер важным заданием.

Новый Годда и нет ничего плохого, что есть code owner. в конце концов hotfix можно сделать и без code review, толко официальный фикс нельзя, и те изменения, кот. пойдут в релиз
Если owner понимать как code review, то в этом действительно нет ничего плохого.

17-77конкретно про это - я не знаю как в других местах, в .NET все ошибки можно обрабатывать централизовано, отрабатывая событие вроде "OnException" у Application.
При всей моей любви к Application.OnException, обработка ошибок - это иногда что-то большее, нежели MessageBox("Всё плохо! :(").

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

Поясню на примере: допустим, мы тестируем бизнес-функцию "клиент получает по почте отчёт о своих расходах за последний месяц". Для того, чтобы сказать "эта бизнес-функция работает" нам совершенно неинтересно искать ответ на вопрос "работает ли запрос в СУБД", "работает ли почтовый интерфейс" и так далее. Они нам не нужны. Нам нужно и интересно следующее: сделать за месяц десять расходов, нажать кнопку, найти в почтовом ящике письмо и увидеть, что цифра в нём равна сумме десяти сгенерированных нами расходов. Если почта работает с ошибками, но код умеет эти ошибки обходить или преодолевать - хотя бы тупой перепосылкой - функция работает, и именно это нам важно. Напротив, нам наплевать на самый идеально реализованный почтовый модуль, если функция его криво вызывает и данные не приходят, приходят не туда или не так.

chpashaв противном случае, нужно сначала писать нечто, что хоть какими-то правдами и неправдами сможет "тестировать" существующего монстра (а это в зависимости от ситуации может быть либо почти невозможно, либо возможно, но с неоправданно большими затратами времени и усилий).
Вынужден признать, полномасштабное автоматизированное тестирование я развернул на проекте, где оно довольно просто делалось штатными средствами самого проекта. Скажем, под спойлером - полный текст теста передачи lob-ов с клиента на сервер.



В то же время насчёт больших, да ещё неоправданно, затрат времени и сил, в общем случае таки не соглашусь. У меня относительно мало опыта с покупными монстрами типа TestComplete, больше с собственными наработками, уверяю Вас - цена более чем оправданная даже для одного серьёзного продукта.

chpashaсобственно я о чем : по-моему скромному мнению ваше утверждение о нонсенсе переписывания без тестов кажется мне черезчур категоричным (или я его неверно интерпретирую?)
"Нонсенс" там - не моё слово, я отвечаю на утверждение про "переписывание - нонсенс" и имею в виду "без тестов - может быть и нонсенс, а с тестами - можно и нужно".

chpashaна моем опыте, была масса случаев, где очередность переписать, а потом тестировать себя оправдывала,
Не собираюсь спорить. Бывает даже так, что оптимально просто переписать и потом ещё раз руками простестировать. Но это уже немного другое переписывание, не то "попутное с основной задачей", о котором мы говорим с лёгкой руки ShSerge-а.

chpashaно вот тестов для нее не существует в природе и возможность таковых весьма призрачна в виду полной неструктурированности кода.
Формат кода не может и не должен иметь отношения к наличию и структуре тестов. Подмена "тестов" "юнит-тестами" - имхо опасное заблуждение.