Начнем с жемчужины индийской архитектурной мысли — использования JPA Entity и работы с Entity в одном и том же классе:
Это же прямо сердце Pattern-a ActiveRecord. Вот в этом вообще не видно ни какого "варварства". Можно поспорить кашерный это паттерн или нет, но тут как со всем SOLID - можно сразу к своему пантеону богов обращаться.
Коллеги в настройках в параметре baseUri указали значения вида http://host/someUri/. А resource хардкодили в коде. В течении одного месяца, коллеги дважды забыли при выкатке на прод указать someUri.
На мой вопрос, может быть в baseUri оставить http://host/, а someUri занести уже в код, для уменьшения риска таких ошибок? Коллеги выдали мне ссылки на то, что такое "правильный" baseUri. И, что только так и надо. И им "ок" жить с таким риском.
Я не стал развивать дискуссию, и остановился на том, что для меня важно, чтобы таких ошибочных релизов быть не должно.
И будь ты сколь угодно сеньёром или тим лидом, к тебе может прийти человек с погонами сеньора и загонять "идеологию", не смотря на практику.
Отметил бы следующее. Scrum позиционировался, как фреймворк управления процессом разработки, чтобы делать быстрые поставки, получать обратную связь, и на основе обратной связи принимать решение, куда двигаться дальше. Т.е. фрейвморк для работы в рамках неопределённости. У нас же его пихают везде, и в разработку маркетплейса (не понятно, что и когда нам надо будет) и в проект (нам надо систему А заменить на систему Б, оставив 90% функционала "как есть"). И если в первом варианте ещё "ок", то во втором это уж на еже.
Для себя я отметил бы следующие моменты, которые я отношу к минусам данного фреймворка: 1. Это фреймворк. Т.е. инструмент, который надо использовать "как написано", а не допиливать его. Иначе - это "не считово" и именно по этому у вас "не получается" 2. Команда берёт на себя коммитмент, чтобы сделать задачу в течении спринта. И в рамках спринта мы должны сделать "всё" и уточнить требования, и разработать и протестировать и хорошо бы "задеплоить". И вот с этим всегда проблемы. Заказчику не нужны задачи "создать сущность ПОЛЬЗОВАТЕЛЬ", "Сделать формочку регистрации", "реализовать API для регистрации", "Реализовать логику регистрации пользователя", "Отправить письмо о регистрации со ссылкой подтверждения почты", "Подтвердить адрес электронной почты". Пользователю нужны две пользовательские истории "Я как пользователь хочу зарегистрировать", "Как зарегистрированный пользователь хочу подтвердить свою почту". И если первые задачи влезают в спринт, то пользовательские истории редко влезают в спринт. 3. Из этого следует следующий "минус". Т.к. мы не можем поставить(с деплоем) функционал в рамках спринта, то мы не можем сделать ревью, т.е. показать пользователю работающий функционал, но можем показать "данные в табличке". И всякие такие "заплатки". Что автоматом приводит к ощущению "отчёта перед заказчиками", а не к процессу получения обратной связи от заказчика. 4. И ещё один больной момент - непрозрачность процесса. Т.е. часть работы по процессу делается "за рамками" спринта, и значит - задачи. Либо мы делим задачи на "предварительный анализ"(до спринта), задача же для взятия в спринт должна удовлетворять критериям DOR и саму разработку, либо одну задачу мы делаем в рамках двух спринтов (1 - анализ, 2 разработка). И вот тут на сцену вылезают оценки. При переезде задачи из спринта в спринт надо менять оценку? А как изменённая оценка должна учитываться в пропускной способности команды (в спринте)? Как изменённая оценка влияет на предсказание поставки?
Не согласен с основой этого высказывания. Я считаю, что человек не может быть компетентен или некомпетентен. Такой обобщающий черно-белый подход на практике не работает. Даже самый прокачанный senior может не знать каких-то вещей. И наоборот, у джуниоров иногда проскакивают отличные идеи.
Как так? Вот недавно собеседовал кандидата. Опыта уже несколько лет. И вот ему задаётся вопрос:
— Мы берём вас на позицию специалиста по… Почему вы всё время отвечаете «Гугл поможет»?
— Так время же такое.
И вы считаете, что такого человек не некомпетентен? Человек хотел неплохую по нынешним меркам ЗП, у него опыт 6 лет в индустрии. 6, мать его, лет. А он не может ответить на базовые вопросы по своей специальности, потому что «Гугл всё знает»
Если человек совершает ошибки раз за разом и не пытается как-то расти, то его надо увольнять.
Это же и есть признание факта некомпетентности человека. Плюс, если вы не будете до этого доносить ему обратную связь, то получится, что человека уволили «не за что».
Т.е. стресс — это плохо вообще-то. Даже для самых «стрессоустойчивых» людей.
Да, а как же развитие? ели вы будете всё время в кисельных берегах, вы когда нибудь вырастите? Ну как без физического стресса научиться подтягиваться 20 раз, допустим. Вот не напрягать мышцы, не напрягать, а потом взять и подтянуться. Так получается?
Это же прямо сердце Pattern-a ActiveRecord. Вот в этом вообще не видно ни какого "варварства".
Можно поспорить кашерный это паттерн или нет, но тут как со всем SOLID - можно сразу к своему пантеону богов обращаться.
Расскажу забавную историю.
Коллеги в настройках в параметре baseUri указали значения вида http://host/someUri/. А resource хардкодили в коде. В течении одного месяца, коллеги дважды забыли при выкатке на прод указать someUri.
На мой вопрос, может быть в baseUri оставить http://host/, а someUri занести уже в код, для уменьшения риска таких ошибок? Коллеги выдали мне ссылки на то, что такое "правильный" baseUri. И, что только так и надо. И им "ок" жить с таким риском.
Я не стал развивать дискуссию, и остановился на том, что для меня важно, чтобы таких ошибочных релизов быть не должно.
И будь ты сколь угодно сеньёром или тим лидом, к тебе может прийти человек с погонами сеньора и загонять "идеологию", не смотря на практику.
Отметил бы следующее. Scrum позиционировался, как фреймворк управления процессом разработки, чтобы делать быстрые поставки, получать обратную связь, и на основе обратной связи принимать решение, куда двигаться дальше. Т.е. фрейвморк для работы в рамках неопределённости. У нас же его пихают везде, и в разработку маркетплейса (не понятно, что и когда нам надо будет) и в проект (нам надо систему А заменить на систему Б, оставив 90% функционала "как есть"). И если в первом варианте ещё "ок", то во втором это уж на еже.
Для себя я отметил бы следующие моменты, которые я отношу к минусам данного фреймворка:
1. Это фреймворк. Т.е. инструмент, который надо использовать "как написано", а не допиливать его. Иначе - это "не считово" и именно по этому у вас "не получается"
2. Команда берёт на себя коммитмент, чтобы сделать задачу в течении спринта. И в рамках спринта мы должны сделать "всё" и уточнить требования, и разработать и протестировать и хорошо бы "задеплоить". И вот с этим всегда проблемы. Заказчику не нужны задачи "создать сущность ПОЛЬЗОВАТЕЛЬ", "Сделать формочку регистрации", "реализовать API для регистрации", "Реализовать логику регистрации пользователя", "Отправить письмо о регистрации со ссылкой подтверждения почты", "Подтвердить адрес электронной почты". Пользователю нужны две пользовательские истории "Я как пользователь хочу зарегистрировать", "Как зарегистрированный пользователь хочу подтвердить свою почту". И если первые задачи влезают в спринт, то пользовательские истории редко влезают в спринт.
3. Из этого следует следующий "минус". Т.к. мы не можем поставить(с деплоем) функционал в рамках спринта, то мы не можем сделать ревью, т.е. показать пользователю работающий функционал, но можем показать "данные в табличке". И всякие такие "заплатки". Что автоматом приводит к ощущению "отчёта перед заказчиками", а не к процессу получения обратной связи от заказчика.
4. И ещё один больной момент - непрозрачность процесса. Т.е. часть работы по процессу делается "за рамками" спринта, и значит - задачи. Либо мы делим задачи на "предварительный анализ"(до спринта), задача же для взятия в спринт должна удовлетворять критериям DOR и саму разработку, либо одну задачу мы делаем в рамках двух спринтов (1 - анализ, 2 разработка). И вот тут на сцену вылезают оценки. При переезде задачи из спринта в спринт надо менять оценку? А как изменённая оценка должна учитываться в пропускной способности команды (в спринте)? Как изменённая оценка влияет на предсказание поставки?
Как так? Вот недавно собеседовал кандидата. Опыта уже несколько лет. И вот ему задаётся вопрос:
— Мы берём вас на позицию специалиста по… Почему вы всё время отвечаете «Гугл поможет»?
— Так время же такое.
И вы считаете, что такого человек не некомпетентен? Человек хотел неплохую по нынешним меркам ЗП, у него опыт 6 лет в индустрии. 6, мать его, лет. А он не может ответить на базовые вопросы по своей специальности, потому что «Гугл всё знает»
Это же и есть признание факта некомпетентности человека. Плюс, если вы не будете до этого доносить ему обратную связь, то получится, что человека уволили «не за что».
Да, а как же развитие? ели вы будете всё время в кисельных берегах, вы когда нибудь вырастите? Ну как без физического стресса научиться подтягиваться 20 раз, допустим. Вот не напрягать мышцы, не напрягать, а потом взять и подтянуться. Так получается?