Конечно, и благодаря этому вы получаете более высокую читаемость кода. Но в реальном коде не будет «пустого места на единицу площади иногда больше, чем кода», не надо перегибать палку.
Спасибо за статью, из любопытства хотелось бы задать пару вопросов :)
Интересно было бы узнать не перекрываются ли у вас user stories и functional requirements?
Что вас привело к использованию user stories вместе с use case + functional req?
Делаете ли вы какой-нибудь mapping типа user story -> use case, или только functional req -> use case?
Понятно, что реализуемо, но надо доделывать самим… Простейший пример на связи, который мог бы помочь решать данный инструмент:
1. Надо создать N объектов User и рандомно присвоить enum UserType
2. Надо создать M объектов UserGroup, у которых есть enum UserGroupType. Каждой UserGroup надо добавить Users, но таких, чтобы UserType каким-то заданным образом соответствовал UserGroupType.
Насколько я понял, в Podan это делается через отдельную стратегию для зависимости UserType-UserGroupType.
В общем я не говорю, что Podan плох, или надо все делать через сеттеры, просто он умеет не все, что мог бы (имхо).
Я только за генерацию. Просто похоже на инструмент, который делает inject значения в объект (может сгенерить рандом), а все остальное «сделай сам».
Или взять аннотации "@Podam...", это же жесть. Я понимаю, что не обязательно их использовать, но представьте это в domain model слое… Грубо нарушаем SRP, domain model зависит от тестовой dependency, domain model определяет поведение тестов.
Использовать одну strategy для всех объектов — не очень удачное решение по-моему. На примере Country и City с парой полей, конечно, все будет хорошо, но если у вас будут объекты со сложными связями и генерировать надо псевдо-случайные связи — в этом strategy будет сущий ад из if-else.
Конечно, можно создать несколько factory, но можно ли связать объект из одной с объектами из другой (не руками)?
Или, например, в объект Country надо добавить только те City, которые проходят какое-то условие, это тоже решается через if-else?
Так же, по всей видимости, забыты enumeration'ы, которые живут в дб, их тоже руками в strategy добавлять?
В общем писали мы тоже такое дело, на первый взгляд похоже, что подам не делает за вас кучу работы, которую мог бы.
решения, которые там используются почти что на 100% настолько оптимальны и продуманы, на сколько это возможно
И еще одно весьма спорное утверждение. Не хочется разводить холивар если честно, но инструмент, который имеет настолько большой функционал, с большой вероятностью не может быть «на 100% оптимальным» в частных случаях.
Я ни в коем случае не говорю, что jQuery плох. Просто странно видеть такие эпитеты об инструменте. А жить без jQuery надо хотя бы иногда, это полезно.
Хм… 1,5 млн руб, 7 месяцев разработки… работают за хлеб с водой? :) Тогда не удивительно, что такие результаты.
В общем акцент моего первого комментария был на хотя бы более-менее серьезной фирмы.
Так и не понял шутка это или нет…
Если нет, то пост уж слишком утрирован. С трудом верится, что такое можно найти у хотя бы более-менее серьезной фирмы в продукции.
А так пишите хоть без пробелов, джаве то все равно
Интересно было бы узнать не перекрываются ли у вас user stories и functional requirements?
Что вас привело к использованию user stories вместе с use case + functional req?
Делаете ли вы какой-нибудь mapping типа user story -> use case, или только functional req -> use case?
Написать Hello world без пробелов можно с помощью
System.out.println("Hello"+(char)32+"World");1. Надо создать N объектов User и рандомно присвоить enum UserType
2. Надо создать M объектов UserGroup, у которых есть enum UserGroupType. Каждой UserGroup надо добавить Users, но таких, чтобы UserType каким-то заданным образом соответствовал UserGroupType.
Насколько я понял, в Podan это делается через отдельную стратегию для зависимости UserType-UserGroupType.
В общем я не говорю, что Podan плох, или надо все делать через сеттеры, просто он умеет не все, что мог бы (имхо).
Или взять аннотации "@Podam...", это же жесть. Я понимаю, что не обязательно их использовать, но представьте это в domain model слое… Грубо нарушаем SRP, domain model зависит от тестовой dependency, domain model определяет поведение тестов.
Конечно, можно создать несколько factory, но можно ли связать объект из одной с объектами из другой (не руками)?
Или, например, в объект Country надо добавить только те City, которые проходят какое-то условие, это тоже решается через if-else?
Так же, по всей видимости, забыты enumeration'ы, которые живут в дб, их тоже руками в strategy добавлять?
В общем писали мы тоже такое дело, на первый взгляд похоже, что подам не делает за вас кучу работы, которую мог бы.
И еще одно весьма спорное утверждение. Не хочется разводить холивар если честно, но инструмент, который имеет настолько большой функционал, с большой вероятностью не может быть «на 100% оптимальным» в частных случаях.
Я ни в коем случае не говорю, что jQuery плох. Просто странно видеть такие эпитеты об инструменте. А жить без jQuery надо хотя бы иногда, это полезно.
Весьма спорное утверждение, если честно :)
В общем акцент моего первого комментария был на хотя бы более-менее серьезной фирмы.
Если нет, то пост уж слишком утрирован. С трудом верится, что такое можно найти у хотя бы более-менее серьезной фирмы в продукции.