Page 1 of 1

Методика/ Процесс разработки

Posted: Tue 18 Feb, 2014 16:22
by fml2
Меня иногда занимает вопрос, откуда в Фаре появляются баги в таких местах, над которыми, вроде бы, никто не работал. Например, вот этот последний случай (просто как пример, можно привести и другие): ведь вроде нигде не было жалоб по поводу командной строки. Как же она тогда сломалась? Неужели в Фаре все так тесно связано, что изменения в одном месте могут вызвать побочные эффекты в совершенно (казалось бы) не связанных с ним местах?

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Tue 18 Feb, 2014 16:33
by 2useven10
Соблазн велик...
Но пусть лучше именинник ответит.

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Tue 18 Feb, 2014 19:43
by DrKnS
fml2 wrote:Меня иногда занимает вопрос, откуда в Фаре появляются баги в таких местах, над которыми, вроде бы, никто не работал. Например, вот этот последний случай (просто как пример, можно привести и другие): ведь вроде нигде не было жалоб по поводу командной строки. Как же она тогда сломалась? Неужели в Фаре все так тесно связано, что изменения в одном месте могут вызвать побочные эффекты в совершенно (казалось бы) не связанных с ним местах?
То, что конкретно в вашем поле зрения "нигде не было жалоб по поводу командной строки", к сожалению, не означает, что их нет в природе.
Например, возьмите версию 3793 (или древнее) и пропробуйте установить этот ваш формат в "$@".

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

Второй сводится к "сделать нормально". Иногда для того, чтобы "сделать нормально", приходится залезать в "совершенно (казалось бы) не связанные места".
К сожалению, тут надо немножко больше думать и есть риск "вызвать побочные эффекты".

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

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Tue 18 Feb, 2014 21:02
by 2useven10
Делать хорошо - это хорошо.
Делать плохо, называя это хорошо - очень плохо.
В том темпе, в каком делаются хорошие изменения сейчас, сделать их хорошо нельзя.
Просто нет времени на разборки и отделение мух от котлет, когда всё закатывается под асфальт.
Присыпанные песочком рефакторинга и постоянно вылезающие из самых неожиданных
мест баги тому подтверждение (благо если уши видны сразу, но далеко не всегда так везёт).
Пятикратные проходы рефакторинга по одним и тем же местам из той же серии.
Сам по себе процесс ничем не плох. Если бы он шёл постепенно и в один скромный
'рефакторинг' не мешались сразу по 2-3 без какого либо описания происходящего.

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Tue 18 Feb, 2014 22:09
by DrKnS
У меня нет особого желания обсуждать методики разработки.
Остановлюсь на двух моментах.
1. Суть не в багах, а в факте и скорости их устранения. Если что-то из поломанного в последнее время не исправлено — пишите, не стесняйтесь.
2. Почему бы вместо очередного комментария в стиле «как страшно жить» не взять какой-нибудь образцово-упоротый компонент (тот же вьювер, ага) и не показать мастер-класс с постепенным скромным прогрессом и полным описанием происходящего?

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Wed 19 Feb, 2014 07:34
by 2useven10
Предмет в данном случае не методики разработки, а способы выливания их в массы.
Времени у всех мало, если его нет на минимальный тестинг - лучше выливать меньшими дозами.
1. Суть не в багах, которые проявились сразу и (достаточно быстро) исправлены, а в тех что остались.
Большинство из них тривиальны, но именно они создают впечатление сырого продукта,
делаешь примитивную операцию - обвал.
2. Было бы время - переписал ..., сейчас даже на доделку минимальных оставшихся хвостов его нет,
правлю только баги. Вьювер (если вдруг) проще просто переписать, косметика++ ничего кроме (1) не даст.

