Как стать автором
Обновить
22
0
Дмитрий Панюшкин @gnaeus

Пользователь

Отправить сообщение

Кстати, второе ваше замечание (по поводу произовдительности) можно применить и к extension-методам. Например:


static T GetElementAt<T>(this IReader<T> reader, int index) => 
  reader.GetItems().ElementAt(index);

Но реализации по-умолчанию в интерфейсах хотя бы позволяют переопределить такое поведение в непосредственном классе-реализации.

Ну или более пессимистичный вариант. Потомки и не будут знать, потому что их не будет.

К примеру право отказаться от работы с пользователем если потенциальный ущерб от него превышает потенциальную прибыль

Вот только крупные корпорации и так оказывают сейчас на пользователей слишком большое влияние. Да, доступ к интернет-сервисам не жизненно необходим. И когда в прошлом веке принимались "права человека", его не было. Но его не было ни у кого. А вы предлагаете дать волю компании лишать этого доступа конкретных людей.


Как вам например такое:


Вы в прошлый раз отсудили у страховой по ОСАГО крупную сумму => ущерб от вас превысил потенциальную прибыль => вы оказались в "черном списке" страховых (олигополия же) => не можете водить машину (уже по закону).


Или то же самое с банками: не можете пользоваться картами, кредитами, вкладами, инвестициями.

Мне кажется, автор не топит за говнокод, а говорит достаточно разумные вещи.


  • Технологии, требующие глубокого изучения или знания математики, повышают порог входа.

Если у нас собралась команда рок-звезд, мы можем применять все это. Но не каждому это дано. Не все столь фанатичны. И для среднестатистического проекта лучше писать так, чтобы это понял среднестатистический разработчик. И да, если пишем с "индусами", чтобы понял даже "индус".


  • Бездумное следование принципу DRY может увести не туда.

Как он выглядит упрощенно: увидели повторяющийся код — выделили в функцию / метод / базовый класс. Но это неверно! Сначала мы должны ответить на вопрос: а должен ли этот код повторяться и при внесении изменений? Или в последствии мы можем изменить один вариант копипасты, а другой оставить нетронутым? Т.е. отвечает ли выделенная функция принципу SRP.


Поэтому иногда копипаста и бойлерплейт бывают полезны.

А вам не кажется, что этот connect слегка нечестный?


<Observer>
  {() => <WrappedComponent {...mapState(store)} {...props} />}
</Observer>

Тут <Observer> подпишется только на изменения shallow props из {...mapState(store)}. Вот пруф.


И получается, у нас во-первых внутри <WrappedComponent> будут по-прежнему использоваться MobX-объекты вместо Plain. А во-вторых, он не будет реагировать на изменения deep props в переданном ему объекте, даже если они затронуты рендерингом.


Чтобы этого избежать, нужно в mapStateToProps() вызывать mobx.toJS(). А это уже убъет саму идею: подписка пойдет на все свойства, вместо затронутых. И объекты будут пересоздаваться каждый раз с помощью deep copy, а не shallow как в Redux.


Так что на самом деле mobx-state-tree asReduxStore() единственный вариант для такого кейса.

Присоединяюсь к MaZaAa. MobX вообще пофиг на вложенность. Можно использовать даже не дерево, а циклическую структуру данных.


Все подписки точечные (только на те поля, которые были затронуты). Все изменения данных тоже точечные. В отличие от Redux, при изменении вложенного поля, здесь не копируются объекты по пути к этому полю. Поэтому и компоненты, подписанные на вышестоящие объекты, не перерендерятся.

перепишет алгоритм на другой, а ссылка или описание останется прежним

А код-ревью тогда зачем?


Зачем человеку знать какие-то детали реализации при вызове метода?

Ну так я об этом и говорю, что не надо. Только вот потом кто-то захочет узнать например memory cost и time complexity вашего алгоритма. И как он это должен понять? Вдумчивым чтением исходников? (я сейчас не про библиотечные сортировки).


Вообще бред какой-то получается: в этом треде нет ни одного совета комментить все в стиле "капитана". Зато регулярно слышны призывы "все комменты зло".

