Дружище -- твой рисунок с подписью " Пример компонента с множеством зависимостей. Так — плохо " это отражение сути ООП и его базовой идеи на которой пляшет React, может ты перечитаешь ещё раз то? ради чего пришёл в отрасль, и перестанешь изгонять главную идею от которой всё идёт -- а подчинишь её себе и начнёшь использовать? Либо уж откажись, выкини ООП и сделай "классно" по-другому ( это возможно, только надо идеи понимать, а не убирать потому что "слооожнААА" ) Давно ли классные идеи, отличные идеи, идеи, просто, для аплодисментов появлялись корнем из бизнеса? Чёт ни одного примера не помню за 30 лет.
Очень надеялся увидеть исходя из заголовка: "Пишем хорошие компоненты, которые захочется переиспользовать, а плохие — не пишем" Увидеть главное -- ПРИМЕРЫ, как плохо и главное ПОЧЕМУ плохо с ПРАКТИЧЕСКИМ обоснованием, и как ХОРОШО -- с той же базой обоснования. По факту зря потратил время на чтение.
Я уржался уже на заголовке, проработав пресейлом почти 10 лет в телекоме могу сказать сразу кто останется без премии в лучшем случае, и кто пойдёт по собственному в худшем случае. От статьи я ожидал если честно не лечения -- а свода правил как в такое не попасть. Ещё момент -- раз так можно шить -- не стоило ЛИ сразу подстелить соломку и сделать конфиг чтобы шить можно было не отходя от кассы прямо в доме у клиента не трогая больные ноги из-за дурной головы? Методику как прошить роутеры не сложнее игры в тетрис -- не это хочется увидеть, так или иначе лыком мыком это можно, а вот то что технический пресейл у вас откуда-то из из того самого органа с универсальной шиной, что во-первых вы не пошли к нему спросить какого хрена, это по плану -- если не по плану какой путь решения -- явно говорит о том что кто пресейл и работает головой, а кто пресейл и деньги получает. К слову у нас были сходные пресейлы по входящим условиям, в моих проектах проектах тем более, все эти ситуации я просчитывал заранее, затем тестировал на предпилотной стадии в песочнице -- и только потом одобрял или отклонял в зависимости от ситуации. В статье описано решение головняка который вы не должны решать потому что он не должен состояться минимум из-за трёх человек которые стояли в цепочке -- но жизнь сурова : )
Неловкий вопрос -- архитектора вы наняли из моих преподов в универе, которых держали в подвале с годам моего выпуска в 2007 года? Я читал и просто ломал стул от смеха вместе с коллегами , а СМЫВ и ИУДА СМЫВА ( та самая пробка где-то рядом, будет ещё не один десяток лет мемом лично про вот это вот всё)
А теперь серьёзно.
Объём хозяйства 2500 запросов в секунду. Размазанный по десяти нодам это 250 в секунду. Где highload? Или насколько криво вы всё это написали что это стал highload? В вас не спутниковый канал валится с каждым запросом в 2ГБ, а сама логистика проста как пень, её талантливый студент за курсач нарисует, и за диплом сделает. Ещё и 11 месяцев отдыхать будет.
"Доставить любой ценой" -- лозунг прочитал, ничего о механизме не увидел, просто по нулям. Брокер сообщений это от Ивана Грозного ещё , давно устарело и неактуально, и нелогируемо, может возьмёте что-то понадёжнее?
И да, я в ИТ с 90 года, даже плотно на ассемблере посидел, во всех сферах поработал, чего только не видел и в сетях и в серверах и в виртуализации. Но то что стало с госуслугами это тихий ужас, у меня мама всю жизнь работала в КБ ещё в СССР корабли в космос запускала образно говоря -- но Ваш конечный продукт Гос Услуг она боится хуже барабашки. Вы делаете продукт НЕ ДЛЯ ЛЮДЕЙ -- факт. И Вам этот факт ВООБЩЕ НЕ ИНТЕРЕСЕН! А Ваш продукт по факту должен охватывать именно людей И БЫТЬ УДОБНЫМ ДЛЯ ЛЮДЕЙ хотя бы в общей массе до 85% -- а не Ваши безумные дизайнерские пляски в попытке личного изощрения непонятно над чем.
Всё вышесказанное субъективно -- но устройте голосование у людей
Теперь неловкий вопрос: react нам зачем в этом процессе? И его 500 мегабайт неизвестно чего которые нужно перед этим поставить с мольбой чтобы не рухнуло ( логов то нет ) ? От обычного вопроса: а почему не использовали ещё скобочки вида :%!"? и прочих вы успешно уклонились, когда читаешь код на react -- авторов react хочется придушить от количества видов скобок и несистемности их применения ( субъективно ) Теперь к практическим вопросам: логи исполнения -- где? Обработка очевидных ошибок в лог -- где? Декларация наименования того, что именуется, где? Если на выходе -- "абстрактная" ошибка или вообще ничего -- логи где? Сомнительно-клёвое "быстро отображает слои" упирается в HW -- так что нихрена оно не плюс. Зато Вы повысили входной порог специалиста с джуниора JS до чувака который должен знать react желательно не понаслышке с гуглом. И личный вопрос -- зачем вы притащили объекты в такой просто пример? Ради того чтобы замедлить исполнение? Или потому что "Вам сказали" что объекты это круто?
Дружище -- твой рисунок с подписью " Пример компонента с множеством зависимостей. Так — плохо " это отражение сути ООП и его базовой идеи на которой пляшет React, может ты перечитаешь ещё раз то? ради чего пришёл в отрасль, и перестанешь изгонять главную идею от которой всё идёт -- а подчинишь её себе и начнёшь использовать? Либо уж откажись, выкини ООП и сделай "классно" по-другому ( это возможно, только надо идеи понимать, а не убирать потому что "слооожнААА" )
Давно ли классные идеи, отличные идеи, идеи, просто, для аплодисментов появлялись корнем из бизнеса? Чёт ни одного примера не помню за 30 лет.
Очень надеялся увидеть исходя из заголовка: "Пишем хорошие компоненты, которые захочется переиспользовать, а плохие — не пишем"
Увидеть главное -- ПРИМЕРЫ, как плохо и главное ПОЧЕМУ плохо с ПРАКТИЧЕСКИМ обоснованием, и как ХОРОШО -- с той же базой обоснования. По факту зря потратил время на чтение.
Я уржался уже на заголовке, проработав пресейлом почти 10 лет в телекоме могу сказать сразу кто останется без премии в лучшем случае, и кто пойдёт по собственному в худшем случае. От статьи я ожидал если честно не лечения -- а свода правил как в такое не попасть. Ещё момент -- раз так можно шить -- не стоило ЛИ сразу подстелить соломку и сделать конфиг чтобы шить можно было не отходя от кассы прямо в доме у клиента не трогая больные ноги из-за дурной головы? Методику как прошить роутеры не сложнее игры в тетрис -- не это хочется увидеть, так или иначе лыком мыком это можно, а вот то что технический пресейл у вас откуда-то из из того самого органа с универсальной шиной, что во-первых вы не пошли к нему спросить какого хрена, это по плану -- если не по плану какой путь решения -- явно говорит о том что кто пресейл и работает головой, а кто пресейл и деньги получает. К слову у нас были сходные пресейлы по входящим условиям, в моих проектах проектах тем более, все эти ситуации я просчитывал заранее, затем тестировал на предпилотной стадии в песочнице -- и только потом одобрял или отклонял в зависимости от ситуации. В статье описано решение головняка который вы не должны решать потому что он не должен состояться минимум из-за трёх человек которые стояли в цепочке -- но жизнь сурова : )
Неловкий вопрос -- архитектора вы наняли из моих преподов в универе, которых держали в подвале с годам моего выпуска в 2007 года? Я читал и просто ломал стул от смеха вместе с коллегами , а СМЫВ и ИУДА СМЫВА ( та самая пробка где-то рядом, будет ещё не один десяток лет мемом лично про вот это вот всё)
А теперь серьёзно.
Объём хозяйства 2500 запросов в секунду. Размазанный по десяти нодам это 250 в секунду. Где highload? Или насколько криво вы всё это написали что это стал highload? В вас не спутниковый канал валится с каждым запросом в 2ГБ, а сама логистика проста как пень, её талантливый студент за курсач нарисует, и за диплом сделает. Ещё и 11 месяцев отдыхать будет.
"Доставить любой ценой" -- лозунг прочитал, ничего о механизме не увидел, просто по нулям. Брокер сообщений это от Ивана Грозного ещё , давно устарело и неактуально, и нелогируемо, может возьмёте что-то понадёжнее?
И да, я в ИТ с 90 года, даже плотно на ассемблере посидел, во всех сферах поработал, чего только не видел и в сетях и в серверах и в виртуализации. Но то что стало с госуслугами это тихий ужас, у меня мама всю жизнь работала в КБ ещё в СССР корабли в космос запускала образно говоря -- но Ваш конечный продукт Гос Услуг она боится хуже барабашки. Вы делаете продукт НЕ ДЛЯ ЛЮДЕЙ -- факт. И Вам этот факт ВООБЩЕ НЕ ИНТЕРЕСЕН! А Ваш продукт по факту должен охватывать именно людей И БЫТЬ УДОБНЫМ ДЛЯ ЛЮДЕЙ хотя бы в общей массе до 85% -- а не Ваши безумные дизайнерские пляски в попытке личного изощрения непонятно над чем.
Всё вышесказанное субъективно -- но устройте голосование у людей
Теперь неловкий вопрос: react нам зачем в этом процессе? И его 500 мегабайт неизвестно чего которые нужно перед этим поставить с мольбой чтобы не рухнуло ( логов то нет ) ?
От обычного вопроса: а почему не использовали ещё скобочки вида :%!"? и прочих вы успешно уклонились, когда читаешь код на react -- авторов react хочется придушить от количества видов скобок и несистемности их применения ( субъективно )
Теперь к практическим вопросам: логи исполнения -- где? Обработка очевидных ошибок в лог -- где? Декларация наименования того, что именуется, где? Если на выходе -- "абстрактная" ошибка или вообще ничего -- логи где?
Сомнительно-клёвое "быстро отображает слои" упирается в HW -- так что нихрена оно не плюс.
Зато Вы повысили входной порог специалиста с джуниора JS до чувака который должен знать react желательно не понаслышке с гуглом.
И личный вопрос -- зачем вы притащили объекты в такой просто пример? Ради того чтобы замедлить исполнение? Или потому что "Вам сказали" что объекты это круто?