PS: Мечты ( твою бы энергию рефакторинга на переписывание copy.cpp ... )
PPS: То что хотел я уже высказал. Продолжать метать горох в стену смысла нет.

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Wed 19 Feb, 2014 07:53
by Alexey Samlyukov
поддерживаю, копир желательно переписать в первую очередь.
upd. и желательно с службой фонового копирования чтоб :P

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Wed 19 Feb, 2014 08:44
by NightRoman
Автоматизированное тестирование нужно. Тогда можно и рефакторить более-менее спокойно (не 100% факт, конечно). "Программисты не тестируют программы, тесты тестируют программы" (с). А у нас пользователи тестируют. А это не очень хорошо, если честно...

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Wed 19 Feb, 2014 09:47
by zg
NightRoman wrote:Автоматизированное тестирование нужно.
исходники открыты, если что.

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Wed 19 Feb, 2014 10:48
by NightRoman
Это понятно. Но если Фартим не решит этим заняться и не решит, какой должна быть система тестов и ее место в разработке и релизах/сборках, то ничей энтузиазм не поможет.

С функциональным тестированием на PowerShell могу помочь советом, кодом, тестами (Фарнет АПИ хорошо покрыт, а значит и эта часть Фар АПИ и функциональности тоже тестируется). После массированных изменений могу прогнать свои тесты предварительно на тестовом Фаре до выкладывания его на публику. Вроде предлагал это некоторое время назад.

Однако, с введением Луа, наверное, проще и эффективнее подобное тестирование на Луа организовать. Но тут я уже не владею темой в нужной мере.

Re: Глюки и баги, появившиеся в «ночных сборках»

Posted: Wed 19 Feb, 2014 11:23
by NightRoman
Рефакторинг можно делать с прицелом на выделение функций, пригодных для юнит тестов. Хотя бы будущих. Может, это так и делается? Было бы хорошо.

Re: Методика/ Процесс разработки

Posted: Thu 20 Feb, 2014 00:42
by DrKnS
2useven10 wrote:создают впечатление сырого продукта, делаешь примитивную операцию - обвал.
Впечатление сырого продукта создают подобные баги в версиях, объявленных "стабильными" и рекомендуемых к использованию.
Ночные сборки же - это как бы тупо срез текущего состояния репозитория и то, что они компилируются, ещё не повод считать их production-ready.
Если кто-то здесь или на руборде любит бегать впереди паровоза, то тут никакое тестирование не поможет.
Вьювер (если вдруг) проще просто переписать
переписывание copy.cpp
поддерживаю, копир желательно переписать в первую очередь
Я, если что, дичайше хочу нормальный copy.cpp. Я дичайше хочу свёртку в редакторе, выделение мышью там же, мультипанели, фоновые операции, логирование, расширение возможностей плагинов и другие прекрасные идеи, высказанные на этом форуме.

Но:
- переписывать что-либо с нуля - это похоронить 15 лет исправления своих багов, обходов багов ОС, внедрения каких-то специфических вещей и т. п. и тщательно пройтись по всем этим граблям ещё раз (у Джоэла есть неплохая статья на эту тему);
- вносить новый функционал, не трогая старый - это именно то, что (в основном) происходит с 2000 года, это именно то, из-за чего у нас такой copy.cpp и закончиться это может только .

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

Re: Методика/ Процесс разработки

Posted: Thu 20 Feb, 2014 07:40
by Shmuel
DrKnS wrote:Впечатление сырого продукта создают подобные баги в версиях, объявленных "стабильными" и рекомендуемых к использованию.
Ночные сборки же - это как бы тупо срез текущего состояния репозитория и то, что они компилируются, ещё не повод считать их production-ready.
Если кто-то здесь или на руборде любит бегать впереди паровоза, то тут никакое тестирование не поможет.
Так называемые стабильные сборки по своей нестабильности мало чем отличаются от ночных, а если бы "кто-то здесь или на руборде" не любил бегать впереди паровоза, то-есть репортить постоянно добавляемые баги, то Фар был бы ещё в пять раз сырее.

Re: Методика/ Процесс разработки

Posted: Thu 20 Feb, 2014 10:33
by DrKnS
Shmuel, это, если что, не наезд и не в твой адрес.
Речь лишь о том, что не следует ожидать от ночных сборок чудес стабильности.
А всем рапортующим - огромное спасибо, ваша помощь неоценима.