Почему лень – это хорошо?

➕Ленивые дольше живут! Есть исследование моллюсков Атлантического океана, которое пришло к выводу, что кальмары и каракатицы, которые активней других расходовали энергию, умирали (и даже вымирали!) значительно раньше.

➕ Лень восстанавливает мозг. Свободные от нагрузки периоды нужны голове, чтобы переработать всю информацию, подгрузить новые данные и выдать классное решение.

➕ Лень учит работать быстрее. Ленивые не начинают заранее и часто делают в последний момент.
Тонкий аромат дедлайна учит бежать быстрее, это факт.

➕ Самые мощные инсайты и озарения приходят во время ничегонеделания. Представляете, есть даже название сего феномена: «эффект инкубации».

➕ Умные бездельники – самые ценные сотрудники. Они способны предложить решение, которое будет максимально быстрым и требует минимальных ресурсов. Качество не страдает, ибо переделывать тоже лень.

➕ Благодаря лени человеческой у вас по дому ездит робот-пылесос, есть посудомоечная машина и даже дворники на машине. Лентяи заботятся о лени других!

➖ Кстати, мне было лень писать этот пост.

Парето и код-ревью

Считаю, что принцип 80/20 часто работает и в вопросе код-ревью, ибо только 20% вносимых замечаний правят баги и вскрывают важные ошибки. Остальные 80 – это субъективщина: человек привык использовать одну структуру классов, а ты внес другую. А еще он знает более модную библиотеку и паттерн проектирования из книжки ну очень просится сюда. А в итоге код остается тем же и по функциональности, и по простоте/сложности. Естественно, я не говорю про ситуации, когда, например, сеньор правит джуна и замечания влияют на гибкость кода, тут о другом.

И нет, отказываться от код-ревью, конечно нельзя, это важная часть процесса, взгляд со стороны нужен в любом случае. Но когда есть несколько способов решить проблему, всегда будут возникать другие мнения.

И вся эта шлифовка для красоты приводит только к тому, что повышается стоимость разработки, дизморалится разработчик, которого правят. На команду тоже влияет, так как работа над продуктом замедляется.

Идеально красивый код – не цель, цель – работающий продукт. Работайте на результат, а не над красотой кода.

Oracle выложили записи с конференции OracleDevLive, там много всего про новую Java 17, а еще про Vector API, Helidon, GraalVM и тд. Если планируете переходить, будет полезно.

Ссылка: https://developer.oracle.com/developer-live/java-innovations-sep-2021/

Продолжая тему пятничного поста про код-ревью, грех не вспомнить про «Чистый код» Роберта Мартина.

Краткий обзор от меня, судя по тому, что помню:

📕 Мысли и советы вроде как простые и очевидные, но зачастую игнорируемые даже опытными программистами.

📕 Основной посыл в том, чтобы писать код, который просто работает, а еще чтобы увеличивать срок его службы за счет этого.

📕 Книга скорее для ребят 1-3 года в программировании, учит задумываться об оптимизации блока кода до начала написания этого же блока и будет отличным туториалом, чтобы привить себе навыки грамотного написания и документирования кода. Совсем начинающим будет сложно осилить главу про многопоточность, например. А опытным рекомендую сделать эту книгу настольной (см.1 пункт :))

📕 Есть местами перевес в сторону идеального кода с забиванием на прагматизм. Я все-таки придерживаюсь мнения, что чистый код нужен не просто для красоты, а из практических соображений.

📕 В книге мало воды и есть смешные шутки)

📕 Перевод нормальный, но с некоторыми терминами не очень соглашусь, прикреплю вам русскую версию 2019 года полистать.

Закончу в стиле статусов ВК из нашей юности)

«Чистый код всегда выглядит так, будто его писал человек, которому не всё равно», Майкл Фезерс.

Чтобы работать рядовым разработчиком необязательно уметь эффективно сортировать списки и уметь строить бинарные деревья.

