Руслан, очень хотелось сострить, по вашему подобию, но сдержусь. Да, я абсолютно серьёзно, юнит тесты не позволяют решить проблему наличия багов в приложении. Позволяют уменьшить их количество, но никак не решить проблему их наличия.

Угу, именно это я и написал выше =)

Профессионализм здесь не при чем. Профессионализм это не означает, когда всё подряд нравится, это означает, что работа будет сделана качественно вне зависимости от нравиться/не нравиться.

Детективы люблю читать. Мне легко придумать, что могло бы быть более интересным.

3. угу, но это не безболезненный путь, тем более через сервер и коротко-живущий бранч.

Множественные рабочии копии часто полезны, иногда очень.

Могу лишь сказать «не часто полезны, но иногда очень». У всех разный опыт, конечно когда-то полезны, когда-то нет. Спасибо, но на java не хочу работать =), я прекрасно работаю в проекте с переключением между production, qa-staging, pre-staging, dev, just-ci и ещё куче веток, DVCS мать его так и нормально написанные миграции для DB. Это раз уж мы начали рассматривать частные случаи, вместо оригинального топика.

В том, что это скучно, и в том, что не в деньгах счастье.

Ага, так и записываем. С проектами, которые имеют одинаковые по названию и разные по содержанию конфиги, дела не имели. С проектами, которые в различных поддерживаемых ветках работают с несовместимыми базами данных, дела не имели.

Сомнительные выводы.

сделать кого-л./что-л. — винительный падеж. Проверяем:

сделать (кого/что) две (каких) рабочих (кого/чего) копии.

нашёл правило nekin.narod.ru/...th/numerals.htm, читать с «И без того сложные», вобщем я был прав, сложная штука русский язык

Все равно вы время ото времени чаи гоняете на работе. Не ви...

Пожалуй сознательно пропущу это.

Кроме того, если известно, что есть N веток софта, в которые по желанию левой пятки или по факту инцидента надо коммититься, то разумно загодя держать по working copy каждой поддерживаемой ветки.

Для меня разумнее иметь систему контроля версий, которая позволяет дёшево переключаться между ветками и легко мёрджиться (привет git, hg). Избавляя о лишних заботах о настройке конфигураций и их поддержке.

Кроме того, если известно, что есть N веток софта, в которые по желанию левой пятки или по факту инцидента надо коммититься

Разумно если это не DVCS (т.е. переключение между ветками это целая песня) и если кофигурация легко настраивается, а это бывает далеко не всегда. Написан ли проект хорошо или плохо это дело третье, так же как и не единственный фактор который влияет на сложность конфигурации. «Виртуализация и сопутствующие решения» для такой задачи как «переключиться на другую ветку» выглядят для меня как overkill, хотя в каком-то частном случаем могут и быть полезны.

В случае веб-проектов, если они, конечно, написаны не сосвем через пень-колоду, настроить два (три, четыре, много) не соприкасающихся окружения почти тривиально

Настроить конечно, а вот поддериживать потом, может быть занятием не из весёлых.

Я что-то пропустил или изготовить патч даже между несколькими ревизиями с последующим применением в другой копии стало вдруг тяжкой, непосильной задачей?

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

Думаю это всё уводит беседу не туда.

Вцелом я не вижу пользы дальше вдаваться в технические детали различных стратегий работы с VCS, предлагаю вернуться к начальной иронии о рабочих копиях и её смыслу. Ни наличие нескольких рабочих копий, ни наличие одной не является решением одним и на все случаи жизни. Думаю автор статьи в курсе этого, а факт того, что «нужно как-то сохранить текущую работу» остаётся фактом. Но ваша ирония звучала как-будто существует всем давно известный подход, который позволяет эту проблему решить и подход этот «несколько рабочих копий», а это не так. Это не серебряная пуля и всего лишь один из вариантов решения.

«две рабочих копии».

почему? я думаю «две рабочие копии» правильно.

1) Полный чекаут — может занять длительное время, правда только в первый раз.

2) Далеко не всегда, как в случае веб проектов, веб сервисов и дургих проектов сильно зависящих от конфигурации окружения, это будет приемлимым. Два чекаута означают две настройки окружения, это может быть жутко неудобно, если вообще возможно. (и двойной майнтейн этих настроек, даже если возможно)

3) Два чекаута в централизированных системах могут легко стать проблемой, если возникнет потребность перенести изменения из одной рабочей копии в другую минуя центральный сервер.

В общем, в случае DVCS я вообще не вижу смысла в таком подходе в описанном контексте, в случае CVCS я бы предпочёл shelving, т.к. это избавляет от всех трёх пунктов. Мой котёнок забился в угол и зашипел, когда я предложил ему сделать две рабочии копии.

А о какой VCS идет речь? Если SVN/TFS/Perforce — придётся переключиться на другую ветку, текущий под положить в какой-нибудь shelve. Если это git/hg, процесс похожий с той разницей, что можно изменения не шелвить, а закомитить в локальную веточку или просто в текущую, а потом вернуться. В любом случае это и есть «сохранив код над которым идет работа», уверен автор в курсе всех этих подходов, но неуверен, что ваша ирония уместна.

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

Профессионализм здесь не при чем. Профессионализм это не означает, когда всё подряд нравится, это означает, что работа будет сделана качественно вне зависимости от нравиться/не нравиться.

Как-то неправильно выдерать фразу из контекста и применять её в общем случае. Это я про то, что изначально под «копанием в чужом коде» понималось копание в коде из статьи, который судя по всему не блещет качеством. Неправильно брать и применять это в общем случае.

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

1. Забавно, «чужой код» — код который написан не мной (чужим, отсюда и название).

2. Несомненно, но там напсано, что «хороший челлендж» приносит удовольствие, челлендж, который не приности удовольствия, скорее всего плохой.

Почему-то автор не учавствует в обсуждении своего топика.

Бэклог? не, не слышали..

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

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

Также я не понял поинт про уменьшение кол-ва багов, кот. находят пользователи за счёт написания юнит тестов. Нет я понимаю, что потратив большее время на анализ/рефакторинг кода и покрытие его тестами, вероятность _нахождения_ багов увеличивается, но в абсолютных понятиях проблему это решить не может, т.к. баги могут быть разного рода: юзабилити, неверное решение (т.е. вам кажется, что он оверное, а оказалось нет). Т.е. сокращение кол-ва багов за счёт большего времени потраченного на работу и анализ кода это разумный аргумент, но тесты лишь средство и даст именно _сокращение_, может это и имелось в виду, но just to be clear.

Challange сомнительный, несомненно это именно челендж, но интересно ли копаться в чужом коде? Приводить его в порядок, да ещё и в продукте, которые не ты развивал, не начинал и не видишь дальнейшего светлого будущего (добавления фич и т.п.) Вот что я думаю по поводу чтения плохого кода: twitter.com/...5620737/photo/1

А также переписывание и рефакторинг легаси кода это большой риск, но учитывая преимущества, проще попросить прощения, чем разрешения =)

Со всем согласен, а на пункт 3 ответ «нисколько», юнит тесты не позволяют решить проблему наличия багов в приложении.

Вы странный, меня очень привлекают 73% не очень переборчивых девочек.

Проблема в том, что несмотря на нельзя, это происходит.

Кодят на си и на асме без изучения математики.

Можно сказать то же самое и про джаву и c# - без должного изучения продвинутых техник ООП и архитектурных принципов на них нельзя кодить (но кодят же сцуки).