2 mayton

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

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


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

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

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

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

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

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

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

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