Парето и код-ревью
Считаю, что принцип 80/20 часто работает и в вопросе код-ревью, ибо только 20% вносимых замечаний правят баги и вскрывают важные ошибки. Остальные 80 – это субъективщина: человек привык использовать одну структуру классов, а ты внес другую. А еще он знает более модную библиотеку и паттерн проектирования из книжки ну очень просится сюда. А в итоге код остается тем же и по функциональности, и по простоте/сложности. Естественно, я не говорю про ситуации, когда, например, сеньор правит джуна и замечания влияют на гибкость кода, тут о другом.
И нет, отказываться от код-ревью, конечно нельзя, это важная часть процесса, взгляд со стороны нужен в любом случае. Но когда есть несколько способов решить проблему, всегда будут возникать другие мнения.
И вся эта шлифовка для красоты приводит только к тому, что повышается стоимость разработки, дизморалится разработчик, которого правят. На команду тоже влияет, так как работа над продуктом замедляется.
Идеально красивый код – не цель, цель – работающий продукт. Работайте на результат, а не над красотой кода.
Считаю, что принцип 80/20 часто работает и в вопросе код-ревью, ибо только 20% вносимых замечаний правят баги и вскрывают важные ошибки. Остальные 80 – это субъективщина: человек привык использовать одну структуру классов, а ты внес другую. А еще он знает более модную библиотеку и паттерн проектирования из книжки ну очень просится сюда. А в итоге код остается тем же и по функциональности, и по простоте/сложности. Естественно, я не говорю про ситуации, когда, например, сеньор правит джуна и замечания влияют на гибкость кода, тут о другом.
И нет, отказываться от код-ревью, конечно нельзя, это важная часть процесса, взгляд со стороны нужен в любом случае. Но когда есть несколько способов решить проблему, всегда будут возникать другие мнения.
И вся эта шлифовка для красоты приводит только к тому, что повышается стоимость разработки, дизморалится разработчик, которого правят. На команду тоже влияет, так как работа над продуктом замедляется.
Идеально красивый код – не цель, цель – работающий продукт. Работайте на результат, а не над красотой кода.
Oracle выложили записи с конференции OracleDevLive, там много всего про новую Java 17, а еще про Vector API, Helidon, GraalVM и тд. Если планируете переходить, будет полезно.
Ссылка: https://developer.oracle.com/developer-live/java-innovations-sep-2021/
Ссылка: https://developer.oracle.com/developer-live/java-innovations-sep-2021/
Краткий обзор от меня, судя по тому, что помню:
📕 Мысли и советы вроде как простые и очевидные, но зачастую игнорируемые даже опытными программистами.
📕 Основной посыл в том, чтобы писать код, который просто работает, а еще чтобы увеличивать срок его службы за счет этого.
📕 Книга скорее для ребят 1-3 года в программировании, учит задумываться об оптимизации блока кода до начала написания этого же блока и будет отличным туториалом, чтобы привить себе навыки грамотного написания и документирования кода. Совсем начинающим будет сложно осилить главу про многопоточность, например. А опытным рекомендую сделать эту книгу настольной (см.1 пункт :))
📕 Есть местами перевес в сторону идеального кода с забиванием на прагматизм. Я все-таки придерживаюсь мнения, что чистый код нужен не просто для красоты, а из практических соображений.
📕 В книге мало воды и есть смешные шутки)
📕 Перевод нормальный, но с некоторыми терминами не очень соглашусь, прикреплю вам русскую версию 2019 года полистать.
Закончу в стиле статусов ВК из нашей юности)
«Чистый код всегда выглядит так, будто его писал человек, которому не всё равно», Майкл Фезерс.
📕 Мысли и советы вроде как простые и очевидные, но зачастую игнорируемые даже опытными программистами.
📕 Основной посыл в том, чтобы писать код, который просто работает, а еще чтобы увеличивать срок его службы за счет этого.
📕 Книга скорее для ребят 1-3 года в программировании, учит задумываться об оптимизации блока кода до начала написания этого же блока и будет отличным туториалом, чтобы привить себе навыки грамотного написания и документирования кода. Совсем начинающим будет сложно осилить главу про многопоточность, например. А опытным рекомендую сделать эту книгу настольной (см.1 пункт :))
📕 Есть местами перевес в сторону идеального кода с забиванием на прагматизм. Я все-таки придерживаюсь мнения, что чистый код нужен не просто для красоты, а из практических соображений.
📕 В книге мало воды и есть смешные шутки)
📕 Перевод нормальный, но с некоторыми терминами не очень соглашусь, прикреплю вам русскую версию 2019 года полистать.
Закончу в стиле статусов ВК из нашей юности)
«Чистый код всегда выглядит так, будто его писал человек, которому не всё равно», Майкл Фезерс.
Чтобы работать рядовым разработчиком необязательно уметь эффективно сортировать списки и уметь строить бинарные деревья.
Но хорошая база очень сильно повышает скил программиста, тем более что изучить ее нужно однажды, алгоритмы всегда останутся алгоритмами.
Структуры данных – основа всех вычислений, большая часть программирования вращается вокруг манипулирования структурами данных. Выбор неподходящих структур будет иметь огромное значение, особенно если проект большой.
У каждой профессии есть свои инструменты – это наши.
Безусловно на повышение скила это будет работать только в сумме с хорошим знанием своей основной платформы.
Если вдруг вы тот самый разработчик, который однажды подзабил на это, точно знаю, что вот эти два курса очень неплохие:
➡️https://www.udemy.com/course/introduction-to-data-structures/
➡️https://ru.coursera.org/specializations/data-structures-algorithms
Есть вся база, отличные примеры.
Про литературу по этой теме сделаю пару постов потом.
Но хорошая база очень сильно повышает скил программиста, тем более что изучить ее нужно однажды, алгоритмы всегда останутся алгоритмами.
Структуры данных – основа всех вычислений, большая часть программирования вращается вокруг манипулирования структурами данных. Выбор неподходящих структур будет иметь огромное значение, особенно если проект большой.
У каждой профессии есть свои инструменты – это наши.
Безусловно на повышение скила это будет работать только в сумме с хорошим знанием своей основной платформы.
Если вдруг вы тот самый разработчик, который однажды подзабил на это, точно знаю, что вот эти два курса очень неплохие:
➡️https://www.udemy.com/course/introduction-to-data-structures/
➡️https://ru.coursera.org/specializations/data-structures-algorithms
Есть вся база, отличные примеры.
Про литературу по этой теме сделаю пару постов потом.
Udemy
Easy to Advanced Data Structures
A complete guide to learning everything there is to know about data structures
Смотрите какая классная статья по вопросам на собеседованиях о Spring Boot. Мне очень нравится, что она именно про понимание процессов, а не простое заучивание функционала. Всегда бы так.
Ссылка:
https://habr.com/ru/post/544472/
Ссылка:
https://habr.com/ru/post/544472/
Хабр
11 вопросов на собеседовании по Spring Boot, которые заставляют задуматься
Большинство списков вопросов интервью по Boot заставляют вас запоминать случайные детали из документации Spring Boot. Но запоминание — плохая замена истинному пониманию и уверенности в знании...
В своей работе я часто сталкиваюсь с использованием шаблонов проектирования DTO.
Данные на клиенте и на сервере в наших проектах структурируются по-разному. На стороне сервера этого требует оптимальное представление информации в базе данных и повышение производительности. На стороне клиента нет необходимости иметь закрытую информацию (пароль, email, роль и т.п.). Для этого могут использоваться специальные объекты – DTO (Data Transfer Object), которые содержат только те поля, которые нужны [на фронтенде]. Подробнее об этом можно найти статьи в интернете, например эту.
Но сегодня я хотел рассказать о том, какой инструмент есть для преобразования entity в dto и обратно, тем самым избегая boilerplate code.
Библиотека MapStruct – это генератор кода, который значительно упрощает реализацию сопоставлений между типами Java-компонентов на основе подхода соглашения, а не конфигурации. С MapStruct нужно создать интерфейс, а библиотека автоматически создаст конкретную реализацию во время компиляции.
Разобравшись с этой или подобной библиотекой, применяя ее, разработчик сокращает количество кода и время разработки.
Быстрый старт можно начать прямо на официальном сайте, по ссылке.
С принципами работы можно ознакомиться на примерах от разработчиков, доступных тут, или найдя статью наподобие этой.
Данные на клиенте и на сервере в наших проектах структурируются по-разному. На стороне сервера этого требует оптимальное представление информации в базе данных и повышение производительности. На стороне клиента нет необходимости иметь закрытую информацию (пароль, email, роль и т.п.). Для этого могут использоваться специальные объекты – DTO (Data Transfer Object), которые содержат только те поля, которые нужны [на фронтенде]. Подробнее об этом можно найти статьи в интернете, например эту.
Но сегодня я хотел рассказать о том, какой инструмент есть для преобразования entity в dto и обратно, тем самым избегая boilerplate code.
Библиотека MapStruct – это генератор кода, который значительно упрощает реализацию сопоставлений между типами Java-компонентов на основе подхода соглашения, а не конфигурации. С MapStruct нужно создать интерфейс, а библиотека автоматически создаст конкретную реализацию во время компиляции.
Разобравшись с этой или подобной библиотекой, применяя ее, разработчик сокращает количество кода и время разработки.
Быстрый старт можно начать прямо на официальном сайте, по ссылке.
С принципами работы можно ознакомиться на примерах от разработчиков, доступных тут, или найдя статью наподобие этой.
Отличная статья о том, как у нас учат будущих ИТ-специалистов, четко подсвечивает основные недостатки.
Пока система кардинально не изменится, мы так и будем получать выпускников, которые знают максимум C/C#, а потом вынуждены самостоятельно в экстренном режиме доучивать Java, Go и другие языки, без которых выдержать конкуренцию невозможно.
Нужны изменения в программах образования, которые будут актуальными. Пока что нам предлагают только курсы для освоения цифровых профессий (даже со скидкой). Конечно, этого недостаточно для улучшения ситуации, но плюсы в такой инициативе тоже есть. Студенты могут получить инфу, которой им не хватило в универе, и таким образом восполнить пробелы. И составить более полное представление о конкретном направлении смогут.
Надеюсь все-таки, что масштабные изменения не заставят себя ждать.
Пока система кардинально не изменится, мы так и будем получать выпускников, которые знают максимум C/C#, а потом вынуждены самостоятельно в экстренном режиме доучивать Java, Go и другие языки, без которых выдержать конкуренцию невозможно.
Нужны изменения в программах образования, которые будут актуальными. Пока что нам предлагают только курсы для освоения цифровых профессий (даже со скидкой). Конечно, этого недостаточно для улучшения ситуации, но плюсы в такой инициативе тоже есть. Студенты могут получить инфу, которой им не хватило в универе, и таким образом восполнить пробелы. И составить более полное представление о конкретном направлении смогут.
Надеюсь все-таки, что масштабные изменения не заставят себя ждать.
Хабр
О процессе подготовки ИТ специалистов в ВУЗах. Взгляд работодателя, подсмотренный изнутри
Работая в ИТ сфере региона, пережившего массовый исход ИТ специалистов, мы попали в непривычную ранее для фирмы ситуацию, когда спрос на нашу работу растет и ширится, а удовлетворить его уже попросту...
Как и обещал, начинаю постепенно делиться литературой по структуре данных.
Robert Lafore, Data Structures & Algorithms in Java
Основа основ. Со своими минусами: на мой вкус, воды многовато, местами изложены прописные истины, но для того, чтобы сформировать в голове базу, подходит.
Главное - не читайте в русском переводе: большая часть примеров там не запускается, еще и в предисловии вместо Java пишут JavaScript.
Robert Lafore, Data Structures & Algorithms in Java
Основа основ. Со своими минусами: на мой вкус, воды многовато, местами изложены прописные истины, но для того, чтобы сформировать в голове базу, подходит.
Главное - не читайте в русском переводе: большая часть примеров там не запускается, еще и в предисловии вместо Java пишут JavaScript.
Давненько не было никаких теоретических вопросов. Вспомним, что мы знаем о классах и методах?
Класс B определен как внутренний нестатический класс для A. Какие из нижеперечисленных утверждений верны?
Anonymous Poll
23%
Класс B имеет доступ ко всем полям и методам класса A, не отмеченным спецификатором доступа private
54%
Класс B имеет доступ ко всем полям и методам класса A независимо от спецификаторов доступа
20%
Класс A имеет доступ ко всем полям и методам класса B, не отмеченным спецификатором доступа private
32%
Класс A имеет доступ ко всем полям и методам класса B независимо от спецификаторов доступа
21%
Класс A не имеет доступа ни к каким полям и методам класса B
В классе А некоторые методы объявлены с модификатором static. Какие из нижеперечисленных утверждений верны?
Anonymous Poll
43%
Эти методы могут вызывать только другие статические методы
4%
Эти методы могут быть вызваны только экземплярами класса А
55%
Эти методы должны обращаться только к статическим данным
61%
Эти методы могут быть вызваны до того, как будут созданы какие-либо экземпляры класса А
17%
Все вышеперечисленные утверждения верны
Одна из моих любимых статей о важности системного подхода, пусть и напоминает по стилю расхожие мотивирующие цитаты.
Часто наблюдаю, как джуны пытаются решать задачи, не задумываясь об альтернативных подходах. И почти никогда – как кто-то из них применяет комплексное мышление. А ведь это ключевое умение для программиста.
Как еще развивать навык мыслить системно? Самый простой способ – отказываться от ежедневных привычных действий: менять маршрут от дома до работы, очередность рутинных задач. А еще расширять кругозор. Так постепенно приучаешься видеть в любой ситуации множество вариантов, среди которых затем находишь решение.
Часто наблюдаю, как джуны пытаются решать задачи, не задумываясь об альтернативных подходах. И почти никогда – как кто-то из них применяет комплексное мышление. А ведь это ключевое умение для программиста.
Как еще развивать навык мыслить системно? Самый простой способ – отказываться от ежедневных привычных действий: менять маршрут от дома до работы, очередность рутинных задач. А еще расширять кругозор. Так постепенно приучаешься видеть в любой ситуации множество вариантов, среди которых затем находишь решение.
Хабр
Думай как программист. Урок по решению задач
Если вы интересуетесь программированием, то возможно слышали фразу: «Каждый должен учиться программированию, потому что оно учит думать.» — Стив Джобс Наверное вы тоже задавались вопросом,...