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