А если вместо этой простыни будет только ссылка на описание алгоритма?


Ну ведь бывает, что реализуешь что-нибудь эдакое с графами. Вот назову я метод GetStronglyConnectedComponents. Вы сходу определите, что там внутри алгоритм Тарьяна а не Косарайю? А если добавить фамилию в название метода — это уже implementation details, не важные для вызывающего кода.

Я для себя вывел простую эвристику: если после рефакторинга код все равно кажется сложным или странным — надо написать пару строк в шапке файла.


Так-то за несколько циклов вдумчивого ревью и рефакторинга можно добиться и самодокументированности. Но есть ли на это время? И хватит ли квалификации?

На самом деле, мое мнение тоже где-то "посередине". Но когда в сообществе наблюдается явный перекос, все равно приходится принимать противоположную сторону.

А это не максимализм. Это просто слишком привлекательная концепция для разработчиков. Примерно как "обсуждать чужую зарплату неприлично" привлекательна для работодателей.


"Зачем я буду пояснять, что имел в виду? Мой код и так божественный. А всех, кто не согласен, отправлю читать Мартина" =)

Я вот, признаться, тоже удивлен количеством противников документации. С одной стороны никто писать ее не любит (сам такой). С другой стороны, давайте для примера рассмотрим гитхаб — да на репу без Readme или Wiki никто и не посмотрит. Получается какое-то ханжество: читать чужие доки мы любим, а поддерживать свои — нет.


Документирование как минимум уместно в публичном API. А комментарии к коду — при вызове внешних API. Для внутреннего кода как правило достаточно высокоуровневого описания архитектуры. Например, в виде диаграмм.


Вспомните какой-нибудь качественный open-source проект. Скорее всего, в нем будут и доки и диаграммы. А потом откройте исходники — скорее всего вы увидите комментарии к фиксам и воркэраундам вокруг сторонних API. Поскольку полезные проекты существуют не в вакууме.


P. S. Разумеется, это все не относится к одноразовым проектам, прототипам или тем, где описанием может служить сам интерфейс. Сначала код, потом доки. Если останется время.

Если есть живой человек, который может ввести в курс дела, то все это необязательно.


А вот когда ключевые разработчики уже уволились (по тем или иным причинам) — документация бесценна.

А разве именно это нельзя назвать "демотивирует"? :)


Да, небольшая зарплата может и не побуждает сменить работу. И не уменьшает общий жизненный тонус (наверное это вы имели в виду под "не демотивирует").


Но на проект-то мы тратим меньше эффективного времени. И работаем спустя рукава. И таски выполняются дольше и менее качественно. Если это устраивает и работника и работодателя — ну Ок.

Можете пояснить, какие затраты имеете в виду? Модель данных в MobX – это мутабельный объектный граф. Он уже денормализован "из коробки".

Тут может быть еще интересный момент. Российские работодатели часто забывают о такой штуке, как индексация. А в условиях высокой инфляции за несколько лет это может привести к "Чего я тут горбачусь за N денег, если там могу получить 2N за то же самое?". И это при том, что в целом N денег человеку хватает.

можно отследить в reduxDevTools историю изменений stor'а

Мой коллега сказал, что на одном из проектов ему это очень помогло понять, что вообще происходит. Только вот это аргумент не в пользу Redux =) Потому что чтением исходников это понять было на порядок сложнее.

Ну вот это как раз и является неявным поведением.


Почему бы сразу не завести отдельный action:


@action setFilterParams(filterParams) {
  this.page = 1;
  this.filterParams = filterParams;
}

А неактуальные запросы можно вообще отменять с помощью AbortController.

Я говорю даже не о циклах в обработке реакций. Это уже за гранью добра и зла.
Даже если программа написана корректно: изменение одного observable порождает одну реакцию, которая изменяет другой observable, который запускает другую реакцию, которая...


Это нарушает саму парадигму реактивности. Это нарушает линейность кода. Это получается какой-то уже event-driven подход. То, от чего мы все стараемся уйти.

Информация

В рейтинге
Не участвует
Откуда
Калуга, Калужская обл., Россия
Дата рождения
Зарегистрирован
Активность