Полагаю речь о любых видах автокомплита в IDE + сюда же можно подтянуть различные встроенные и кастомные шаблонны со сниппетами. Статья весьма хайповая.
Код-ревью обычно организовываются в проектах побольше, где в 1-2 человека не справиться. Как уже отмечал в статье, это мощный инструмент для обмена опытом, причем неважно кто кому пишет комментарии к коду - опытный-молодому или наоборот. Коллега может легко предложить в конктретном сниппете заиспользовать какую-то недавно добавленную в язык фичу, о которой другие еще не успели почитать, дать отсылку на какие-то статьи с best practises или просто предложить более свежий взгляд на оформление кода. Мне очень нравится когда мы подтягиваем друг друга в таком ключе.
По поводу где и как можно попрактиковаться. Как уже здесь упомянали, можно попробовать вписаться в какой-нибудь open-source проект на гитхабе, например в библиотеку, которую сам используешь в повседневной жизни. Или, для начала, можно просто поизучать существующие PR-ы. Просто заходи на интересующие тебя проекты в раздел pull-request-ов, как например, вот такой (первое что попалось под руку): https://github.com/lodash/lodash/pull/5855
Да, мы активно пользуемся кастомными плагинами к eslint+prettier и часть правил автоматизировали. Но далеко не все легко ложится на автоматизацию, порой правило может быть слишком сложным и организация его в плагин становится отдельной нетривиальной задачей (с необходимостью последующей поддержки).
На самом деле, когда мы обсуждали отказ от нашего code style документа, то одна из идей звучала так: "то что не получается легко завернуть в eslint, не должно обсуждаться на код-ревью". Я не совсем согласен с таким подходом, но фактически, отчасти эта идея победила в нашей команде.
Ситуация и правда довольно неприятная. Но к сожалению, увольнение - слишком радикальная мера. Пришедшие коллеги в целом - довольно сильные разработчики по хард скиллам, показывают высокую производительность и полезность в проекте. Саботировать начали только некоторые правила и далеко не сразу, без шума. Если ревьюер отмечал на код-ревью такие места, то они исправлялись, но в следующий раз те же самые правила могли опять игнорироваться (тем более что ревьюером мог выступать второй "новичок") - предположу что старые привычки брали свое. Выход на откровенный разговор плавно перерастал в конфликт, т.к. роли лида у нас в команде нет и с новчиками, по сути, приходилось договариваться заново на общих правах. Так у нас заведено.
Думаю при вертикальной структуре команды этот вопрос можно было бы решить иначе, но мы нашли выход и в целом нас всех устраивает такой "демократичный" подход.
Статья начинается с многообещающей ссылки. Открыл посмотреть - сильно устаревшая заметка 10-летней давности от австралийского СМИ, еще и на веб-архиве (( Ни слова про Лондонскую школу экономики. Нет даже информации о количестве опрошенных.
Полагаю речь о любых видах автокомплита в IDE + сюда же можно подтянуть различные встроенные и кастомные шаблонны со сниппетами. Статья весьма хайповая.
Самое простое - на своем проекте договориться с кем-нибудь из коллег поревьюить друг друга, даже если этот процесс не интегрирован в компании.
Если речь о пет-проекте, то можно попросить кого-нибудь из знакомых-разработчиков помочь с этим.
Код-ревью обычно организовываются в проектах побольше, где в 1-2 человека не справиться. Как уже отмечал в статье, это мощный инструмент для обмена опытом, причем неважно кто кому пишет комментарии к коду - опытный-молодому или наоборот. Коллега может легко предложить в конктретном сниппете заиспользовать какую-то недавно добавленную в язык фичу, о которой другие еще не успели почитать, дать отсылку на какие-то статьи с best practises или просто предложить более свежий взгляд на оформление кода. Мне очень нравится когда мы подтягиваем друг друга в таком ключе.
По поводу где и как можно попрактиковаться. Как уже здесь упомянали, можно попробовать вписаться в какой-нибудь open-source проект на гитхабе, например в библиотеку, которую сам используешь в повседневной жизни.
Или, для начала, можно просто поизучать существующие PR-ы. Просто заходи на интересующие тебя проекты в раздел pull-request-ов, как например, вот такой (первое что попалось под руку):
https://github.com/lodash/lodash/pull/5855
Да, мы активно пользуемся кастомными плагинами к eslint+prettier и часть правил автоматизировали. Но далеко не все легко ложится на автоматизацию, порой правило может быть слишком сложным и организация его в плагин становится отдельной нетривиальной задачей (с необходимостью последующей поддержки).
На самом деле, когда мы обсуждали отказ от нашего code style документа, то одна из идей звучала так: "то что не получается легко завернуть в eslint, не должно обсуждаться на код-ревью". Я не совсем согласен с таким подходом, но фактически, отчасти эта идея победила в нашей команде.
Ситуация и правда довольно неприятная. Но к сожалению, увольнение - слишком радикальная мера. Пришедшие коллеги в целом - довольно сильные разработчики по хард скиллам, показывают высокую производительность и полезность в проекте. Саботировать начали только некоторые правила и далеко не сразу, без шума. Если ревьюер отмечал на код-ревью такие места, то они исправлялись, но в следующий раз те же самые правила могли опять игнорироваться (тем более что ревьюером мог выступать второй "новичок") - предположу что старые привычки брали свое. Выход на откровенный разговор плавно перерастал в конфликт, т.к. роли лида у нас в команде нет и с новчиками, по сути, приходилось договариваться заново на общих правах. Так у нас заведено.
Думаю при вертикальной структуре команды этот вопрос можно было бы решить иначе, но мы нашли выход и в целом нас всех устраивает такой "демократичный" подход.
Статья начинается с многообещающей ссылки. Открыл посмотреть - сильно устаревшая заметка 10-летней давности от австралийского СМИ, еще и на веб-архиве (( Ни слова про Лондонскую школу экономики. Нет даже информации о количестве опрошенных.