Сообщений в теме: 27

[Case]

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

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

[Andy]

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

Или другой пример:

"Самая первая версия Microsoft Word для Windows была проектом типа "смертельный бой". Работа над ней повисла навечно. Вся команда вкалывала, не покладая рук, и при этом выпуск откладывался снова, и снова, и снова, и стресс был просто невыносимым. Когда эту чёртову штуку всё-таки выпустили с задержкой в несколько лет, Microsoft отправил всю команду в отпуск в Мексику и провёл серьёзный анализ.

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

Пример, конечно, не очень, но общая идея в том, что при полной работоспособности программы она может вся работать на таких вот подпорках.

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

[Andy]

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

И если уже приходит решение о переписании всего кода, значит внутри все очень, очень плохо.

[Case]

Методология ХР как я понимаю этот момент говорить что рефакторить нужно если код не нравится. То есть не переделывать если не работает, а переделывать чтобы код был красивее, ровнее, ронятнее.
Приведённый пример с выпуском Ворда немного не к рефакторингу относится - это разработка.
Рефакторинг это изменение существующего кода с целью зделать его более читабельным, логичным и понятным. Более простым для передачи, если планируется передавать кусок проекта другому разработчику. Но если этот косметический ремонт тянет за собой кучу переделок в коде тестера, то уже стоит подумать нужен ли он? Оправдан ли?

[Andy]

По моему мнению нет.

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

[Andy]

В данном случае, по моему, целесообразнее снабдить код подробными коментариями.

[Green]

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

to Case:

Если перефразировать Ваш вопрос, то Вы озвучили редко возникающую дилему в практике тестирования, а именно:
Нужно ли проводить повторное тестирование, если программист внес изменения в уже работающий код программы?

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

[Case]

Green, мой вопрос не звучит так.
Я спрашиваю оправдан ли рефакторинг (а не просто изменения кода - рефакторинг это не переделки чистой воды) если за ним стоит ещё и рефакторинг кода тестировщиков.

[Green]

Что же касается внесения изменений в тестовые скрипты, то я здесь не виже проблемы. Изменения в них ДОЛЖНЫ быть минимальны. В идеальном случае - их быть не должно.

Если речь идет о скриптах, которые тестируют пользовательский интерфейс программы (типа WinRunner, Silk и т.п.), то нужно избавляться от таких программистов, если их рефакторинг приводит к изменению интерфейса программы (хотя бы и на уровне имен контролов).

Если же речь идет о unit testing (white box testing), то с такими программистами нужно поступать так же, как и в предыдущем случае. Тестировщик, принимающий участие в юнит тестировании, должен тестировать только функции вынесенные в интерфейс компоненты (а не все подряд), а они (функции), в свою очередь, должны быть четко прописаны и задокументированны.

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

B)

[Case]

При чём тут документирование?
Есть стандарт наименований.
Было два метода которые делали плюс минус одно и тоже (мы это тестили), отрефакторили на три метода, с точки зрения функционала ничего не поменялось, код стал понятнее и красивее (типичный пример который приводят адепты рефакторинга) - теперь тестеру который работал с двумя методами нужно перекапывать код, который перестал работать, так как методы были согласно правилам наименований переименованы.

Ситуация классическая: 10 разработчиков, 2 тестера. Разработчики ушли в рефакторинг. Тестеры ушли в рефакторинг. Разработчики ушли в разработку, тестеры сидят в рефакторинге.... долго.

[Green]

Тогда мне не совсем понятно, чем занимаются тестеры?

Могу предположить, что они отвечают за unit testing. Но в таком случае, это нонсенс - использовать тестировщиков для проверки всего кода! Это крайне не продуктивно! :(

На мой взгляд, это сфера ответственности программеров - писать юнит тесты на все методы класса (открытые и не очень :P ). Тестировщик не должны копаться в коде. Максимум, что он может делать - это писать юнит тесты на public функции, т.е. на функции вынесенные в интерфейс класса или компоненты.

В свою очередь, такие функции должны быть задокументированы. Как известно, интерфейс пишиться один раз и навсегда. Хочешь его поменять - наследуй. Поэтому, если было два public метода до рефакторинга, столько же должно остаться после него. Тоже относиться и к их именам. Вот именно о документации на программный интерфейс, я говорю. Если же программист может менять не только свой код, но и программный интерфейс, то это крайная степень неорганизованности проекта.

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

B)

[Case]

Как известно, интерфейс пишиться один раз и навсегда.

Откуда такая известность? :)

Хочешь его поменять - наследуй. Поэтому, если было два public метода до рефакторинга, столько же должно остаться после него.

После рефакторинга их станет иное количество - если кол-во совпадёт будет вопрос что отрефакторили?

Тоже относиться и к их именам.

Если поменялся функционал метода, то и называться он должен иначе.

Это три приятжки за уши мимо которых я просто не мог пройти.

[Green]

Как известно, интерфейс пишиться один раз и навсегда.

Откуда такая известность? :)

