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

Разработка Far.
Post Reply
fml2
Posts: 534
Joined: Mon 09 Jul, 2012 22:10
Has thanked: 2 times
Been thanked: 8 times

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

Post by fml2 »

Меня иногда занимает вопрос, откуда в Фаре появляются баги в таких местах, над которыми, вроде бы, никто не работал. Например, вот этот последний случай (просто как пример, можно привести и другие): ведь вроде нигде не было жалоб по поводу командной строки. Как же она тогда сломалась? Неужели в Фаре все так тесно связано, что изменения в одном месте могут вызвать побочные эффекты в совершенно (казалось бы) не связанных с ним местах?
Last edited by fml2 on Thu 01 Jan, 1970 01:00, edited 0 times in total.
Reason: Добавлена ссылка на исходную тему
2useven10
Posts: 5192
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 309 times

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

Post by 2useven10 »

Соблазн велик...
Но пусть лучше именинник ответит.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post by DrKnS »

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

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

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

Человек слаб и сооблазн пойти первым путём велик.
Но, увы, в долгосрочной перспективе этот путь подобен справлению нужды на морозе непосредственно себе в штаны — сначала тепло и хорошо, но потом...
2useven10
Posts: 5192
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 309 times

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

Post by 2useven10 »

Делать хорошо - это хорошо.
Делать плохо, называя это хорошо - очень плохо.
В том темпе, в каком делаются хорошие изменения сейчас, сделать их хорошо нельзя.
Просто нет времени на разборки и отделение мух от котлет, когда всё закатывается под асфальт.
Присыпанные песочком рефакторинга и постоянно вылезающие из самых неожиданных
мест баги тому подтверждение (благо если уши видны сразу, но далеко не всегда так везёт).
Пятикратные проходы рефакторинга по одним и тем же местам из той же серии.
Сам по себе процесс ничем не плох. Если бы он шёл постепенно и в один скромный
'рефакторинг' не мешались сразу по 2-3 без какого либо описания происходящего.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post by DrKnS »

У меня нет особого желания обсуждать методики разработки.
Остановлюсь на двух моментах.
1. Суть не в багах, а в факте и скорости их устранения. Если что-то из поломанного в последнее время не исправлено — пишите, не стесняйтесь.
2. Почему бы вместо очередного комментария в стиле «как страшно жить» не взять какой-нибудь образцово-упоротый компонент (тот же вьювер, ага) и не показать мастер-класс с постепенным скромным прогрессом и полным описанием происходящего?
2useven10
Posts: 5192
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 309 times

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

Post by 2useven10 »

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

PS: Мечты ( твою бы энергию рефакторинга на переписывание copy.cpp ... )
PPS: То что хотел я уже высказал. Продолжать метать горох в стену смысла нет.
Last edited by 2useven10 on Wed 19 Feb, 2014 12:02, edited 1 time in total.
User avatar
Alexey Samlyukov
Posts: 1765
Joined: Tue 15 Mar, 2005 17:28
Been thanked: 7 times
Contact:

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

Post by Alexey Samlyukov »

поддерживаю, копир желательно переписать в первую очередь.
upd. и желательно с службой фонового копирования чтоб :P
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

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

Post by NightRoman »

Автоматизированное тестирование нужно. Тогда можно и рефакторить более-менее спокойно (не 100% факт, конечно). "Программисты не тестируют программы, тесты тестируют программы" (с). А у нас пользователи тестируют. А это не очень хорошо, если честно...
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

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

Post by zg »

NightRoman wrote:Автоматизированное тестирование нужно.
исходники открыты, если что.
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

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

Post by NightRoman »

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

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

Однако, с введением Луа, наверное, проще и эффективнее подобное тестирование на Луа организовать. Но тут я уже не владею темой в нужной мере.
User avatar
NightRoman
Posts: 6184
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 32 times
Been thanked: 62 times
Contact:

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

Post by NightRoman »

Рефакторинг можно делать с прицелом на выделение функций, пригодных для юнит тестов. Хотя бы будущих. Может, это так и делается? Было бы хорошо.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post by DrKnS »

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

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

Лишь постепенное упрощение, "пятикратный проход по одним и тем же местам", метод прогрессивного джипега и "косметика++, которая ничего не даст" дадут возможность избавиться от , за которыми и реализовывать плюшки, не боясь получить результат как на картинке выше.
Shmuel
Posts: 6815
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 526 times

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

Post by Shmuel »

DrKnS wrote:Впечатление сырого продукта создают подобные баги в версиях, объявленных "стабильными" и рекомендуемых к использованию.
Ночные сборки же - это как бы тупо срез текущего состояния репозитория и то, что они компилируются, ещё не повод считать их production-ready.
Если кто-то здесь или на руборде любит бегать впереди паровоза, то тут никакое тестирование не поможет.
Так называемые стабильные сборки по своей нестабильности мало чем отличаются от ночных, а если бы "кто-то здесь или на руборде" не любил бегать впереди паровоза, то-есть репортить постоянно добавляемые баги, то Фар был бы ещё в пять раз сырее.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post by DrKnS »

Shmuel, это, если что, не наезд и не в твой адрес.
Речь лишь о том, что не следует ожидать от ночных сборок чудес стабильности.
А всем рапортующим - огромное спасибо, ваша помощь неоценима.
Post Reply

Return to “Development”