Применение рефакторинга для увеличения тестируемости кода

Мои цели:
1) Высокая читаемость кода
2) Легкость тестирования кода (юнит тесты, интеграционные тесты, приемочные тесты)
3) Высокая модульность кода
4) Возможность повторного использования кода

Конкретная задача (может быть использована для людей, которые предпочитают показывать на примере):


Далее предположим, что данная задача или подобная ей реализована в виде одного god-like класса, этот класс содержит 500-2000 строк кода. В нем заданы все константы, осуществлена наиболее примитивная декомпозиция на методы. Класс не содержит кода по отображению GUI - эта логика вынесена в другой модуль с которым идет общение через интерфейс (или через сигналы Qt).
Код является полной противоположностью поставленных целей. Необходимо покрыть его тестами на 70-100 процентов.

Вопросы:
Какой из типов швов следует применять по умолчанию, при решении о увеличении модульности/тестируемости некоторого god-like класса? (Швы по Майклу Физерсу)
Каким образом Вы производили бы декомпозицию задачи и до какой степени разделения (от чего зависела бы эта степень) ?
В каком случае Вы применяли бы рефакторинг извлечение класса и в каком - дополнительно, извлечение интерфейса?
По каким признакам Вы определили бы, что в дополнительном выделении классов отсутствует необходимость?
Как при этом Вы предпочли бы управлять памятью и на каком уровне инвертировать зависимости? (DIP из SOLID)

В чем моя проблема:

0

Сообщение от Melg Код является полной противоположностью поставленных целей.

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

Сообщение от Melg Необходимо покрыть его тестами на 70-100 процентов.

Откуда такие числа?

Сообщение от Melg Какой из типов швов следует применять по умолчанию, при решении о увеличении модульности/тестируемости некоторого god-like класса? (Швы по Майклу Физерсу) Каким образом Вы производили бы декомпозицию задачи и до какой степени разделения (от чего зависела бы эта степень) ? В каком случае Вы применяли бы рефакторинг извлечение класса и в каком - дополнительно, извлечение интерфейса? По каким признакам Вы определили бы, что в дополнительном выделении классов отсутствует необходимость? Как при этом Вы предпочли бы управлять памятью и на каком уровне инвертировать зависимости? (DIP из SOLID)

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

Сообщение от Melg как другие программисты применяют рефакторинги и к чему они приходят в итоге

У каждого изменения кода есть
1) кол-во времени, потраченное на изменение
2) кол-во профита, от это изменения полученного.
Из всех возможных выбираем изменение с максимальным соотношением профит/время, производим его. Повторяем по желанию до тех пор, пока не останутся только те изменения, профит от которых не окупает потраченное время.

0

ct0r, в данном конкретном случае причина начала рефакторинга никак не связана ни с самим легаси кодом, ни с тем, какие бизнес проблемы он решает в данный момент и сможет решать после проведения рефакторинга. Целью данной активности в конечном счете является как раз приобретение необходимых навыков/подходов при решении подобных задач в реальных условиях. В общем случае ставится задача получения опыта в проведении рефакторингов без (или с минимальным количеством) ошибок в условиях большого объема кода не покрытого тестами, приобретения навыков тестирования для предотвращения регрессии кода при внесении изменений (связанных с изменениями в бизнес-правилах). А так же освоения методологии разработки через тестирования.
100 процентов покрытия - выбраны как идеальный случай, к которому я стремлюсь, 70 процентов как случай достаточного покрытия, предполагающий тестирование бизнес логики, и критических сегментов кода без необходимости тестировать не используемые при решаемой задаче возможности, либо код связывания элементов логики в единое целое (которое может быть перекрыто статическим анализом, корректной компиляцией, приемочным тестированием и т.д.)

Если бы все было однозначно - самыми крутыми разработчиками были бы те, кто больше всех читает. Но это не так.

У Вас завалялась статистика на этот счет? выработанная система, описывающая положение дел? может быть, хотя бы личный опыт? Поделитесь? Пока-что это утверждение звучит крайне самонадеянно.
Если Вам хотелось услышать примеры обоснования первопричин проведения рефакторингов и покрытия тестами, по приведенной задаче, я могу синтезировать пару, тройку. Относительно глобальной ситуации:
1) менеджмент по итогам прошедшего года пришел к выводу, что группа программистов не справляется с поставленными задачами в срок и качество продукта ниже заявленного, новый тех. лид. проекта принимает решение о последовательном изменении методологии разработки, постулируется необходимость покрывать новый код и изменения в старый код тестами перед тем как он попадет на ревью.
2) В унаследованный проект для его поддержки и модификации нанята группа программистов - цель номер один - не допустить регрессии существующего кода, цель номер два, увеличить скорость добавления новых фич в проект, цель номер три понять как работает уже написанный код - для решения этих целей среди прочих выбрано дополнительное покрытие тестами.
3) Сотрудник отдела ведет подрывную деятельность на предприятии и безнаказанно занимается рефакторингом легаси кода.
Локально по коду:
1) Изначально код копировал файлы целиком, теперь появилась необходимость копировать по частям, поскольку изменились требования к системе.
2) Изначально код копировал файлы по частям, теперь появилась необходимость для множества маленьких файлов выполнять один способ копирования, а для других другой.
3) Изначально код копировал файлы по одному, теперь процесс необходимо распараллелить по носителям.
4) Изначально код копировал известный на этапе компиляции набор файлов, теперь пользователю необходимо дать возможность включить/исключить некоторые из них
5) Изначально код копировал файлы локально, теперь требуется посылать команды на удаленную машину.
6) Изначально код копировал файлы, а теперь он должен их перемещать с гарантией удаления информации с изначальной позиции считывания.
7) Изначально код решал одну из выше перечисленных задач, теперь требуется написать на его основе небольшую библиотеку классов, используемую в компании для решения каждой из представленных задач без необходимости переписывать общую для алгоритма часть.

0

Сообщение от Melg Целью данной активности в конечном счете является как раз приобретение необходимых навыков/подходов при решении подобных задач в реальных условиях. В общем случае ставится задача получения опыта в проведении рефакторингов без (или с минимальным количеством) ошибок в условиях большого объема кода не покрытого тестами, приобретения навыков тестирования для предотвращения регрессии кода при внесении изменений (связанных с изменениями в бизнес-правилах). А так же освоения методологии разработки через тестирования.

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

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

Так и думал, что число 70 выбрано пальцем в небо.

Сообщение от Melg У Вас завалялась статистика на этот счет? выработанная система, описывающая положение дел? может быть, хотя бы личный опыт? Поделитесь?

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

Сообщение от Melg Локально по коду:

Какое отношение все нижеперечисленное имеет к рефакторингу?

0

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

Какое отношение все нижеперечисленное имеет к рефакторингу?

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

0

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

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

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

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

Сообщение от Melg 70 выбрано не совсем случайно, мне нужно число гарантированно больше 50 процентов, позволяющее увидеть как люди действуют в условиях необходимости тестирования классов с зависимостями от других классов.

Число 70 мне ни о чем не говорит. Другим тоже. Почему бы просто не сказать: дофига зависимостей в классе, по-любому надо будет их разруливать?

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

Если мы действительно поимеем большой гемор без рефакторинга, то да, все так. Я именно это и хотел услышать

Сообщение от Melg Я такой сепарации практически нигде не видел, поэтому и задаюсь вопросом как другие программисты применяют рефакторинги и к чему они приходят в итоге.

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

0

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

0

Сообщение от XRuZzz обычно этим занимаются люди, которым не сказали, что есть функциональное программирование.

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

0