Хочешь его поменять - наследуй. Поэтому, если было два public метода до рефакторинга, столько же должно остаться после него.

После рефакторинга их станет иное количество - если кол-во совпадёт будет вопрос что отрефакторили?

Тоже относиться и к их именам.

Если поменялся функционал метода, то и называться он должен иначе.

Это три приятжки за уши мимо которых я просто не мог пройти.

Другими словами, в вашей организации практикуется следующий подход:

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

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

Я правильно понял вашу систему взаимодействия?

[Case]

Я сейчас в принципе не говорю о конкретной системе взаимодействия и не очень понимаю почему Вы на неё перевели разговор.
Я задал три вопроса после цитаты из вашего сообщения, дальнейший пост не всносит ясности. Кроме того не даёт ответа на вопросы :( Я что-то упустил или потерян какой-то из постов?

[Green]

Я просто сделал предположение исходя из Ваших вопросов. Если бы Вы попробовали на них ответить, то многое стало бы яснее. Во всяком случае, для меня. ;)

Что касается Ваших вопросов, то могу ответить следующее.

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

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

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

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

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

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

B)

[Case]

Один вопрос: у Вас никогда не меняются методы? Не удаляются и не создаются новые?
Мне очень сложно представить практически реализованный проект, который несёт в конечной его модификации весь набор заложенных в него с самого начала интерфейсов к примеру. Мусорник называется :)

[Green]

Конечно же, меняются. Случается, что меняются даже требования к приложению!

В природе постоянны только изменения! :P

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

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

Что касается внесения изменений в программный интерфейс, то можно легко наследовать класс, добавив новые возможности тому или иному методу. Но такие изменения обязательно должны быть описаны в документации.

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

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

Но мне не совсем понятен другой вопрос. У вас что, тестировщики пишут юнит тесты для кода программистов?
:blink: :(

[Mila]

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

Разработчик ОБЯЗАН вносить любые изменения по улучшению кода. И тестер тут никак не может выступать инициатором, т.к. он не кодирует, не отвечает за целостность кода, его сопровождаемость и т.п. :rolleyes:
На практике, если код не улучшать, то система рано или поздно начнет просто "разваливаться", причем, по закону Мерфи, как раз перед релизом. :(

Ну и, естественно, об изменениях громко сообщается менеджерам, тестерам и т.п. ... вобщем... трудовые будни... :rolleyes:

[Case]

Green:

При использовании подхода жестко закрепленного интерфейса, рефакторинг вообще не оказывает влияния на работу смежников.

Как-то у меня не особо вяжутся понятия "жестко закрепленного интерфейса" и "рефакторинга".

У вас что, тестировщики пишут юнит тесты для кода программистов?

Да не заморачивайтесь вы на мою скромную персону. ;)
Не пишем мы юниты - на то разработчики есть. Я спрашиваю о подходе.

Mila:

И тестер тут никак не может выступать инициатором

Мммм.. Пардон, если я нашёл ошибку, задокументировал, отправил разработчику, то кто как ни я есть инициатор изменений в коде?

_______________________________________
По-моему мы немного топчемся вокруг термина.
http://xprogramming.ru/glossary/ - раздел "Refactoring".
Рефакторинг: Рефакторинг, Переработка, Реорганизация.
Прошу отметить что исправление ошибок как таковое не есть рефакторинг.

[Green]

Разработчик ОБЯЗАН вносить любые изменения по улучшению кода.  И тестер тут никак не может выступать инициатором, т.к. он не кодирует, не отвечает за целостность кода, его сопровождаемость и т.п.   :rolleyes:

Мила, мне нравиться Ваш оптимизм! :P

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

Но здесь необходимо сделать несколько оговорок.

1. Код должен писаться цельно, т.е. не должно быть участков кода оставленных "на потом" в надежде на их улучшение. Если разработчик хочет опробовать какой-либо подход или прием, то для этого он должен использовать пробный проект или пример, но не основной код программы!

2. Нельзя писать код на будущее, т.е. разработчик не должен реализовывать функциональность не предусмотренную техническим заданием в надежде, что его инициатива возможно пригодиться в будущем. Функциональность должна строго соответствовать тех. заданию. Ни больше, ни меньше.

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

4. Код должен писаться в паре за одним компьютером и за одной клавиатурой. Это не является жизнено необходимым требованием, но именно это правило и помогает достигнуть высокого качества написания кода. Вместе обсуждают. Затем, один пишет, другой смотрит. Через некоторое время меняются.

5. И наконец, разработчики пишут юнит тесты к своему коду. Причем, юнит тесты должны писаться до написания кода, который они тестируют.
Сценарий примерно следующий. Определяется - как функциональность должна работать, входные и выходные данные. Далее пишеться тест, который подает на вход тестовые данные и проверяет полученный результат. В конце, пишется код. Запускаются тесты. По результатам тестов, код, или исправляется, или признается работающим. В последнем случае, все повторяется со следующим заданием.

B)