Не совсем понял из статьи зачем мне самому описывать аннотациями узкие/слабые/тонкие места, когда их можно закрыть от потенциальных уязвимостей более правильным написанием кода? Из примера понял, что разработчик по какой-то причине не хочет или не знает как применять параметризированные запросы к БД. Но тогда аннотирование сего кода - это лишняя работа, т.к. всё равно придётся переписывать чтобы убрать предупреждение PVS-Studio?
Два раза встречался с таким подходом на собеседовании - и оба раза мне понравилось. Опыта просмотра кода много, т.к. преподаю и применяю подход: студенты проводят ревью моего кода, а я их. Поэтому более-менее просто могу увидеть что-то что мне не понравится в коде. Но, опять же, у меня один подход к написанию, у кого-то другого - другой. И не всегда он совпадает. Понятно, что есть что-то "фундаментально" как именование, но есть и что-то более размытое. Например, DI (Dependency Injection). Но бывают ситуации, про которые выше уже писали, что на собеседовании ты делаешь ревью кода - а на работе "потом, сейчас некогда...". И это очень печалит.
По себе могу сказать - что обучение по книжкам - те ещё трудо- и время-затраты. С преподавателем или в группе быстрее будет, но только если преподаватель заинтересован в передаче знаний.
Можно посмотреть на налоги Slack (https://habr.com/ru/companies/skillfactory/articles/510178/). Но мне не хочется использовать "ещё один мессенджер" и настраивать его под себя. Хотя идеи использовать Mattermost у меня были - но я их не стал реализовывать.
Это, к сожалению, ожидаемо.
По теме конкурсов - а хакатоны вам не подходят?
А почему вам не нравится командная работа?
А что преподаёте?
Я советую студентам ходить по собеседованиям и потом с меня спрашивать про то, что не рассказал им или что рассказал не полностью.
P.S. Дополню статью
Ох, первый ваш комментарий и под моей статьёй - как бы вас не посчитали "ботом для накрутки" ))))
Рад что понравились приёмы. Может поделитесь своими или напишите какой больше всего понравился?
Не совсем понял из статьи зачем мне самому описывать аннотациями узкие/слабые/тонкие места, когда их можно закрыть от потенциальных уязвимостей более правильным написанием кода?
Из примера понял, что разработчик по какой-то причине не хочет или не знает как применять параметризированные запросы к БД. Но тогда аннотирование сего кода - это лишняя работа, т.к. всё равно придётся переписывать чтобы убрать предупреждение PVS-Studio?
Два раза встречался с таким подходом на собеседовании - и оба раза мне понравилось. Опыта просмотра кода много, т.к. преподаю и применяю подход: студенты проводят ревью моего кода, а я их. Поэтому более-менее просто могу увидеть что-то что мне не понравится в коде. Но, опять же, у меня один подход к написанию, у кого-то другого - другой. И не всегда он совпадает. Понятно, что есть что-то "фундаментально" как именование, но есть и что-то более размытое. Например, DI (Dependency Injection).
Но бывают ситуации, про которые выше уже писали, что на собеседовании ты делаешь ревью кода - а на работе "потом, сейчас некогда...". И это очень печалит.
Спасибо за пожелание!
Спасибо за комментарий.
P.S. Сразу готовьтесь к тому, что тут могут вас посчитать "типо бота" для поддержки автора (не помню как правильно это называется).
Я это имел ввиду под сознательным нежеланием учиться ))))
Ну ведь сознательно не стали ))) Значит понимают что не смогут обучиться и что не стоит им своё время на это тратить.
Но на самом деле - это грустно.
Кстати, тоже верно. Даже можно приписать это к осознанному отказу от обучения - ибо даст результат. ))))
По себе могу сказать - что обучение по книжкам - те ещё трудо- и время-затраты. С преподавателем или в группе быстрее будет, но только если преподаватель заинтересован в передаче знаний.
Книжки разные бывают )))
Есть такие. Вроде и взрослые люди, а ведут себя хуже маленьких детей.
Отличное решение!
Хороший вопрос. Ничего - спать буду. Я постарался выстроить общение так - что ночью никто не пишет. И всё общение стараюсь вести в чатах групп.
Можно посмотреть на налоги Slack (https://habr.com/ru/companies/skillfactory/articles/510178/). Но мне не хочется использовать "ещё один мессенджер" и настраивать его под себя. Хотя идеи использовать Mattermost у меня были - но я их не стал реализовывать.
Мне хватает бесплатных возможностей. Пока существенных преимуществ бизнес-аккаунта или премиум для преподавания не вижу.