Согласен, всё ясно, но согласитесь что читаемости кода эти сигнатуры не способствуют.
Я, как программист, должен заниматься бизнес логикой, а не boilerplate code — преобразованием типов и т.д.
Это бизнес решения. Да, они должны приниматься осознанно, но ситуация когда надо выйти с версией пораньше, сделать пресс рилиз о новой функциональности во время гораздо важнее того качества, которое получят пользователи.
Печально? Да.
Но это реальности
Отговорки — удел программистов, а решение сколько времени уделять на тестирование, сколько тестеров держать — удел начальства.
Фирма должна делать деньги. Хороший софт — не самоцель, а средство.
Я сам пишу как раз юнит тесты :)
Но время на написание юнит тестов и количество тестеров в команде — это в конце концов бизнес решения.
Они могут быть ошибочными (если из за плохого качества клиенты откажутся от софта), или правильные (если через месяц выпустили следующую версию с исправлениями, но конкурентов опередили), но это бизнес решения
Очень часто, что из коммерческих соображений, в списке «время», «функциональность», «качество», дл компании качество на последнем месте. например важно выйти с новой верисей раньше конкурентов
А не увеличится ли страшным образом время поднятие приложения из за того, что надо будет сканировать все пакеты на предмет поиска там спринг бинов? Как вообще это происходит? Спринг читает класспас, раскрывает все jars, загружает все классы и ищет классы с аннотациями?
Или как то по другому?
Я, как программист, должен заниматься бизнес логикой, а не boilerplate code — преобразованием типов и т.д.
Может перенести в блог «как я бы потратил деньги, если бы умел их заработать»?
Мне, например и то, и другое очень далеко
Давайте встретимся через год и посмотрим, что случилось.
www.afanas.ru/ROF/
Печально? Да.
Но это реальности
Фирма должна делать деньги. Хороший софт — не самоцель, а средство.
Я сам пишу как раз юнит тесты :)
Но время на написание юнит тестов и количество тестеров в команде — это в конце концов бизнес решения.
Они могут быть ошибочными (если из за плохого качества клиенты откажутся от софта), или правильные (если через месяц выпустили следующую версию с исправлениями, но конкурентов опередили), но это бизнес решения
Или как то по другому?
Изменить поведение методов, добавить новые — это зло.
Просто лениться не надо…
Ну а часть действительно нет…