Хороший вопрос. Как объяснил дизайнер у нас предусмотрено их две. Но данный подход как раз направлен больше на разработчиков) Постараюсь объяснить: - дизайнер сделал модальную форму; - написали компонент который нужно использовать; - сделали одну модалку; - следующий новый разработчик создал еще 10-20 по какой то бизнес задаче; - используя этот компонент, но накосячил с версткой; * пропустили по какой-то причине такой код в прод; - потом еще создали по образцу еще пачку модалок; итого получаем N-oe количество не корректных модальных форм. Суть этого подхода как раз и подсветить разработчику, что надо использовать (даже одну ту единственную), которая стандартизирована, не стоит придумывать новую. Таким образом мы четко знаем что наша данная модалка или любой другой компонент основанный на данном подходе, будь то таблица или что то другое, будет соответствовать требованиям. Естественно если дизайнер накосячил и сам использовал не тот стандарт, тут уже вопросы будут к дизайнеру. Перед разработкой данного компонента мы с дизайнером четко прорабатывали возможные варианты, и пришли к стандартным вариантам. Проблема заключалась в том что эти модалки насоздавались не по стандартам. Все мы люди и свойственны делать ошибки, а так же их копировать - один не так сделал, второй подхватил некорректный вариант и тоже не так сделал. Вот и пытаемся всячески подсветить некорректное использование разработчику.
О вас как о человеке можно судить по вашим комментариям, я вам дважды говорил вести диалог соблюдая субординацию, и вы не понимаете а только и можете что обзывать, и вякать не обоснованно. Покажите место с плохим кодом? может вы и кодить не умеете, а только кукарекаете, и наличие статьи ещё не о чем не говорит. Спасибо за эту нелепую демагогию. Продолжать её не собираюсь.
Тогда разбираемся с дизайнером почему так. Если иначе никак и она действительно уникальна то и пиши кастомную модальную форму и не используй целый набор компонентов. Либо второй вариант мы обговариваем с дизайнером что появляется еще один тип МФ и расширяем функционал.
На счет данного комментария
заставляя повторять ваш плохой код
Почему плохой? Можете объяснить что плохого вы там увидели? Я возьму себе на вооружение если вы приведете действительно обоснованные аргументы. Ну и желательно несколько моментов, так назвать код плохим по одному конкретному месту, ну как-то странно) Мы все же люди и допускаем ошибки.
Далее... Разработчику просто нужно использовать один из подготовленных компонентов. Ему не нужно писать целые портянки кода что бы сделать то что просят? а наоборот взять готовое решение и его заюзать.
Вот Вы пишите таблицу, для неё сделали специальную строку-компонент. Вы ее связываете с главным компонентом Table, и точно уверены что там будет то что нужно, иначе вы создаете кастомную таблицу с кастомной строкой, и уже точно знаете какой с неё спрос, если она не удовлетворяет стандартам потому что в дизайне её не сделали таковой, зачем нужны тогда UI-Kit`s пишите везде кастомно, вдруг какую то кнопку и т.п не так сделают. Так лучше размышлять?
Я понимаю что можно писать красиво, но не все так делают, и что бы на ревью не заставлять разработчика делать иначе, можно сделать это на этапе разработки. Можно вопрос, у Вас линтеру такое же отношение, вы читали статьи по настройке линтера? Там такие же примеры с писюлькой приводите в комментах, или же все таки согласны что лучше разработчик сразу сделает как надо, или вы потом когда код будете проверять сами переделаете / на доработку отправите?
Так вот именно что эти правила не все читают, самый первый комментарий который написали - нужны гайдлайны, я с этим согласен, и в дополнение к этим правилам можно применить блокировки подобные туториалу, в сообщение с ошибкой можно указать ссылку на этой гайдлайн, в которой сказано «не суйте писюль в микроволновку - это не правильно, она не для этого» и что вы тут плохо то видите я не пойму, это не палки в колеса - это инструмент оповещающий разработчика, что следует использовать, у нас имеются специально созданные модальные формы, которые прописаны стилистически верно, все что нужно сделать это почитать ошибку+гайдлайн и сделать что просят - использовать готовый компонент. Тут наоборот мы избавляем разработчика от необходимости писать стили и т.п потому что это все уже сделано!
Ну тогда и линтеры нахрен нужны, Вы я как вижу тоже за разработчиками все дописываете?! И пишет у вас тоже кто как хочет, не придерживаясь никаких правил. Не хотелось бы работать под вашим началом. Честно собрались почти одни хейтеры, увидели фразу "ЗАПРЕТИТЬ ..." и понеслось, даже код врядли смотрели. Всего пару существенных комментариев по которым можно было бы развести дискуссию и пообщаться, что-то улучшить, послушать как другие справляются с этой проблемой. А тут только "Это все чушь, нахрен это надо и т.п.". Значит Вам повезло что Вы не сталкивались пока с такими проблемами.
пример больше для понятности связей и зависимостей. Может я грубо сказал что прямо в html используется тот же паттерн, но в целом он очень похож, ну на счет его сомнения тут он не прост в понимании и я хотел показать как раз очередной пример его использования помимо уже заезженных таблиц со строками. Плюс показать как можно его немного доработать.
Да. Давайте не будем, но уверяю вас ни один уважающий себя тимЛид не будет за вас что то допиливать. Предлагаю закончить данную темагогию, и буду ждать комментарии по коду, так как по теме обязанностей мы сошлись на том что есть разные цели команд.
Странное у вас отношение к работе, но кто я что бы Вас судить. В таком случае, либо Вы играете (работаете) по правилам компании, либо ищите другую компанию - все верно. Но прежде чем ливать стоит задуматься, а может человек который код-ревью проводит знает по больше меня, подольше работает в компании, раз он знает как использовать компонент, а я нет.
Нужно просто читать ошибки, а не игнорить их. Они и нужны как раз для помощи, а не просто испоганить рабочий день разработчику. Разработчик который не читает ошибки, значит еще не достаточно опытный разработчик, и как раз от таких, и надо защищать код. Решение остается за каждым свое, но код-ревью есть почти в каждой команде, по крайней мере уважающей себя команде, потому если разработчик пытается обойти ты что предусмотрено правилом, то у меня к нему были бы большие вопросы. Аналогично я бы задал вопросы разработчику который вместо того что бы следовать стилю кода ставил везде игноры для линтера. Так и тут тоже самое.
Что-то вы сильно зациклились на HTML примере:) статья совсем не об этом. Буду рад более компетентному комментарию от вас. Почитайте внимательно статью.
На счет документации согласен, и использование её в комбо с кодовыми блокировками будет супер подходом. На счет линтера, не могу ничего сказать, как то этот подход обошел меня)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Хороший вопрос. Как объяснил дизайнер у нас предусмотрено их две. Но данный подход как раз направлен больше на разработчиков) Постараюсь объяснить:
- дизайнер сделал модальную форму;
- написали компонент который нужно использовать;
- сделали одну модалку;
- следующий новый разработчик создал еще 10-20 по какой то бизнес задаче;
- используя этот компонент, но накосячил с версткой;
* пропустили по какой-то причине такой код в прод;
- потом еще создали по образцу еще пачку модалок;
итого получаем N-oe количество не корректных модальных форм.
Суть этого подхода как раз и подсветить разработчику, что надо использовать (даже одну ту единственную), которая стандартизирована, не стоит придумывать новую. Таким образом мы четко знаем что наша данная модалка или любой другой компонент основанный на данном подходе, будь то таблица или что то другое, будет соответствовать требованиям.
Естественно если дизайнер накосячил и сам использовал не тот стандарт, тут уже вопросы будут к дизайнеру. Перед разработкой данного компонента мы с дизайнером четко прорабатывали возможные варианты, и пришли к стандартным вариантам. Проблема заключалась в том что эти модалки насоздавались не по стандартам.
Все мы люди и свойственны делать ошибки, а так же их копировать - один не так сделал, второй подхватил некорректный вариант и тоже не так сделал. Вот и пытаемся всячески подсветить некорректное использование разработчику.
О вас как о человеке можно судить по вашим комментариям, я вам дважды говорил вести диалог соблюдая субординацию, и вы не понимаете а только и можете что обзывать, и вякать не обоснованно. Покажите место с плохим кодом? может вы и кодить не умеете, а только кукарекаете, и наличие статьи ещё не о чем не говорит. Спасибо за эту нелепую демагогию. Продолжать её не собираюсь.
Тогда разбираемся с дизайнером почему так. Если иначе никак и она действительно уникальна то и пиши кастомную модальную форму и не используй целый набор компонентов.
Либо второй вариант мы обговариваем с дизайнером что появляется еще один тип МФ и расширяем функционал.
На счет данного комментария
Почему плохой? Можете объяснить что плохого вы там увидели? Я возьму себе на вооружение если вы приведете действительно обоснованные аргументы. Ну и желательно несколько моментов, так назвать код плохим по одному конкретному месту, ну как-то странно) Мы все же люди и допускаем ошибки.
Далее... Разработчику просто нужно использовать один из подготовленных компонентов. Ему не нужно писать целые портянки кода что бы сделать то что просят? а наоборот взять готовое решение и его заюзать.
Вот Вы пишите таблицу, для неё сделали специальную строку-компонент. Вы ее связываете с главным компонентом Table, и точно уверены что там будет то что нужно, иначе вы создаете кастомную таблицу с кастомной строкой, и уже точно знаете какой с неё спрос, если она не удовлетворяет стандартам потому что в дизайне её не сделали таковой, зачем нужны тогда UI-Kit`s пишите везде кастомно, вдруг какую то кнопку и т.п не так сделают. Так лучше размышлять?
Я понимаю что можно писать красиво, но не все так делают, и что бы на ревью не заставлять разработчика делать иначе, можно сделать это на этапе разработки. Можно вопрос, у Вас линтеру такое же отношение, вы читали статьи по настройке линтера? Там такие же примеры с писюлькой приводите в комментах, или же все таки согласны что лучше разработчик сразу сделает как надо, или вы потом когда код будете проверять сами переделаете / на доработку отправите?
Ещё разок попрошу на вы, тыкать на базаре будете.
Так вот именно что эти правила не все читают, самый первый комментарий который написали - нужны гайдлайны, я с этим согласен, и в дополнение к этим правилам можно применить блокировки подобные туториалу, в сообщение с ошибкой можно указать ссылку на этой гайдлайн, в которой сказано «не суйте писюль в микроволновку - это не правильно, она не для этого» и что вы тут плохо то видите я не пойму, это не палки в колеса - это инструмент оповещающий разработчика, что следует использовать, у нас имеются специально созданные модальные формы, которые прописаны стилистически верно, все что нужно сделать это почитать ошибку+гайдлайн и сделать что просят - использовать готовый компонент. Тут наоборот мы избавляем разработчика от необходимости писать стили и т.п потому что это все уже сделано!
Ну тогда и линтеры нахрен нужны, Вы я как вижу тоже за разработчиками все дописываете?! И пишет у вас тоже кто как хочет, не придерживаясь никаких правил. Не хотелось бы работать под вашим началом. Честно собрались почти одни хейтеры, увидели фразу "ЗАПРЕТИТЬ ..." и понеслось, даже код врядли смотрели. Всего пару существенных комментариев по которым можно было бы развести дискуссию и пообщаться, что-то улучшить, послушать как другие справляются с этой проблемой. А тут только "Это все чушь, нахрен это надо и т.п.". Значит Вам повезло что Вы не сталкивались пока с такими проблемами.
пример больше для понятности связей и зависимостей. Может я грубо сказал что прямо в html используется тот же паттерн, но в целом он очень похож, ну на счет его сомнения тут он не прост в понимании и я хотел показать как раз очередной пример его использования помимо уже заезженных таблиц со строками. Плюс показать как можно его немного доработать.
Для начала пожалуйста на вы, мы не на базаре, а в продолжение извинятся ни за что не собираюсь
?
Да. Давайте не будем, но уверяю вас ни один уважающий себя тимЛид не будет за вас что то допиливать. Предлагаю закончить данную темагогию, и буду ждать комментарии по коду, так как по теме обязанностей мы сошлись на том что есть разные цели команд.
Странное у вас отношение к работе, но кто я что бы Вас судить. В таком случае, либо Вы играете (работаете) по правилам компании, либо ищите другую компанию - все верно. Но прежде чем ливать стоит задуматься, а может человек который код-ревью проводит знает по больше меня, подольше работает в компании, раз он знает как использовать компонент, а я нет.
Нужно просто читать ошибки, а не игнорить их. Они и нужны как раз для помощи, а не просто испоганить рабочий день разработчику. Разработчик который не читает ошибки, значит еще не достаточно опытный разработчик, и как раз от таких, и надо защищать код. Решение остается за каждым свое, но код-ревью есть почти в каждой команде, по крайней мере уважающей себя команде, потому если разработчик пытается обойти ты что предусмотрено правилом, то у меня к нему были бы большие вопросы.
Аналогично я бы задал вопросы разработчику который вместо того что бы следовать стилю кода ставил везде игноры для линтера. Так и тут тоже самое.
И во время pull request-а получает по рукам от ревьюера. Как раз для этого это все и задумано?
Что-то вы сильно зациклились на HTML примере:) статья совсем не об этом. Буду рад более компетентному комментарию от вас. Почитайте внимательно статью.
На счет документации согласен, и использование её в комбо с кодовыми блокировками будет супер подходом. На счет линтера, не могу ничего сказать, как то этот подход обошел меня)