А я и не говорю, что это нужно вводить в середине цикла разработки, когда все вредные привычки уже сформированы. Я тоже считаю, что это надо закладывать с самого начала и жестко обязывать команду соблюдать эту практику. А самоосознанность - это до первой горящей жопы перед релизом. Надо всё закреплять на уровне документации и бить по рукам за несоблюдение оговоренных правил.
А поддерживать потом как? Разработчику нужно одновременно работать минимум в трёх файлах в рамках одного компонента. Довольно сильно размывает фокус. Не подумайте, я не представляю противоположную точку зрения, я просто хочу для себя разобраться, как помочь проекту не скатиться в помойку.
У меня в голове только один вариант. На уровне команды и проекта определить минимальный порог, после которого мы будем дробить компонент. Например: простые компоненты <150-200 строк оставлять как есть, средние - до 300 или со сложной логикой дробить, страницы и контейнеры - всегда дробить (стили во всех случаях выносить отдельно).
Тем самым мы можем не распыляться на мелкую ерунду вроде кнопок или других маленьких компонентов и сосредоточиться на декомпозиции средних и больших модулей и страниц. Вроде то же самое, но экономим время на «мишуре» и фокусируемся на том, где дробление действительно решает.
Такое разбиение мне больше по душе, чем копание в месиве React-компонента. Но это сильно тормозит написание самого компонента (хотя и даёт преимущество в долгосрок). Бизнесу нужно быстро, а дробить кнопку на кучку файлов и повторять это раз за разом во всех последующих компонентах я считаю другой крайностью, как и писать всё в одном файле. «Месиво» против «Капусты» - наверное, нужен какой-то компромисс между этими подходами.
Корень проблемы, как мне кажется, в недосказанности между всеми участниками процесса. Пока кто-то боится задать вопрос или уточнить детали, чтобы не показаться "некомпетентным", такие ситуации будут повторяться.
Многие проблемы решаются, если заранее договариваться о зонах ответственности и фиксировать ожидания: кто что делает и за что отвечает. Ну и метрики надо учитывать адекватно — смотреть не только на количество ошибок, но и на сложность задач и объем проделанной работы.
А еще очень важно нормально общаться в команде. Если есть честный диалог между менеджерами, постановщиками и разработчиками, таких ситуаций можно избежать.
А я и не говорю, что это нужно вводить в середине цикла разработки, когда все вредные привычки уже сформированы. Я тоже считаю, что это надо закладывать с самого начала и жестко обязывать команду соблюдать эту практику. А самоосознанность - это до первой горящей жопы перед релизом. Надо всё закреплять на уровне документации и бить по рукам за несоблюдение оговоренных правил.
А поддерживать потом как? Разработчику нужно одновременно работать минимум в трёх файлах в рамках одного компонента. Довольно сильно размывает фокус. Не подумайте, я не представляю противоположную точку зрения, я просто хочу для себя разобраться, как помочь проекту не скатиться в помойку.
У меня в голове только один вариант. На уровне команды и проекта определить минимальный порог, после которого мы будем дробить компонент. Например: простые компоненты <150-200 строк оставлять как есть, средние - до 300 или со сложной логикой дробить, страницы и контейнеры - всегда дробить (стили во всех случаях выносить отдельно).
Тем самым мы можем не распыляться на мелкую ерунду вроде кнопок или других маленьких компонентов и сосредоточиться на декомпозиции средних и больших модулей и страниц. Вроде то же самое, но экономим время на «мишуре» и фокусируемся на том, где дробление действительно решает.
Такое разбиение мне больше по душе, чем копание в месиве React-компонента. Но это сильно тормозит написание самого компонента (хотя и даёт преимущество в долгосрок). Бизнесу нужно быстро, а дробить кнопку на кучку файлов и повторять это раз за разом во всех последующих компонентах я считаю другой крайностью, как и писать всё в одном файле. «Месиво» против «Капусты» - наверное, нужен какой-то компромисс между этими подходами.
Корень проблемы, как мне кажется, в недосказанности между всеми участниками процесса. Пока кто-то боится задать вопрос или уточнить детали, чтобы не показаться "некомпетентным", такие ситуации будут повторяться.
Многие проблемы решаются, если заранее договариваться о зонах ответственности и фиксировать ожидания: кто что делает и за что отвечает. Ну и метрики надо учитывать адекватно — смотреть не только на количество ошибок, но и на сложность задач и объем проделанной работы.
А еще очень важно нормально общаться в команде. Если есть честный диалог между менеджерами, постановщиками и разработчиками, таких ситуаций можно избежать.