Я в таких случаях «старому» начальнику говорю, что «все вопросы — через нового нача», а новому начальнику обозначаю, что лично я «сдавать кровь» особым желанием не горю. А дальше уже сами пусть разбираются.
Если о том, что Асе интересен конкретно такой рост знают снаружи, но Ася ни сном ни духом, что такая же позиция есть в ее родной компании, то что-то не так именно в консерватории, и Ася, скорее всего, правильно делает ноги…
Но у Аси же хватило качеств и желания пойти и узнать о своих перспективах вовне, я же вот о чем. То есть получается, что ей на текущем месте спросить/обозначить было труднее, чем пойти вовне, прособеседоваться, получить оффер, и совершить еще кучу энергозатратных телодвижений. Значит Ася-таки способна не только озвучить свои желания, но и реализовать себя — просто не здесь. И возникает вопрос — что за климат в коллективе, в котором Асе проще уйти на сторону, нежели озвучить свои желания там, где ее ценят и любят?
Все равно не понимаю, каким образом у вас остается возможность того, что «Ася не знает возможности своего роста», и при этом «три пункта выше выполняются»? Тут либо три пункта не выполняются, и поэтому Ася не знает, либо эти три пункта изначально не способствуют такому знанию, и Ася не знает уже поэтому. Исходя из того, что прямо сказано о обязанности Аси выяснять, как работает ее карьерный лифт, ставлю на второе. В общем имейте ввиду, что Ася может уходить не потому, что она какая-то не такая, а потому что открытый и честный начальник слишком заигрался со своими высокими материями, вместо того, что бы прямо сказать что Асе светит, а что не светит.
заметьте, что Ася предпочла уйти в другую команду прежде, чем выяснить возможности роста в своей. Такое поведение, скорее всего, прямо говорит об отсутствии качеств, необходимых для более ответственной позиции: доверия к руководителю, активности, лояльности, умения сформулировать потребности и смелости о них рассказать.
Это Ася должна выяснять «возможности роста в своей команде», а не честный и открытый руководитель должен четко обозначать как и куда может расти каждый его сотрудник? Может быть описанная ситуация как раз говорит не о Асе, а о дубовом руководителе, и об отсутствии у него качеств, необходимых для занимаемой должности?
Не совсем так. У меня выделена отдельная сущность «экшен», который с одной стороны может вызываться на выполнение фронтэндом, путем отправления по вебсокету специального сообщения, а с другой стороны в него интегрирован доступ к ядерным сервисам, которые обеспечивают работу самого приложения, и знать не знают ни о какой фронтовой части. То есть реализуя экшен (java код) на получение, к примеру, данных о работнике, которые на ядерном уровне распределены по нескольким компонентам, мы делам примерно так:
UserProfile userProfile = userService.getProfile(id);
EmployeeProfile employeeProfile = employeeService.getProfile(id);
после чего компонуем эти два профиля в одну entity, состоящую, скажем, из ФИО (взятого из userProfile) и количества рабочих часов в месяц (из employeeProfile), которую экшен и возвращает для дальнейшего превращения в json, и возврата фронтэнду. При таком подходе результирующий entity даже в виде inner класса в классе экшена смотрится довольно уместно.
А в чем проблема дополнительных оберток, кстати говоря? Формально понятно, лишняя сущность, но практически она маленькая, локальная и вопросов не вызывает. Стоит ли с ней бороться?
Ваш подход не подойдет в случае если нет однозначного соответствия Класс<->json. То есть в одном случае нужен json состоящий из некоторых полей класса А, в другом — из всех полей, а в третьем случае вообще должен быть композицией из A + B + C. Плюс мне нравится иметь возможность на вопрос «почему фронту приходит ЭТО вместо ЭТОГО?» пойти и подправить одну конкретную обертку гарантированно не затронув ничего по соседству. Я такие обертки вообще частенько создаю, как inner классы прямо по месту преобразования результата.
Для человека, который этого не знает и та и другая аннотация выглядят магически и требуют времени для постижения того, что это такое и как работает, так что с этой точки зрения разница не велика. При этом, замечу, квикдок по аннотации Data первым делом сообщает: "Generates getters for all fields", плюс дает ссылку на сайт ломбока, что сильно помогает делу.
Есть объект класса, нужно вернуть его часть в виде json — я создаю отдельную обертку, которая в конструктор принимает этот объект, и берет из него все нужное, после чего объект обертки прогоняется через jackson, и на выходе получаем json. Jackson, как известно, пользуется для конвертации либо публичными полями, либо геттерами, поэтому одна единственная аннотация Data над классом-оберткой быстро и не заметно экономит мне время. Еще одна аннотация @Slf4j позволяет мне работать с логгером даже не думая о нем. В общем не очень понимаю ваше не понимание, о каком «внедрении в бородатый энтерпрайз» вообще идет речь? Это же библиотека, а не фреймворк — если удобно, то используем, если не удобно, то не используем.
Это Ася должна выяснять «возможности роста в своей команде», а не честный и открытый руководитель должен четко обозначать как и куда может расти каждый его сотрудник? Может быть описанная ситуация как раз говорит не о Асе, а о дубовом руководителе, и об отсутствии у него качеств, необходимых для занимаемой должности?
UserProfile userProfile = userService.getProfile(id);
EmployeeProfile employeeProfile = employeeService.getProfile(id);
после чего компонуем эти два профиля в одну entity, состоящую, скажем, из ФИО (взятого из userProfile) и количества рабочих часов в месяц (из employeeProfile), которую экшен и возвращает для дальнейшего превращения в json, и возврата фронтэнду. При таком подходе результирующий entity даже в виде inner класса в классе экшена смотрится довольно уместно.
А насчет библиотеки это да, тут согласен.
Спринговый @Compontent тоже вгонит, так что ж теперь, Спрингом не пользоваться?
Жека Борисов и его доклад «Спринг-потрошитель» в двух частях доступен на ютубе черт знает сколько уже. Рекомендую!