Периодически собеседую джунов и встречаю полное отсутствие понимания принципов ООП, не могут объяснить даже основные принципы. Это ладно, можно просто не брать джуна). Но бывает вижу это не только у начинающих. И иногда это опытные ребята, которые не понимают, что весь смысл ООП сводится к тому, чтобы так переформулировать задачу и её решение, чтобы писать надо было поменьше и понятнее. Наследование и полиморфизм для них просто инструмент, а что там в основе этих механизмов – неважно. Не жалуюсь, просто хочу реже такое встречать.
Ну что, проверим, как хорошо вы помните ООП и переопределение в частности? 😈
Ну что, проверим, как хорошо вы помните ООП и переопределение в частности? 😈
Какой из перечисленных методов является переопределением метода public int[] inverse (int ar[], int size) класса родителя?
Anonymous Quiz
5%
public int inverse (int a, int b)
22%
public int[] method (int ar[], int size)
29%
private int[] inverse (int arr[], int arSize)
15%
private int[] inverse (double a[], double size)
7%
public int inverse (int arr[], int arSize)
22%
нет верного ответа
Какой из перечисленных методов является переопределением метода public double method (boolean flag, char ch) класса родителя?
Anonymous Quiz
0%
public void method (int a, int b)
5%
public void method (int a, int b, int c)
8%
public int method (int a, int b)
81%
public double method (boolean i, char j)
5%
все вышеперечисленные
Как оптимизировать митинг: не проводить его.
Да-да, всех бесят затянутые совещания, дейли и бесконечные стендапы. Конечно, есть продакт или скрам, который должен все это контролировать. Но мне кажется, если каждый участник немного ответственней отнесется к процессу, легче станет всем. Вот мои простые, но почему-то не всем очевидные рекомендации:
👍 Готовься, не надо вспоминать на месте статус своей задачи. Если занимаешься другими делами до встречи, за несколько минут переключи контекст в голове.
👍 Не бери с собой ноутбук, убери телефон. Не решай другие задачи во время митинга, сейчас твоя задача – митинг.
👍 Держи фокус на повестке, а себя в руках). Не пускайся в обсуждение вопросов, которые связаны с другими задачами, не поддерживай отхождение от темы у коллег. Если в конце встречи останется время и ты считаешь, что это сильно необходимо обсудить сейчас, можешь предложить.
👍 Уважай коллег: не опаздывай, не переходи на личные разговоры.
👍 Развивай скилы, касающиеся выступлений и ораторских способностей. Учись четко формулировать мысль, говорить лаконично и по факту.
Да-да, всех бесят затянутые совещания, дейли и бесконечные стендапы. Конечно, есть продакт или скрам, который должен все это контролировать. Но мне кажется, если каждый участник немного ответственней отнесется к процессу, легче станет всем. Вот мои простые, но почему-то не всем очевидные рекомендации:
👍 Готовься, не надо вспоминать на месте статус своей задачи. Если занимаешься другими делами до встречи, за несколько минут переключи контекст в голове.
👍 Не бери с собой ноутбук, убери телефон. Не решай другие задачи во время митинга, сейчас твоя задача – митинг.
👍 Держи фокус на повестке, а себя в руках). Не пускайся в обсуждение вопросов, которые связаны с другими задачами, не поддерживай отхождение от темы у коллег. Если в конце встречи останется время и ты считаешь, что это сильно необходимо обсудить сейчас, можешь предложить.
👍 Уважай коллег: не опаздывай, не переходи на личные разговоры.
👍 Развивай скилы, касающиеся выступлений и ораторских способностей. Учись четко формулировать мысль, говорить лаконично и по факту.
Почему лень – это хорошо?
➕Ленивые дольше живут! Есть исследование моллюсков Атлантического океана, которое пришло к выводу, что кальмары и каракатицы, которые активней других расходовали энергию, умирали (и даже вымирали!) значительно раньше.
➕ Лень восстанавливает мозг. Свободные от нагрузки периоды нужны голове, чтобы переработать всю информацию, подгрузить новые данные и выдать классное решение.
➕ Лень учит работать быстрее. Ленивые не начинают заранее и часто делают в последний момент.
Тонкий аромат дедлайна учит бежать быстрее, это факт.
➕ Самые мощные инсайты и озарения приходят во время ничегонеделания. Представляете, есть даже название сего феномена: «эффект инкубации».
➕ Умные бездельники – самые ценные сотрудники. Они способны предложить решение, которое будет максимально быстрым и требует минимальных ресурсов. Качество не страдает, ибо переделывать тоже лень.
➕ Благодаря лени человеческой у вас по дому ездит робот-пылесос, есть посудомоечная машина и даже дворники на машине. Лентяи заботятся о лени других!
➖ Кстати, мне было лень писать этот пост.
➕Ленивые дольше живут! Есть исследование моллюсков Атлантического океана, которое пришло к выводу, что кальмары и каракатицы, которые активней других расходовали энергию, умирали (и даже вымирали!) значительно раньше.
➕ Лень восстанавливает мозг. Свободные от нагрузки периоды нужны голове, чтобы переработать всю информацию, подгрузить новые данные и выдать классное решение.
➕ Лень учит работать быстрее. Ленивые не начинают заранее и часто делают в последний момент.
Тонкий аромат дедлайна учит бежать быстрее, это факт.
➕ Самые мощные инсайты и озарения приходят во время ничегонеделания. Представляете, есть даже название сего феномена: «эффект инкубации».
➕ Умные бездельники – самые ценные сотрудники. Они способны предложить решение, которое будет максимально быстрым и требует минимальных ресурсов. Качество не страдает, ибо переделывать тоже лень.
➕ Благодаря лени человеческой у вас по дому ездит робот-пылесос, есть посудомоечная машина и даже дворники на машине. Лентяи заботятся о лени других!
➖ Кстати, мне было лень писать этот пост.
Парето и код-ревью
Считаю, что принцип 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.