Как же надоело за всю жизнь слушать все это нытье. От тимлидов которые не хотят быть тимлидами, от техлидов которые не хотят быть тимлидами, от мидлов которые не хотят быть тимлидами. От всех - про переработки, про не те обязанности, про все на свете. Уже столько насмотрелся и наслушался.
То что вы не не можете сказать нет, то что вы не можете порешать вопросы своей карьеры и из вас верёвки вьют - это исключительно ваши проблемы, которые нужно решать а не ныть. Нужно учится говорить нет, нужно учится добиваться как минимум компромиссов а лучше удобной для себя работы. Не важно на тот же самом месте или меняя работу. За вас это никто делать не будет а вот пользоваться вами - только в путь.
Я не понимаю зачем писать статьи с нытьем, вместо того чтобы написать - "Я техлид. История про то как меня пытались прогнуть но у них ничего не вышло. Делюсь опытом". Нет блин, давайте все вместе собираемся и будим плакать.
Если у вас нет нормального code review на проекте, вас ничего не спасет от "творчества" таких разработчиков. Ну забанили Вы слово now, что дальше? Есть еще миллион и один способ как угробить проект, если нет нормального контроля качества кода. Знаете что будет в реальной жизни? Отдадут проект на поддержку другой команде и через непродолжительное время найдется разработчик который посчитает написанное Вами правило глупым и просто отключит его. Вот и вся жизнеспособность на большом отрезке времени.
Можно просто не использовать напрямую работу с датой и временем а вынести в отдельный сервис . Потом можно менять реализацию сколько захочется. В тестах мокать и выставлять любое время. И не нужно никаких радикальных ограничений на code-style. Все просто.
Это связано с сильными контрактами совместимости между Java-версиями: модули скомпилированные до Java 5, продолжат работать — вызывать классы с generic-типами. Это работает и назад. В случае более строгой реализации generic-типов без erasure совместимость была бы нарушена.
На самом деле не совсем так. Когда для Java проектировалось решение для добавления дженериков было создано сразу оба экспериментальных варианта - как с боксингом так и со специализацией. Но по результатам тестов, на JVM того времени, вариант со специализацией выглядел неубедительно и привносит дополнительные проблемы. Потому предпочтение было отдано варианту реализации через боксинг.
kotlin - это исторически порождение проблемы старой Java в Android.
Не нужно придумывать сказки. Kotlin ни для какого андроида не придумывали, а то что Kotlin взлетел на андроиде это был приятный сюрприз для самих JB. Никто это не скрывает, про создание данного ЯП есть достаточное количество материалов где раскрывается как все это было придумано. Популярность Kotlin на андроиде обусловлена как болью связанной с старой версией Java так и в целом куда менее консервативным сообществом адроид разработчиков.
Я бы очень осторожно выбирал язык для долго играющих проектов (>3..5 лет). потому что сегодня JetBrains есть, а завтра ее кто ни будь купит и приоритеты поменяются и т.п.
Как хорошо что крупные компании никогда не позволяют себе делать неожиданные вещи. Например делать JDK то платным то бесплатным. Судится за авторские права. Ой, извините это другое.
Рубрика "вредные советы". Сами создали проблему, сами героически пытаетесь ее решить непонятным образом.
Что здесь происходит? Вместо строгого типа Product, мы ставим ResponseEntity<?>, где под ? понимается любой Java объект.
Почему Вы сами не поставили параметр типа ответа а вместо него "?" и жалуетесь что не понятен тип?
public Product findById(Long id) {
return productsRepository.findById(id).orElseThrow(
() -> new ResourceNotFoundException("Product with id " + id + " not found"));
}
Вы когда логику вынесли в сервисы и радостно выбрасываете исключение, конечно же не подумали что если ресурс не найден то это не ошибка. Это вполне ожидаемое поведение. По нормальному нужно возвращать из метода Optional<Product> , и уже пользователь этого метода должен решать что делать если ресурса нет. А он может не просто бросить исключение а например: - использовать значение по умолчанию - попробовать выполнить альтернативный сценарий В вашем сценарии все прибито гвоздями.
{
"statusCode": 404,
"message": "Product with id 299 nor found"
}
Т.е. фронт отправил запрос для получения Product по id=299 и когда ему приходит 404, он ну никак не сможет догадается о том что когда пошел за ресурсом Product по id=299 и получил статус код 404 - что ресурс не найден, обязательно нужно сообщение: "Product with id 299 nor found"?
Как же надоело за всю жизнь слушать все это нытье. От тимлидов которые не хотят быть тимлидами, от техлидов которые не хотят быть тимлидами, от мидлов которые не хотят быть тимлидами. От всех - про переработки, про не те обязанности, про все на свете. Уже столько насмотрелся и наслушался.
То что вы не не можете сказать нет, то что вы не можете порешать вопросы своей карьеры и из вас верёвки вьют - это исключительно ваши проблемы, которые нужно решать а не ныть. Нужно учится говорить нет, нужно учится добиваться как минимум компромиссов а лучше удобной для себя работы. Не важно на тот же самом месте или меняя работу. За вас это никто делать не будет а вот пользоваться вами - только в путь.
Я не понимаю зачем писать статьи с нытьем, вместо того чтобы написать - "Я техлид. История про то как меня пытались прогнуть но у них ничего не вышло. Делюсь опытом". Нет блин, давайте все вместе собираемся и будим плакать.
Если у вас нет нормального code review на проекте, вас ничего не спасет от "творчества" таких разработчиков. Ну забанили Вы слово now, что дальше? Есть еще миллион и один способ как угробить проект, если нет нормального контроля качества кода. Знаете что будет в реальной жизни? Отдадут проект на поддержку другой команде и через непродолжительное время найдется разработчик который посчитает написанное Вами правило глупым и просто отключит его. Вот и вся жизнеспособность на большом отрезке времени.
Можно просто не использовать напрямую работу с датой и временем а вынести в отдельный сервис . Потом можно менять реализацию сколько захочется. В тестах мокать и выставлять любое время. И не нужно никаких радикальных ограничений на code-style. Все просто.
На самом деле не совсем так. Когда для Java проектировалось решение для добавления дженериков было создано сразу оба экспериментальных варианта - как с боксингом так и со специализацией. Но по результатам тестов, на JVM того времени, вариант со специализацией выглядел неубедительно и привносит дополнительные проблемы. Потому предпочтение было отдано варианту реализации через боксинг.
Не нужно придумывать сказки. Kotlin ни для какого андроида не придумывали, а то что Kotlin взлетел на андроиде это был приятный сюрприз для самих JB. Никто это не скрывает, про создание данного ЯП есть достаточное количество материалов где раскрывается как все это было придумано. Популярность Kotlin на андроиде обусловлена как болью связанной с старой версией Java так и в целом куда менее консервативным сообществом адроид разработчиков.
Как хорошо что крупные компании никогда не позволяют себе делать неожиданные вещи. Например делать JDK то платным то бесплатным. Судится за авторские права. Ой, извините это другое.
Рубрика "вредные советы". Сами создали проблему, сами героически пытаетесь ее решить непонятным образом.
Почему Вы сами не поставили параметр типа ответа а вместо него "?" и жалуетесь что не понятен тип?
Вы когда логику вынесли в сервисы и радостно выбрасываете исключение, конечно же не подумали что если ресурс не найден то это не ошибка. Это вполне ожидаемое поведение. По нормальному нужно возвращать из метода Optional<Product> , и уже пользователь этого метода должен решать что делать если ресурса нет. А он может не просто бросить исключение а например:
- использовать значение по умолчанию
- попробовать выполнить альтернативный сценарий
В вашем сценарии все прибито гвоздями.
Т.е. фронт отправил запрос для получения Product по id=299 и когда ему приходит 404, он ну никак не сможет догадается о том что когда пошел за ресурсом Product по id=299 и получил статус код 404 - что ресурс не найден, обязательно нужно сообщение: "Product with id 299 nor found"?
Думаю наиболее полезно было бы при работе с БД, где из имени свойства можно было бы по умолчанию выводить имя колонки