FSD - это когда авторы опять решили, что Clean Architecture слишком сложно и вообще непонятно, нужно обязательно скрыть всё это структурой папок. Попутно решили, что фронт и бэк вещи не совместимые, слои там разные, логика разная, напишем об этом прямо на главной странице и окончательно превратим идею в монстра Франкенштейна.
Вся проблема с "реальными" РПГ и геймификацией в целом в том, что она подразумевает наличие правильного пути достижения правильной цели. В реальной жизни таких условий не существует.
Радостный такой иду на сайт... А там только предзаказ... Только бумаги... Ладно, предзаказа цифры нет, но даже выпущенные книги половины нет в цифре, что глубоко печально :(
ТС путает тёплое с мягким, сначала говорит про гуманитариев, потом почему-то переключается на поведенческие паттерны, а в конце признаётся, что всех нас налюбил кликбейтным заголовком. Не будьте, как ТС.
Ну, и раз в тексте есть типичная ошибка обращения к уникальной выборке, давайте я тоже сыграю на этом поле. Я гуманитарий, за спиной филфак и истфак, в разработку попал случайно, начинал с админства сайтов, сейчас занимаюсь всяческим engineering management'ом.
Имею ровно противоположный опыт: подавляющее большинство "технарей" и всяческих выпускников профильных ВУЗов обладают максимальной психической ригидностью в том, что касается работы. В идеале, решение должно быть написано в книге, документации, докладе, в общем, зафиксировано. И вообще, "всегда делали вот ТАК, зачем делать по-другому".
Выходцев из "технарей", особенно СТО, это тоже касается. "Мы не будем пользоваться этим инструментом, потому что я когда-то пользовался, мне не понравилось, значит инструмент плохой" - сплошь и рядом встречал.
Теперь осталось опровергнуть моё личный опыт чужим личным опытом и так мы быстро доберёмся до мордобоя :)
Извините, но это просто накиданные рандомно игры с тегом "космос". И всего списка действительно похоже на SF только The Outer Worlds и, с очень большой натяжкой, Mass Effect. Можно так же отнести Немужицкое небо сюда, но это сравнение затрагивает только де необязательные активности из SF, что так же сводит сравнение на нет.
Я читал и "Мама, я тимлид!" и "Карьера Software Engineering Manager". Лично моё мнение - именно для новичка-практика "Мама" гораздо лучше. Лаконичная, конкретная, проблемно-ориентированная. Её я даю читать ребятам, кого промоутят в лиды.
А вот "Карьера" это здоровенный талмуд с текстом в лучших традициях американской школы науч-попа. Автор чрезвычайно многословен, постоянно растекается мыслью по древу и норовит свернуть в какие-нибудь исторические дебри или личные переживания по типу "когда мы были молодыми". Скажу честно, я не смог осилить её целиком и очень много просмотрел по диагонали.
Но есть вариант, когда я бы советовал именно почитать именно "Карьеру". Это отличный обзорник для HR, малоопытных CTO и прочих нанимающих менеджеров, чтобы они понимали, кто такой Software Engineering Manager сегодня и что вообще такой специалист в дикой природе существует.
Это да, это нормально :) Founding CTO, вот это вот всё. Понятное дело, что в вакансии предполагался какой-то "сформировавшийся уже" продукт, от того и странности.
Смотря что это за приложение и что именно считать бизнес логикой. Например, сложный wizard, экраны и поля которого динамически определяются на основе данных на клиенте и который должен породить некую бизнес сущность.
Бля меня глобально отличается тем, что это view-компонент конкретной библиотеки представления. Если вы пишите бизнес логику (возьмём пример с контролом паспорта выше) в таком компоненте, а потом тестируете его, то, по факту, вы пишите интеграционный тест, ведь нужно ещё эмулировать виртуальный дом, работу рантайма реактуа и тд и всё это ради чего? Чтобы проверить разметку при двух вариантах if? Вы реально сомневаетесь в способностях реакта к условному рендерингу?
Но вот код, который генерирует тот самый bool для контрола на основе входящих данных протестить хочется, но как это сделать, не делая тест на компонент реакта? Вынести логику и использовать её как сторонний сервис по отношению к компоненту.
В этом случае код автоматически разделяется по слоям, представление зависит от логики, а мы получаем маленький и простой тест.
S в SOLID означает Single Responsibility — единственная ответственность Разбивайте код на модули, каждый из которых имеет одну ответственность.
Видишь такое в статье про SOLID - можно смело пропускать. Ну, сколько можно из раза в раз повторять одну и ту же повсеместную ошибку! Я уже говорил, что такое безумие?!
Давайте просто заглянем в источник (будет локализованный вариант, да простят меня адепты английского):
Традиционно принцип единственной ответственности описывался так: Модуль должен иметь одну и только одну причину для изменения.
<...>
Фактически принцип можно перефразировать так: Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо.
<...>
Соответственно, окончательная версия принципа единственной ответственности выглядит так: Модуль должен отвечать за одного и только за одного актора.
Неужели там нет ни слова про разделение кода на мелкие части с одной функциональностью? На самом деле, есть, прямо выше по тексту!
Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.
Я как-то видел на Хабр.Карьере вакансию СТО с описанием в стиле "нужно писать весь код самому, а существующий СТО идёт пилить новый проект". Так что кто знает, кто там скрывается за шильдиком :)
Если вас пригласили в команду быть пугалом это значит, что и ваше руководство не умеет работать с людьми. Рано или поздно то же пугало придёт к вам и будет бить Ван Даммом по лицу.
Полностью поддерживаю пример выше своим опытом. HRBP это, конечно, хорошо, но Team Lead ДОЛЖЕН знать своих людей и уметь работать с ними. Если у него не хватает конкретных навыков для этого - ок, устройте внутреннее обучение для лидов, пригласите психолога. Человек принципиально не в состоянии работать с этим процессом? Ок, он не Team Lead. Всё. Никаких отговорок. Tech Lead? Да, вполне. Lead, а то и Stuff Developer? Наверняка. Architect? Скорее всего. Но не лид команды...
Хочу осторожно заметить, что тезис "Часто можно услышать такие определения, как Retention, ROI и прочие." объясняется очень легко.
Retention и ROI это действительно метрики, то есть собираемая информация о деятельности неких акторов, а так же вторичные данные, собираемые на их основе.
У вас же метриками почему-то называются статичные параметры игрового мира. Честно говоря, я впервые в жизни вижу, чтобы кто-то называл их метриками.
Я мог бы предположить, что это калька с английского, принятая в геймдеве, но даже в английском смысл сводится к "числам и статистическим данным, позволяющим оценить успешность деятельности".
Перенесение боёвки ДнД в цифру как было отвратительной идеей во времена тройки, так и сейчас. Полностью лишний, ненужный атавизм, превращающий любой бой в часовое пошаговое закликивание врага.
У Ларианов своя система была гораздо более динамична и вариативна, что в очередной раз напоминает нам - "самая популярная ролевая система в мире" давно и прочно пшик.
Окей, согласен. Я наивно надеялся, что при выходе в офис там что-то меняется. Люди там сразу общаться начинают и вот это вот всё, иначе зачем вообще нужен офис?
Зато сразу видно следующий потенциальный рынок. Будет Ньютон Мини какой-нибудь.
Сделал для себя открытие на Хабре, подписался.
Написаны очень правильные вещи, которые откликаются у меня, буду ждать новостей про проект как с точки зрения бизнеса, так и с точки зрения медицины.
Успеха вам!
FSD - это когда авторы опять решили, что Clean Architecture слишком сложно и вообще непонятно, нужно обязательно скрыть всё это структурой папок. Попутно решили, что фронт и бэк вещи не совместимые, слои там разные, логика разная, напишем об этом прямо на главной странице и окончательно превратим идею в монстра Франкенштейна.
В целом, лучше бы был минус один подход.
Пока я всё это изучу, успею умереть, переродиться, как раз выйдет третий дайджест и придётся нагонять...
P.S. Спасибо, не хватало не-языковых дайдежстов!
Вся проблема с "реальными" РПГ и геймификацией в целом в том, что она подразумевает наличие правильного пути достижения правильной цели. В реальной жизни таких условий не существует.
Радостный такой иду на сайт... А там только предзаказ... Только бумаги... Ладно, предзаказа цифры нет, но даже выпущенные книги половины нет в цифре, что глубоко печально :(
ТС путает тёплое с мягким, сначала говорит про гуманитариев, потом почему-то переключается на поведенческие паттерны, а в конце признаётся, что всех нас налюбил кликбейтным заголовком. Не будьте, как ТС.
Ну, и раз в тексте есть типичная ошибка обращения к уникальной выборке, давайте я тоже сыграю на этом поле. Я гуманитарий, за спиной филфак и истфак, в разработку попал случайно, начинал с админства сайтов, сейчас занимаюсь всяческим engineering management'ом.
Имею ровно противоположный опыт: подавляющее большинство "технарей" и всяческих выпускников профильных ВУЗов обладают максимальной психической ригидностью в том, что касается работы. В идеале, решение должно быть написано в книге, документации, докладе, в общем, зафиксировано. И вообще, "всегда делали вот ТАК, зачем делать по-другому".
Выходцев из "технарей", особенно СТО, это тоже касается. "Мы не будем пользоваться этим инструментом, потому что я когда-то пользовался, мне не понравилось, значит инструмент плохой" - сплошь и рядом встречал.
Теперь осталось опровергнуть моё личный опыт чужим личным опытом и так мы быстро доберёмся до мордобоя :)
Извините, но это просто накиданные рандомно игры с тегом "космос". И всего списка действительно похоже на SF только The Outer Worlds и, с очень большой натяжкой, Mass Effect. Можно так же отнести Немужицкое небо сюда, но это сравнение затрагивает только де необязательные активности из SF, что так же сводит сравнение на нет.
Я читал и "Мама, я тимлид!" и "Карьера Software Engineering Manager". Лично моё мнение - именно для новичка-практика "Мама" гораздо лучше. Лаконичная, конкретная, проблемно-ориентированная. Её я даю читать ребятам, кого промоутят в лиды.
А вот "Карьера" это здоровенный талмуд с текстом в лучших традициях американской школы науч-попа. Автор чрезвычайно многословен, постоянно растекается мыслью по древу и норовит свернуть в какие-нибудь исторические дебри или личные переживания по типу "когда мы были молодыми". Скажу честно, я не смог осилить её целиком и очень много просмотрел по диагонали.
Но есть вариант, когда я бы советовал именно почитать именно "Карьеру". Это отличный обзорник для HR, малоопытных CTO и прочих нанимающих менеджеров, чтобы они понимали, кто такой Software Engineering Manager сегодня и что вообще такой специалист в дикой природе существует.
Это да, это нормально :) Founding CTO, вот это вот всё. Понятное дело, что в вакансии предполагался какой-то "сформировавшийся уже" продукт, от того и странности.
Смотря что это за приложение и что именно считать бизнес логикой. Например, сложный wizard, экраны и поля которого динамически определяются на основе данных на клиенте и который должен породить некую бизнес сущность.
Можете.
Бля меня глобально отличается тем, что это view-компонент конкретной библиотеки представления.
Если вы пишите бизнес логику (возьмём пример с контролом паспорта выше) в таком компоненте, а потом тестируете его, то, по факту, вы пишите интеграционный тест, ведь нужно ещё эмулировать виртуальный дом, работу рантайма реактуа и тд и всё это ради чего? Чтобы проверить разметку при двух вариантах if? Вы реально сомневаетесь в способностях реакта к условному рендерингу?
Но вот код, который генерирует тот самый bool для контрола на основе входящих данных протестить хочется, но как это сделать, не делая тест на компонент реакта? Вынести логику и использовать её как сторонний сервис по отношению к компоненту.
В этом случае код автоматически разделяется по слоям, представление зависит от логики, а мы получаем маленький и простой тест.
Видишь такое в статье про SOLID - можно смело пропускать.
Ну, сколько можно из раза в раз повторять одну и ту же повсеместную ошибку! Я уже говорил, что такое безумие?!
Давайте просто заглянем в источник (будет локализованный вариант, да простят меня адепты английского):
Неужели там нет ни слова про разделение кода на мелкие части с одной функциональностью? На самом деле, есть, прямо выше по тексту!
Я как-то видел на Хабр.Карьере вакансию СТО с описанием в стиле "нужно писать весь код самому, а существующий СТО идёт пилить новый проект". Так что кто знает, кто там скрывается за шильдиком :)
Как тестировать фронтенд, кратко:
Не пишем бизнес логику внутри представлений
Вообще никогда не пишем бизнес логику внутри представлений
Совсем никогда не пишем бизнес логику внутри представлений
Пишем юнит-тесты на бизнес логику
Если вам всё ещё хочется писать тесты на фронтенд, возможно вам нужно тестирование скриншотами
P.S. Исключения могут составлять общие компоненты со сложной собственной UI логикой. Например, самописный tooltip.
Если вас пригласили в команду быть пугалом это значит, что и ваше руководство не умеет работать с людьми. Рано или поздно то же пугало придёт к вам и будет бить Ван Даммом по лицу.
Полностью поддерживаю пример выше своим опытом. HRBP это, конечно, хорошо, но Team Lead ДОЛЖЕН знать своих людей и уметь работать с ними. Если у него не хватает конкретных навыков для этого - ок, устройте внутреннее обучение для лидов, пригласите психолога. Человек принципиально не в состоянии работать с этим процессом? Ок, он не Team Lead. Всё. Никаких отговорок. Tech Lead? Да, вполне. Lead, а то и Stuff Developer? Наверняка. Architect? Скорее всего. Но не лид команды...
Хочу осторожно заметить, что тезис "Часто можно услышать такие определения, как Retention, ROI и прочие." объясняется очень легко.
Retention и ROI это действительно метрики, то есть собираемая информация о деятельности неких акторов, а так же вторичные данные, собираемые на их основе.
У вас же метриками почему-то называются статичные параметры игрового мира. Честно говоря, я впервые в жизни вижу, чтобы кто-то называл их метриками.
Я мог бы предположить, что это калька с английского, принятая в геймдеве, но даже в английском смысл сводится к "числам и статистическим данным, позволяющим оценить успешность деятельности".
Перенесение боёвки ДнД в цифру как было отвратительной идеей во времена тройки, так и сейчас. Полностью лишний, ненужный атавизм, превращающий любой бой в часовое пошаговое закликивание врага.
У Ларианов своя система была гораздо более динамична и вариативна, что в очередной раз напоминает нам - "самая популярная ролевая система в мире" давно и прочно пшик.
Окей, согласен. Я наивно надеялся, что при выходе в офис там что-то меняется. Люди там сразу общаться начинают и вот это вот всё, иначе зачем вообще нужен офис?