Pull to refresh
2
0

Фронтэнд-разработчик

Send message
Как эти проблемы решает описанный подход?

Какой "описанный подход"?


И это только стор и роутер из явных зависимостей.

Мой "стор" выражается ключевым словом class и никаких зависимостей, не относящихся к работе с данными приложения не требует. А к чему вы тут роутер припахали — для меня вообще загадка. Роутер не относится к работе с данными.


С накрученными по пути контекстами, кастомными хуками, редукс мидлварями и прочим, о каком-то рефакторинге будут говорить разве что шепотом.

Если вы работаете с редаксом — мои соболезнования. Я не работаю и никому не советую этого делать.
Контексты и хуки относятся к реакту, и к работе над данными никогда не привлекаются. Да и не должны. Если вы без реакта не можете написать модельную часть приложения (работу с данными, собссно) — проблема в вас.


Как этому противоречат юнит тесты?

Я где-то написал, что юнит-тесты этому противоречат?

Не тестируй библиотеку, тестируй свой код. Для всего скопа языков так говорят. Для мира js не так?

Ну так что вы протестируете, взяв реакт-компоненты и rtl?
Море всего, на самом деле, но "своего кода" там будет совсем чуть, а проверять его поведение вы будете внутри вороха абстракций. В то время, как для презентационного слоя единственный критерий прохождения или не прохождения приемки — это чтоб оно всё появилось в реальном браузере и отработало в нем же. Работает ли оно внутри абстракций rtl — это вообще абсолютно никого не волнует.

Во-первых, в контексте rtl тестирование компонентов уже не является юнит.

Да, и поэтому нужно тащить что-то еще для мокирования компонент (типа enzyme), если уж вы вступили на эту кривую дорожку. А то еще и тесты будут не юнит, а хренпоймичто.


Во-вторых, что плохого в покрытии веток кода тестами?

Ровно то же плохое, что и в лопаньи пузырьков на пленке. То есть, в общем-то ничего, просто само по себе это совершенно бесполезное занятие, на выходе которого имеем только кучу попорченной пленки. А в нашем случае — гору кода, которая ничего полезного не делает, и будет дальше жрать время на поддержку, пока кто-нибудь её не выкинет из проекта нафиг.


В-третьих, е2 тесты все равно должны быть.

Какое отношение это всё имеет к rtl и статье? Я где-то в своем комментарии сказал, что тестов не надо вообще?

Интеграционный тест компонента показывает, что внутренняя логика работает как ожидается.

И случаев, когда вам в компоненте нужно столько логики, что её уже неплохо бы тестировать — крайне мало. Но поскольку случаи наворачивания логики внутрь компонента обычно (обычно в идеале, а не обычно когда усилиями традиционных "программистов на реакте" в компонентах оказывается весь код проекта) касается специфических разборок с DOM, то даже и тут тестирование этого на ненастоящем игрушечном DOM — бесполезно.


Если же ваша "внутренняя логика" компонента не совершенно примитивна (взяли уже приготовленные данные, отобразили эти данные как есть) и не написана ради оптимизаций и решения сложных проблем DOM — то ей не место внутри компонента.


Если вам приходится переписывать тесты если не изменился функционал, то у вы пишете странные и бесполезные тесты.

Вы статью-то вообще читали? Когда сторона тестов дёргает сторону тестируемого кода через селекторы, завязывающиеся на конкретные теги, классы, или (обоже) тексты — вам неизбежно придётся писать "странные и бесполезные" тесты, которые будут ломаться так сразу, как только в компоненте поменяется хоть что-нибудь по его форме (и плевать, что по смыслу не поменяется ничего).

А эти вообще чистые рельсы с выбором в диалогах «дать по морде» и «всё равно дать по морде». Ещё дальше от фоллаутов, чем ведьмак.

Давайте будем честными: фоллауты состоят из рельсов тоже примерно полностью (да и вообще любая CRPG), просто маскируют это чуток получше. В обоих фоллаутах один абсолютно невариабельный в ключевых событиях сюжет, два относительно разных способа пройти мейнквест в Ф1, и у каждого из этих разных способов еще по 2-3 пути, отличающихся уж совсем незначительными деталями. А в Ф2 и вовсе один способ. И дополнительные локации, почти все из которых (за исключением очень редких ситуаций) являются целиком "вещью в себе", т.е. ты можешь придти, как-то сделать или не сделать мейнквест локации, и в зависимости от исхода увидеть тот или иной финальный слайд про эту локацию, или… вообще не приходить, от этого ничего в остальном прохождении не меняется.


Разница тут в том, что биоварские РПГ тебя тычут носом в весь имеющийся у них контент (но его тем не менее тоже можно пропускать в очень больших объемах), а фоллаут не тычет. В остальном подход не меняется. И конечно фоллауты очень хорошо поддерживают иллюзию вот этого открытого мира, где много может быть иначе. Но если поковыряться в деталях — неа, не может.

Это в новых XCOM-то сложно нащупать?

Попробуйте Long War. Ванильные новые XCOM конечно же не слишком сложны (но всё равно на порядки сложнее старых), даже на максимальной сложности.

Не "сложность победы", а "насколько сложно нащупать путь к победе". Это конечно любопытно, что вы второе прочитали как первое, но это совсем не одно и то же.


В игре, где вы побеждаете, если после 1000 подкидываний монетки выпадет 1000 орлов — победить невероятно сложно, а вот "нащупать путь к победе", скорее всего, довольно легко.

