Я так розумію, чи це публічна функція в деякому класі?
Тому що я особисто тести на приватні та захищені методи не пишу.
Ок, так от, якщо це публічна функція, це означає, що її повинен викликати якийсь код в іншому класі (компоненті).
А щоб викликати функцію з іншого класу, необхідно розуміти, що вона робить.
Як Java розробник розуміє, що робить той чи інший клас/метод із JDK? Навряд чи він щоразу відкриває його sources. Швидше за все, він читає контракт (документацію) як Java Docs.
Більше того, якщо ви використовуєте поліформізм або інтерфейси (патерн Strategy), ви повинні додати контракт на такі інтерфейси:

interface Executor {
public void execute();
}

Інакше ніхто не зможете реалізувати цей інтерфейс, тому що не розумітиме, що реалізація має робити.
Якщо ви написали метод і не має контракту, як зрозуміти, правильно ви його написали чи ні? Дивитись sources? Але цей метод може використовувати безліч інших класів і так по ланцюжку. Щоразу розкручувати це простирадло? Мені здається незручно та непрактично.

Це по-перше. А по-друге, як ви, наприклад, читатимете код функції, якщо ви використовуєте TDD?
У вас при TDD немає жодного коду функції, ви спочатку пишете тести і потім уже реалізацію (production code)

Для unit-тестів потрібно розуміти, що робить метод, а не як він це робить (як працює).
Тобто якщо, наприклад, розробника попросили написати юніт-тести для функції, яка складає два числа, чи повинен він читати код функції? Ні, лише її контракт. Тобто опис вхідних параметрів і значення, що повертається.
Тут може також бути обробка виняткових ситуацій (неправильне значення аргументів тощо.).

Не треба писати коментарі, вони не зроблять незрозумілий код краще.

Вибачте, але ви неправі.
Коментарі лише тоді зло, коли вони повторюють те, що написано у коді. І тоді справді вам доводиться змінювати код, а потім обов’язково коментар.
Але якщо вам потрібно написати high-level опис методу або класу з кількох рядків, це нормальна практика і без цього взагалі важко зрозуміти, для чого потрібен той чи інший API. У Java це називається Java Docs.

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

Чому??? Я написав REST API, не має значення з думкою про тестування чи без неї.
Написати потiм тести для REST API — звичайна стандартна справа, коли ви формуєте запит, відправляєте його та перевіряєте відповідь. І все.

Дуже просте правило: якщо ти не в змозі швидко написати простий тест, то код треба рефакторити до тих пір, поки тест не буде значно простіший за код. Більшість проблем, пов’язаних з юніт-тестами, — це проблеми поганого коду.

Як взагалі пов’язана складність коду та складність тесту?
Код може бути 1000 разів складним, але перевірити його можна тестом із двох рядків. І навпаки.

Якщо функція є нагромадженням if/else/case, сайд-ефектів, додаткових аргументів та return стейтментів, то буде складно і прочитати її й написати тести.

Я не розумію, а навіщо для написання тестів читати тіло функції та розуміти, як ця функція працює?
А якщо це буде тест, який буде викликати ваш REST API та перевіряти відповідь? У автора тесту взагалі може бути доступу до коду проекту.
Коли ви пишете автоматизований тест, для вас те, що ви тестуєте, має бути чорною скринькою, і ніяк і інакше.
А ви виходить, пропонуєте, писати тести не за документацією до проекту, а за тим, як фактично працює код. А це докорінно неправильно.

Але баги можна виправити, а незрозумілий код вже не змінити, його можна тільки викинути. Він вже не є software.

А рефакторинг на що? Його ж і вигадали для того, що робити код (і дизайн) краще і зрозуміліше.

На селищі Котовського мешкає 300 тис. осіб. І що всі вони маргінали?

Після третьої пляшки всі будуть згодні, що краще Java нічого немає

Якщо вас все дратує в Україні, чого ви пасете на українських сайтах? Ідіть на польські і там пишіть, як ви задоволені

Вам все одно, які люди вас оточують — щасливі чи незадоволені?

Найцікавіше, що хоча ІТ-компанії з України і використовують NDA, і постійно про нього нагадують (наприклад, якщо ти залишаєш компанію), але якщо ти приходиш до них на співбесіду, то одне з перших, що запитують — останнє (або поточне) місце роботи, проекти у деталях тощо.

Для когось успіх — гроші, для когось можливість самореалізації, для когось популярність.
Я вважаю, що тільки гроші не можуть бути мірилом успіху. За ними має щось стояти.

Я вам можу назвати кілька відомих українських компаній, де беруть не проект, а «у компанію». І відповідно лише після виходу на роботу вам запропонують розглянути проекти.

А вам цікаво було дивитися один серіал 2 роки щодня нову серію? А 5 чи 10 років?
Комусь таке подобається, а хтось щомісяця вибере новий серіал.
Ви, на жаль, не написали, що для вас важливо в роботі. Якщо просто кодити — то яка різниця де? Якщо розвиватися, то або разом із проектом (інакше почнеться стагнація), або новий проект.

Я знаю людей, які справді працювали на одному проекті по 5-10 років.
Їм уже нічого не потрібно було, вони дорослі до senior і все, що їх цікавило в житті — стабільність. Щоправда, давно з ними не спілкувався.

Якщо ви родич директора, можна і +2k виторгувати.

Це якщо проект розвивається і ви ростете разом із ним.
А якщо ваша роль — фіксувати баги та support, то дуже скоро дійсно починається професійна деградація.

Все залежить від проекту. Звичайно, якщо розробник працює над Microsoft Windows, то він все життя може щось нове вивчати та робити. А якщо якась забута legacy?