С датой и временем ещё типичная ошибка - когда программисты думают, что в сутках 24 часа, забывая про перевод часов. Аналогично с константами 1440 минут в сутках и 86400 секунд. Но это не в 100% случаях ошибка. И часто проще ей пренебречь, чем переписывать на правильный код.
Расчёты с разными часовыми поясами - вот уж где огромное количество ошибок.
В реальности клиенты бы любили Серёжу с его говнокодом только поначалу. А потом очень часто появляются странные баги в неожиданных местах. Поменял Сережа что-то в обработке заказов — часть заказов начала исчезать. И никто не узнает, что они исчезли, пока недовольный потребитель не начнёт жаловаться (а он скорее закажет то же самое на другом сайте). Поменял Сережа расчет комиссий — программа начала обсчитывать некоторых клиентов и недосчитывать зарплату части сотрудников. В малом бизнесе это, может, и прокатит, сто баксов туда-сюда роли не играют. А если бизнес побольше, так можно неожиданно потерять миллион, и это превысит стоимость разработки системы с нормальным кодом.
Также всё хорошо, пока Серёжа один и работает. А если задач стало больше, и он не справляется? Коллегу ему не нанять, он ничего не поймёт в таком коде и будет только отвлекать Сережу вопросами. А если Сережа ушел в отпуск, заболел или уволился?
Иногда бизнесу важнее минимальное кол-во багов, чтобы не терять деньги и клиентов. А стоимость и скорость разработки на втором месте. К таким проектам Сереж нельзя подпускать.
Мягкое удаление делаем ручками. Часто вместо него можно сделать галочку Активный, а на странице списка объектов — фильтр, который по умолчанию показывает только активные. Если юзер по ошибке удалил — он может сам восстановить объект (вернуть галочку), не нужно просить запускать SQL апдейт для этого. И можно отредактировать уже «удалённый» объект при необходимости.
В примере с Glassfish мне показалось странным, почему синхронизация идёт на классе, а не на this. Метод-то не статический. И если сделать несколько экземпляров класса, то эти синхронизации будут мешать друг другу. Разве что если сам этот класс — синглтон, и второго экземпляра там точно не будет.
При рефакторинге забыли ситуацию, когда файл настроек существует, но пустой. Изначально функция не выбрасывала исключение в этом случае, а после рефакторинга этот код его выбросит:
if (loadedProperties.isEmpty()) {
throw new RuntimeException("Can`t load workspace properties");
}
И теперь, чтобы восстановить правильное поведение, надо или возвращать null, если файла нет, и пустые Properties, если файл есть (а возвращать коллекцию null — это костыль). Или добавлять класс типа
class LoadFileResult {
Properties properties
boolean fileExists
}
И возвращать этот класс из функции чтения файла. И в результате получается ничуть не лучше, чем изначальный флаг boolean throwIfNotExists.
Получается, что код выглядит рабочим, даже после перестановки вызовов, а результат оказывается неожиданным.
А это уже проблема того, кто переставляет методы, не разобравшись сначала в коде. Как можно вообще что-то менять в коде просто так, не понимая, как он работает?
Придётся приписывать всякие флаги или прочее, чтобы отличить «нет данных» от «даже не запрашивали».
Можно сделать объект Prices, если «даже не запрашивали» он будет null, а если «нет данных», тогда будет подкласс EmptyPrices или просто цены с пустым контентом, не null. И тогда не надо даже писать Objects.requireNonNull(product.getPrices) — второй метод и так упадёт с NullPointerException, если не вызвать первый.
У нас есть WIP-лимиты, но никто на них не смотрит. Задач гораздо больше, чем в лимитах, вся доска красная. Ну и ладно, вроде ничего страшного не происходит.
А мне не нравится идея ротации, лучше знать свою программу хорошо, чем всего по чуть-чуть и ничего в деталях. Может, это у нас сложный монолит, в котором человеку нужно полгода, чтобы въехать в общих чертах, как что работает, и несколько лет, чтобы разобраться во всех деталях.
Я вот не один год на проекте и чувствую, что это даёт ощутимое преимущество. Когда проблема на лайве, обычно сразу понимаю, в какой файл смотреть и что может быть причиной. Если кто-то поменял код в одном месте, я пишу в ревью, что нужно поменять во втором и третьем, чтобы система работала одинаково (или просто чтобы ничего не сломалось).
Я вот тоже не пойму, зачем делать статическим какой-то метод сервиса (спринг бина), если вдруг так совпало, что он не вызывает другие сервисы? Сегодня не вызывает, а завтра будет вызывать. Ну и я не собираюсь вызывать метод в статическом контексте (MyService.method()), это даже хорошо запретить. Правильно вызывать через экземпляр бина.
Поэтому раздражает инспекция «Method may be static», и я её отключил.
saveAndFlush удобен тем, что если при сохранении будет ошибка БД (например, constraint не даст сделать вставку), то исключение вылетит сразу же, и будет видно, на какой строчке кода и на каком объекте это произошло (первом, десятом или сотом). Если сохранять без flush, то исключение будет потом, на последней строчке метода, где находится закрывающая скобка. Попробуй тогда разберись, что случилось. Поэтому везде flush используем, кроме редких случаев, где нужно сохранить больше тысячи объектов за раз.
Только мне сразу бросился в глаза совершенно дурацкий логотип сайта? Его даже прочитать невозможно, и непонятно, на каком он языке. Последние 2 буквы (перевернутая e и q) говорят про английский, получается тхомекв — странный набор букв. На втором скриншоте уже ТНОМЕР — это уже по-русски или всё ещё по-английски, но с ошибкой? Я бы на этом этапе скептически отнёся бы к фирме, у которой даже нет внятного названия, и пошёл бы на другой сайт.
С датой и временем ещё типичная ошибка - когда программисты думают, что в сутках 24 часа, забывая про перевод часов. Аналогично с константами 1440 минут в сутках и 86400 секунд. Но это не в 100% случаях ошибка. И часто проще ей пренебречь, чем переписывать на правильный код.
Расчёты с разными часовыми поясами - вот уж где огромное количество ошибок.
Также всё хорошо, пока Серёжа один и работает. А если задач стало больше, и он не справляется? Коллегу ему не нанять, он ничего не поймёт в таком коде и будет только отвлекать Сережу вопросами. А если Сережа ушел в отпуск, заболел или уволился?
Иногда бизнесу важнее минимальное кол-во багов, чтобы не терять деньги и клиентов. А стоимость и скорость разработки на втором месте. К таким проектам Сереж нельзя подпускать.
И теперь, чтобы восстановить правильное поведение, надо или возвращать null, если файла нет, и пустые Properties, если файл есть (а возвращать коллекцию null — это костыль). Или добавлять класс типа
И возвращать этот класс из функции чтения файла. И в результате получается ничуть не лучше, чем изначальный флаг boolean throwIfNotExists.
А это уже проблема того, кто переставляет методы, не разобравшись сначала в коде. Как можно вообще что-то менять в коде просто так, не понимая, как он работает?
Можно сделать объект Prices, если «даже не запрашивали» он будет null, а если «нет данных», тогда будет подкласс EmptyPrices или просто цены с пустым контентом, не null. И тогда не надо даже писать Objects.requireNonNull(product.getPrices) — второй метод и так упадёт с NullPointerException, если не вызвать первый.
Зачем вообще делать коммиты каждый день? Можно доделать задачу и уже по ней сделать один коммит.
Я вот не один год на проекте и чувствую, что это даёт ощутимое преимущество. Когда проблема на лайве, обычно сразу понимаю, в какой файл смотреть и что может быть причиной. Если кто-то поменял код в одном месте, я пишу в ревью, что нужно поменять во втором и третьем, чтобы система работала одинаково (или просто чтобы ничего не сломалось).
Поэтому раздражает инспекция «Method may be static», и я её отключил.
saveAndFlushудобен тем, что если при сохранении будет ошибка БД (например, constraint не даст сделать вставку), то исключение вылетит сразу же, и будет видно, на какой строчке кода и на каком объекте это произошло (первом, десятом или сотом). Если сохранять без flush, то исключение будет потом, на последней строчке метода, где находится закрывающая скобка. Попробуй тогда разберись, что случилось. Поэтому везде flush используем, кроме редких случаев, где нужно сохранить больше тысячи объектов за раз.