Comments 7
Предполагаю, что на написание статьи ушло больше времени, чем нужно было на генерацию конструкторов и сеттерев/геттеров в IDE.
Не без этого. :) Но лично мне Lombok нравится тем, что он позволяет фокусировать внимание только на том коде, который делает что-то важное. Это удобно тем, что если по задаче был рефакторинг, например, то diff, который нужно ревьювить будет меньше. Долго запрягаем, но быстро ездим.
После пары лет работы с ломбоком у меня выработалось к нему сильное привыкание. Недавно, буквально, хныкал, когда добавлял в легаси-класс несколько полей, а потом добавлял их же в билдер, а потом корректировал имена полей, а потом корректировал их в билдере, а потом нужно было изменить тип, и следом изменить его в билдере.
Конечно все эти мелкие операции заняли у меня меньше времени, чем заняло бы написание статьи, но и удовольствия это мне не принесло. Хочется тратить свое время на что-то более творческое.
Конечно все эти мелкие операции заняли у меня меньше времени, чем заняло бы написание статьи, но и удовольствия это мне не принесло. Хочется тратить свое время на что-то более творческое.
Думаю, если вы уже знакомы с Gradle, то не стоит объяснять все его преимущества перед Maven.
И все же! В чем преимущества?
Очень своевременная статья. Думаю теперь, после прочтения я точно знаю, что в нашем проекте этого не будет.
Сами создали проблему, сами её решили, виртуозно исполнив танец на костылях.
Некоторое время назад один из потребителей нашего сервиса обратился с проблемой — он пытался дебажить наш модуль, но не мог этого сделать, т.к. в sources.jar отсутствовали методы (и даже классы), в которых он хотел бы поставить breakpoint.
Что помешало убрать бесполезный sources.jar из проекта и невозбранно ставить какие душе угодно точки останова в декомпилированном коде?
Sign up to leave a comment.
Lombok, sources.jar и удобный дебаг