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


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

ЗЫ
В настоящее время сопровождаю очень компактную задачу - весь код в районе 2мегабайт в компилированного з-кода. Возраст задачи - около 7 лет. В настоящий момент контора не роасполагает ни одним сотрудником, исторически причастным к разввитию этой задачи.

В задаче около десятка расчетных функций. Размер функций - от 1000 до 5000 строк (от 30 до 120-130 страниц печатного текста).

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

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

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

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

2 mayton

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

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


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

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

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

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

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

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

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

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