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

untitledесли этот процесс никак не регламентировать, .... . а хотелось бы,
Регламентировать этот процесс - примерно то же самое, что регламентировать качественное программирование. Можно назвать некоторые признаки хорошего и плохого кода, но в целом процесс слишком неформализуемый, чтобы его можно было описать в регламенте.

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

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

maytonПросто надо в особо крупных проектах определить "правила игры".
Само собой. "Невменяемые" - это те, кто несмотря на правила игры.

untitledкак определить что в первом методе стоит писать на уровень info, а во втором только debug,
Никак. Хочется назвать это явной ошибкой, но на всякий случай скажу мягче - очень спорное решение.

untitledточнее я подозреваю что в 90% случаев такое пишется от балды,
Уровни log4j - очень небесспорны и сомнительны. По-хорошему, нужна стратегия уровня команды - что логируется и на каких уровнях, фактически "что именно значат цифры от 0 до N".

untitledно потом это приводит к полной каше в логах рабочего приложения.
Не совсем так. Реальная практика в моем представлении примерно такова: обычно приложение крутится с высоким level-ом логируемости (warn или может быть info), соответственно что в них пишется - команда понимает достаточно четко. В случае наличия проблем отдельные модули запускаются с level=all, и соответственно до бардака в уровнях особо нет никакого дела. А для отладки level=all для всех логгеров проще вообще не убирать.

сосед. был акцессникОчень был бы благодарен за высказывание развернутоно мнения - каким средствами правильно должно достигаться понимание
Смотря что Вы называете пониманием.

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

сосед. был акцессники, может быть вы поделитесь примерами использования этих средств.
Если хочется понять "как работает нечто в конкретном случае", то лучшим инструментом является отладчик. Почему:

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

Если же хочется глобально врубиться, врасти в код, то лучшим решением является чтение хорошо написанного и прокомментированного кода и рефакторинг плохо написанного.

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