Да нет, вы просто смешиваете игры, где соль именно в детальности симуляции (Cataclysm: Dark days ahead как современный яркий пример), и игры, где соль в сложности победы (разными подходами, так XCOM традиционно "играет" на правильной оценке рисков и минимизации потерь).
Исторически, жанры компьютерных стратегий и тактик — всегда о противостоянии, а поэтому я не склонен считать детальность симуляции решаюшим фактором при оценке этого жанра. Решающее — это как раз таки насколько сложно (но при этом возможно) нащупать путь к победе.

Так вам симуляция нужна, или тактика?
Тактике необходим хороший баланс и сильный (или хотя бы превосходящий возможностями) ИИ. А в симуляции — да, достаточно чтоб можно было предпринять 100500 действий (и плевать, что 100498 из них не нужны для победы).


JA2 хорош (очень хорош, причем) как симулятор перестрелок в пошаге. Как тактика он весьма примитивен и прост, и даже попытки его резко усложнить (JA2 Wildfire) не закрыли всех балансовых дыр и просчетов.

Юнит-тесты реактовских компонент — невероятно бессмысленная вещь. Очень недалеко от Enterprise FizzBuzz.


Означает ли, что если юнит-тесты пройдут — наши компоненты будут правильно отображаться и работать? Нет, не означает. Да и принципиально не может, потому что всё, что мы проверили — это делают ли наши компоненты в замокированном DOM некоторые вещи, которые мы ожидаем. От этого и до "компонент правильно отображается и работает" — пропасть, со дна которой на тебя смотрят страшные штуки по имени CSS, browser compatibility, и всё вот это.


Означает ли, что если юнит-тесты не пройдут — наши компоненты не будут правильно отображаться и работать? И опять же нифига: на моей практике на каждую сотню случаев отвала юнит-тестов компонентов примерно штук 5 сообщали о реальных проблемах, а остальные 95 — это "я чего-то поменял в компоненте и теперь мне надо поправить тест, чтоб не падал".


Если у вас очень много свободного времени — тогда да, пишите юнит-тесты на компоненты. Если же нет — тестируйте бизнес-логику, а не появление каких-то там элементов в замокированном DOM.

X-COM: Apocalypse на 10 голов выше.

Это та, в которой в реалтайме можно пройти большинство миссий, просто бегая по карте? И где только отдельные моменты, типа захвата элиенов живьем, требуют некоторого (небольшого) включения головы?


У вас очень странные представления о хорошо сбалансированных тактиках.

Хорошая попытка, но нет. Вещи типа Ведьмака 3 (даже если мы полностью отбросим графон и экшн, как несущественные для этого обсуждения) по проработке ролевой части просто рядом не лежат со старыми фоллаутами, он в разы более объемен при сравнимом (но не в пользу фолов) уровне проработки. Даже если взять чуть более попсовые, но относительно "современные" вещи — биоваровские РПГ окажутся сравнимыми по ролевой части, но куда более проработанными в прочих аспектах (от баланса до графона).


Ну а игр лучше HoMM3 (в разрезе PvE, т.к. аналоги в части PvP особо не востребованы, а потому люди так и играют в HoMM) так и вообще буквально каждая первая (каждая первая из хороших, а не из любых стратегий/тактик вообще), так как упреки, приведенные в статье — полностью справедливы. В ванильном XCOM: EU баланса на порядки больше, чем в HoMM, не говоря уж там про какой-нибудь Long War.

Почему вы отличные игры прошлых времен сравниваете с "многими" современными, а не с лучшими современными?

Великолепные старые игры были, главным образом, великолепны на момент своего выхода и последующие сколько-то лет. Понятное дело, что на сегодняшний день те же Фоллауты ничем очень уж сильно не выделяются, а хороший баланс в HoMM3 буквально забежал на минуточку, и сразу вышел. Но во времена их выхода картина мира компьютерных игр была сильно другая.

Рыб надо брать, рыб — тоже работают за двоих и при этом молча! Идеальный исполнитель!

Уровень дохода вообще не обязан коррелировать с качеством кода. И исключая отдельные места в мире, являющиеся локальными сингулярностями "справедливой вселенной" — он и не коррелирует. Иногда спец, на котором держится вся контора — получает дофига. Иногда буквально "среднерыночно". Иногда посредственного кодера берут на небольшие деньги, а иногда он получает больше всех других программистов в конторе. Просто потому, что пришел в правильный момент, например.


Вы можете с этим бороться, а можете этим пользоваться, вот и вся разница.

"Победить" в моем понимании это влезть в приватное апи, чето там намутить, что изначально не предусматривалось.

Это "переписать", а уж никак не "победить". "Победить" — это дописать.
"Победить" — это взять кривоватый и неудобный инструмент, и таки найти путь применить его, спрятав весь неочевидный код в библиотечные классы и методы (как раз собственно то, о чем они пишут), и выставив наружу уже более интересное и удобное для применения API.

У них куча статей помимо тайги

Я про них и пишу.


где они делают разные классные штуки именно при помощи Ангуляра

Угу. Типа, "посмотрите, как мы классно победили ангулярский DI, чтоб им наконец-то было достаточно удобно пользоваться". Действительно, и почему же это я говорю, что без него было бы лучше?

Я так и не понял, то ли это "вредные советы", то ли еще что. Скажем первый совет про спред — весьма рабочий. При условии что проект на TS, и типы нормально описаны. А если на JS — то да, это уровень классического // happy debugging!

Я к тому, что и на ангуляре можно нормально делать приложения.

Тут главное вовремя понять, что без ангуляра могло бы быть всё гораздо лучше. Вот скажем на хабре уже довольно давно пишут ребята из Тинькофф, делающие Taiga UI. Пишут они замечательные вещи. Но каждый раз читая их, я не могу отделаться от мысли, что то, что они пишут — где-то наполовину или даже больше борьба с ангуляром (в которой они мужественно победили ангуляр).

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity