Это да. Как мне кажется, в fsd есть одна хорошая фундаментальная идея - разбивать бизнес-логику на слои, но вокруг этого раздута "методология" с кучей вопросов и ответов, у многих создаётся ложное представление, что этот грамотный подход присущ исключительно fsd. Достаточно сместить фокус из fsd в сторону принципиального разделения БЛ на слои, каждый из которых имеет свою зону ответственности и может быть доработан в абстракции от других - и окажется, что архитектура может быть совершенно разной (я предпочитаю древовидную) без жёстких рамок "здесь папки создаём с такими файликами, там с другими" - в итоге окажется, что fsd это только один из вариантов (кмк, не самый лучший, чтоб на нем зацикливаться)
Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...
Из личного опыта докину свои 50 копеек. Лучший инструмент - это тот который ты написал сам, т.к. он лучше всего подходит под твои задачи. В остальных случаях нужно подстраиваться под инструмент (каким бы он ни был красивым, продуманным, проработанным кем-то другим).
Пару советов насчёт тех проблем, что решил для себя, но, как вижу, не решил автор.
Совет 1. Чтоб не выгорать - не живите одним проектом; Даже если проект катится к чертям, важно сохранять позитивный настрой - тогда у него ещё есть шансы )
Совет 2. Локализуйте беспорядок до его появлении: если кто-то сделал чушь, эта помойка должна быть атомарной (где-то есть начало и конец) - вплоть до полного понимания что именно можно выпилить/заменить. Это вопросы абстракции и постановки задач.
Написанная тонна библиотек на протяжении лет развития реакта, начиная с 2013 года (я имею ввиду пакеты npm, которые пишут люди чтоб переиспользовать свой код в разных проектах) на классах сегодня может работать как же и новый код на хуках (да, есть рекомендации использовать функциональщину - от эволюции не уйдешь, к ней давно шли); а вот второй Ангуляр сломал представление о первом, что было большой ошибкой (кмк лучше бы ребрендинг) - доверия к нему уже тогда больше не стало, да и появился он позже в 2016 да ещё и с "ломающими изменениями" при переходе на второй -> его и меньше брали в прод с такими качелями (чего на тот момент ещё от него ожидать - было непонятно. Ок, про Ангуляр тогда не будем). Я к тому, что обратная совместимость - залог доверия и надёжности.
Да, пусть, реакт, библиотека, но сейчас она в топе.
Реакт в топе, потому что изначально соблюдал обратную совместимость, не ломаясь между версиями. В отличие от других (не будем показывать пальцем на Ангуляр, к примеру).
Мы про исходный код говорим (про стиль его написания). На клиенте мы увидим продукт сборки в действии (про него мы не говорим)
И не про браузер речь, разумеется, а про "хрупкий" и "надёжный" код (как написанный человеком исходник). Если нужны такие вводные, пожалуйста - мы исходим из того, что транспайлер отработал как надо, код везде выполняется одинаково, говорим только об обработке ошибок входных данных и приведена аналогия "красных лампочек в интерфейсе" как хороший пример ориентира, какая часть системы отказала в данный момент (защитное программирование в действии, "хрупкий" код не даст такого эффекта).
Хотя, допускаю, Вы могли не понять аналогию, ну да ладно.
А здесь уже про разное. Ошибки должны быть обработаны независимо от браузера. Я про Защитное программирование - думаю за ним будущее ) вы когда-нибудь бывали на каком-нибудь военном командном пункте какой-нибудь абстрактной установке? Представьте что, для каждой неисправности есть красная лампочка и табличка (это удобно, потому что это стандарт вывода ошибки) - и это модульная система, где каждый модуль легко заменяем и быстро диагностируется
Не соглашусь с Вами. Я фронт, пишу в духе Защитного программирования, для меня важно иметь возможность быстро (asap) разобраться, что пошло не так (чтоб не ждать круговорот тикета через тестеров и искать причину по тексту ошибки из бандла). Я понимаю, у каждого своя практика, но исходя из моей практики, ошибку мало обнаружить, надо обработать - так ещё и корректно сообщить интерфейсу (а ещё лучше отправить лог в виде сформулированной проблемы) для возможности быстро разобраться в чем дело (не просто бросить в консоль). Не обязательно делать проверки в каждой функции, достаточно проверить входные данные (к примеру, получив ответ по апишке, можно сразу провалидировать ответ, получив на выходе интуитивно понятное `{ ok: boolean; message?: string; }` - и в случае !ok мы уже не работаем с "хрупкими функциями", а с человекочитаемым сообщением: `"Есть проблема! Некорректный формат ответа на запрос '/me' -> user.policyId (получено: undefined, ожидается: string)"`.
А если такой контракт ошибок принят во всем нашем коде как единый стандарт - то, если где-либо что-то пошло не так по итогам стандартной валидации (которая написана один раз и ожидает конфиг с описанием правил на входе), мы уже всегда имеем возможность отправить соответствующие логи, зная что в строке event.message все уже грамотно сформулировано. При этом проверки будут описаны максимально декларативно и без паранойи )
В общем, вкусовщина и полезные привычки (у каждого свои).
Как вариант, предположу, этому господину нужен широкий монитор, чтоб все колонки влезли (тогда не пришлось бы переносить блоки). Но: Это прокатило бы в случае если задачи действительно перемещались постепенно из одного столбика в другой как в классической канбан-доске. Но глядя на скрин, я все же в этом сомневаюсь, т.к. задачи просто делятся на группы: У автора названия блоков - это не стадии задач, а разные группы соответствия (все гораздо проще, чем канбан). Отсюда я делаю вывод, что с канбаном здесь мало общего.
Алгоритм довольно прозрачен и был однажды описан здесь: Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/
Это да. Как мне кажется, в fsd есть одна хорошая фундаментальная идея - разбивать бизнес-логику на слои, но вокруг этого раздута "методология" с кучей вопросов и ответов, у многих создаётся ложное представление, что этот грамотный подход присущ исключительно fsd. Достаточно сместить фокус из fsd в сторону принципиального разделения БЛ на слои, каждый из которых имеет свою зону ответственности и может быть доработан в абстракции от других - и окажется, что архитектура может быть совершенно разной (я предпочитаю древовидную) без жёстких рамок "здесь папки создаём с такими файликами, там с другими" - в итоге окажется, что fsd это только один из вариантов (кмк, не самый лучший, чтоб на нем зацикливаться)
Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...
Из личного опыта докину свои 50 копеек. Лучший инструмент - это тот который ты написал сам, т.к. он лучше всего подходит под твои задачи. В остальных случаях нужно подстраиваться под инструмент (каким бы он ни был красивым, продуманным, проработанным кем-то другим).
Насчёт п 2. Мне тоже всегда switch-case нравился больше )
Добавьте скринов. А то запускать нет времени, а посмотреть охота, что у вас там получилось.
По Вашей наводке пошел искать. Зашёл. Поржал )
Отличное начало
Попробуйте прочитать ещё раз. Возможно не с первого раза, но что-то новое без сомнения должно открыться. Главное, не останавливайтесь на полпути )
Пару советов насчёт тех проблем, что решил для себя, но, как вижу, не решил автор.
Совет 1. Чтоб не выгорать - не живите одним проектом; Даже если проект катится к чертям, важно сохранять позитивный настрой - тогда у него ещё есть шансы )
Совет 2. Локализуйте беспорядок до его появлении: если кто-то сделал чушь, эта помойка должна быть атомарной (где-то есть начало и конец) - вплоть до полного понимания что именно можно выпилить/заменить. Это вопросы абстракции и постановки задач.
Написанная тонна библиотек на протяжении лет развития реакта, начиная с 2013 года (я имею ввиду пакеты npm, которые пишут люди чтоб переиспользовать свой код в разных проектах) на классах сегодня может работать как же и новый код на хуках (да, есть рекомендации использовать функциональщину - от эволюции не уйдешь, к ней давно шли); а вот второй Ангуляр сломал представление о первом, что было большой ошибкой (кмк лучше бы ребрендинг) - доверия к нему уже тогда больше не стало, да и появился он позже в 2016 да ещё и с "ломающими изменениями" при переходе на второй -> его и меньше брали в прод с такими качелями (чего на тот момент ещё от него ожидать - было непонятно. Ок, про Ангуляр тогда не будем). Я к тому, что обратная совместимость - залог доверия и надёжности.
Да, пусть, реакт, библиотека, но сейчас она в топе.
Реакт в топе, потому что изначально соблюдал обратную совместимость, не ломаясь между версиями. В отличие от других (не будем показывать пальцем на Ангуляр, к примеру).
В этом основной секрет "живых" фреймворков.
Ого, тут свои комменты удалять нельзя
[Комментарий удален]
(решил не комментировать обсуждение кода на языке на котором не пишу))
Я как раз не сторонник раздувать код.
Если все делать правильно, не повторяя свой код, он и будет выглядеть и весить соответственно.
Не делайте 100 проверок, делайте одну стандартно.
Мы про исходный код говорим (про стиль его написания). На клиенте мы увидим продукт сборки в действии (про него мы не говорим)
И не про браузер речь, разумеется, а про "хрупкий" и "надёжный" код (как написанный человеком исходник). Если нужны такие вводные, пожалуйста - мы исходим из того, что транспайлер отработал как надо, код везде выполняется одинаково, говорим только об обработке ошибок входных данных и приведена аналогия "красных лампочек в интерфейсе" как хороший пример ориентира, какая часть системы отказала в данный момент (защитное программирование в действии, "хрупкий" код не даст такого эффекта).
Хотя, допускаю, Вы могли не понять аналогию, ну да ладно.
А здесь уже про разное. Ошибки должны быть обработаны независимо от браузера. Я про Защитное программирование - думаю за ним будущее ) вы когда-нибудь бывали на каком-нибудь военном командном пункте какой-нибудь абстрактной установке? Представьте что, для каждой неисправности есть красная лампочка и табличка (это удобно, потому что это стандарт вывода ошибки) - и это модульная система, где каждый модуль легко заменяем и быстро диагностируется
Не соглашусь с Вами. Я фронт, пишу в духе Защитного программирования, для меня важно иметь возможность быстро (asap) разобраться, что пошло не так (чтоб не ждать круговорот тикета через тестеров и искать причину по тексту ошибки из бандла). Я понимаю, у каждого своя практика, но исходя из моей практики, ошибку мало обнаружить, надо обработать - так ещё и корректно сообщить интерфейсу (а ещё лучше отправить лог в виде сформулированной проблемы) для возможности быстро разобраться в чем дело (не просто бросить в консоль). Не обязательно делать проверки в каждой функции, достаточно проверить входные данные (к примеру, получив ответ по апишке, можно сразу провалидировать ответ, получив на выходе интуитивно понятное `{ ok: boolean; message?: string; }` - и в случае
!okмы уже не работаем с "хрупкими функциями", а с человекочитаемым сообщением: `"Есть проблема! Некорректный формат ответа на запрос '/me' -> user.policyId (получено: undefined, ожидается: string)"`.А если такой контракт ошибок принят во всем нашем коде как единый стандарт - то, если где-либо что-то пошло не так по итогам стандартной валидации (которая написана один раз и ожидает конфиг с описанием правил на входе), мы уже всегда имеем возможность отправить соответствующие логи, зная что в строке
event.messageвсе уже грамотно сформулировано. При этом проверки будут описаны максимально декларативно и без паранойи )В общем, вкусовщина и полезные привычки (у каждого свои).
Есть еще незначительные мелочи: tsconfig надо дописать (настроить директорию сборки); установить директорию для скринов и т.д.
А так, идея интересная
Все верно. Узнаваемый стиль принятия законов "бешеным принтером" в контексте "опа, тут тоже можно постричь бабки" - ничего нового.
Как вариант, предположу, этому господину нужен широкий монитор, чтоб все колонки влезли (тогда не пришлось бы переносить блоки). Но: Это прокатило бы в случае если задачи действительно перемещались постепенно из одного столбика в другой как в классической канбан-доске. Но глядя на скрин, я все же в этом сомневаюсь, т.к. задачи просто делятся на группы: У автора названия блоков - это не стадии задач, а разные группы соответствия (все гораздо проще, чем канбан). Отсюда я делаю вывод, что с канбаном здесь мало общего.
Во всяком случае, прогнозы даёт реалистичные.
Алгоритм довольно прозрачен и был однажды описан здесь: Теория вероятностей в действии 2.0 (суть алгоритма корректировки прогнозов разработчиков) https://habr.com/p/874226/