Но хорошая база очень сильно повышает скил программиста, тем более что изучить ее нужно однажды, алгоритмы всегда останутся алгоритмами.

Структуры данных – основа всех вычислений, большая часть программирования вращается вокруг манипулирования структурами данных. Выбор неподходящих структур будет иметь огромное значение, особенно если проект большой.

У каждой профессии есть свои инструменты – это наши.

Безусловно на повышение скила это будет работать только в сумме с хорошим знанием своей основной платформы.

Если вдруг вы тот самый разработчик, который однажды подзабил на это, точно знаю, что вот эти два курса очень неплохие:

➡️https://www.udemy.com/course/introduction-to-data-structures/

➡️https://ru.coursera.org/specializations/data-structures-algorithms

Есть вся база, отличные примеры.
Про литературу по этой теме сделаю пару постов потом.

Ну и старый, но все еще радующий мем для бодрости духа при изучении

Смотрите какая классная статья по вопросам на собеседованиях о Spring Boot. Мне очень нравится, что она именно про понимание процессов, а не простое заучивание функционала. Всегда бы так.

Ссылка:
https://habr.com/ru/post/544472/

Как выглядит типичный дейлик

В своей работе я часто сталкиваюсь с использованием шаблонов проектирования DTO.

Данные на клиенте и на сервере в наших проектах структурируются по-разному. На стороне сервера этого требует оптимальное представление информации в базе данных и повышение производительности. На стороне клиента нет необходимости иметь закрытую информацию (пароль, email, роль и т.п.). Для этого могут использоваться специальные объекты – DTO (Data Transfer Object), которые содержат только те поля, которые нужны [на фронтенде]. Подробнее об этом можно найти статьи в интернете, например эту.

Но сегодня я хотел рассказать о том, какой инструмент есть для преобразования entity в dto и обратно, тем самым избегая boilerplate code.

Библиотека MapStruct – это генератор кода, который значительно упрощает реализацию сопоставлений между типами Java-компонентов на основе подхода соглашения, а не конфигурации. С MapStruct нужно создать интерфейс, а библиотека автоматически создаст конкретную реализацию во время компиляции.

Разобравшись с этой или подобной библиотекой, применяя ее, разработчик сокращает количество кода и время разработки.
Быстрый старт можно начать прямо на официальном сайте, по ссылке.
С принципами работы можно ознакомиться на примерах от разработчиков, доступных тут, или найдя статью наподобие этой.

Отличная статья о том, как у нас учат будущих ИТ-специалистов, четко подсвечивает основные недостатки.

Пока система кардинально не изменится, мы так и будем получать выпускников, которые знают максимум C/C#, а потом вынуждены самостоятельно в экстренном режиме доучивать Java, Go и другие языки, без которых выдержать конкуренцию невозможно.

Нужны изменения в программах образования, которые будут актуальными. Пока что нам предлагают только курсы для освоения цифровых профессий (даже со скидкой). Конечно, этого недостаточно для улучшения ситуации, но плюсы в такой инициативе тоже есть. Студенты могут получить инфу, которой им не хватило в универе, и таким образом восполнить пробелы. И составить более полное представление о конкретном направлении смогут.

Надеюсь все-таки, что масштабные изменения не заставят себя ждать.

Роберт Лафоре, «Структуры данных и алгоритмы в Java».

Как и обещал, начинаю постепенно делиться литературой по структуре данных.

Robert Lafore, Data Structures & Algorithms in Java

Основа основ. Со своими минусами: на мой вкус, воды многовато, местами изложены прописные истины, но для того, чтобы сформировать в голове базу, подходит.

Главное - не читайте в русском переводе: большая часть примеров там не запускается, еще и в предисловии вместо Java пишут JavaScript.

Пятничный мем с высокой концентрацией жизы.

Давненько не было никаких теоретических вопросов. Вспомним, что мы знаем о классах и методах?