Pull to refresh
26
0
Иван @i_user

User

Send message
По личному опыту складывается ровно такое же ощущение:
Проектный менеджмент — это очевидные, общие и довольно прописные истины.
Проблема в том, что для каждого практического кейса — фраз, описывающих решение оной — несколько десятков. Рабочих из них около десятка, уместных 1-2. Поэтому хорошие статьи по проектному менеджменту очень часто смотрятся как исповедь капитана очевидность. Тем не менее таковыми не являются.
Воспринимайте статью как очевидное перечисление очевидных областей с тем чтобы вы проделали неочевидное для своего проекта — и прошлись по этим областям чтобы понять — закрыты ли они у вас осознанно или «сложились исторически и не очень выгодно».
А вы думаете, каждый человек должен стремиться к выдающемуся успеху? Или достаточно просто умения обеспечить достойную жизнь?
Сложность алгоритма — функция от объема входных данных (и еще некоторых параметров)
Сложность функции — эммм…?

Скорее задача должна звучать как — расположите данные функции по эммм… ну я даже не знаю, по скорости роста на больших N…

Слабенько, на самом деле для задач, которые должны что-то показать на собеседовании.
Для tricky задач — слишком прямолинейны, для вопросов на искусство программирования — не то.

Итого — подойдет чтобы отсеять слабых джуниоров и найти джуниоров посерьезнее. Для практикующих программистов, увы, не репрезентативно.
Совершенно не претендую на то, чтобы быть опытным enterprise архитектором, но, быть может дело в том, что Ваш вопрос не совсем простой? (Например, потому, что он у вас возник).

Вообще, про ваш вопрос хотелось бы узнать больше контекста — потому что пока чувствуется некоторый месс — микросервисы, воркфлоу,… В каком вы технологическом стеке вообще? Какова текущая архитектура системы?

Для вопроса в вакууме кажется — что ваш юзер-сервис уже немножко перерос один сервис и требует быть разделенным на сервис, предоставляющий наружу атомарные операции с пользователями (создать/изменить/etc...) — другой сервис отвечает за создание воркфлоу для пользователя, третий — хранит логику достаточную для принятия решения о том для каких изменений запускать воркфлоу, а для каких жить напрямую. — он и выставляется наружу.

«Нормальный архитектор со стажем решал эту проблему уже много раз» — Неа. Не решал ее нормальный архитектор. Другие задачи решал, а конкретно эту задачу не решал абстрактный нормальный архитектор. Ну вот не свезло ему.

P.S. Понимаю Вашу проблему в целом — отсутствие внешнего комьюнити. Хотя бы просто потому что архитектурные вопросы требуют серьезного погружения в тему каждый раз, когда возникают — а это — лень, да и времени жалко. Но тут как и везде — не хватает комьюнити — создай его :-)
Такое ощущение, что человек написавший это, при всем уважении, не совсем понимает что такое Optional type.
Это не про NPE, а про, черт возьми, настоящую строгую типизированность. Когда сущность какого-то типа обозначает именно сущность этого типа, а не «Стринг — это, конечно, Стринг, но иногда еще и null».

Я не знаю кейса, когда из-за этого не хватило какой-то гибкости языка.

P.S.
А теперь вопрос. Кто должен разруливать все эти риски? Язык? Или это работа программиста?


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

Помимо логики для вывода в компоненте есть еще и логика для фильтрации. Решение есть, и оно очень простое. Можно перенести код, который отвечает за фильтрацию в другое место и тестировать там.


1. Если нам понадобится применять ровно эту фильтрацию в другом месте… А если не понадобится?

2. Если мы протестировали код для фильтрации в другом месте — по-хорошему, при тестировании компонента мы должны протестировать, что он вызывает именно эту функцию фильтрации, а не какую-то другую. Так как это внутренняя и неявная зависимость модуля, фактически, для формальной чистоты — мы должны прогнать тесты, которые покроют эту зависимость.
Некоторые вещи концептуальны) Это как доказательство в математике :-D — его полезность измеряется не объемом, а тем, насколько полезные результаты дает применение результата и насколько долго не могли получить это доказательство. Redux — это концептуальная штука, как раз. Фреймворк, навязывающий некоторые стиль написания кода. Я не буду сейчас утверждать, что это ограничение спасет вас от всех проблем — но, anyway — не стоит недооценивать его значимость)
Вообще, есть в этом прекрасном рассуждении тонкий флёр исключительности, заключающийся в том, что постулируется, что работа программиста по дефолту сложнее работы по выстраиванию коммуникаций или качественному менеджменту.
Команда с Джун-менеджером и Сеньор-программистом навоюет ненамного больше, чем команда с Сеньор-менеджером и Джун-программистом.

Поэтому конечно джуны и мидлы справятся с этой необязательной и несложной задачей, а по-настоящему сложные задачу останутся разработчикам… Для сложных проектов умение держать в голове достаточный контекст проекта для формулирования требований и общения с компетентными(подчеркну это слово — потому что да, такие бывают далеко не в каждом проекте) представителями заказчика — требует не меньший уровень сеньорити, чем собственно написание кода.
Маркетинговый стартап размышляет (ну, если можно это так назвать) о промышленной разработке программных продуктов?
Erlang и SmallTalk в одном предложении тоже доставляют. Мне кажется, не хватает Assembler, Fortran и Brainfuck
Не очень понятно, что за мифы? В какой они среде гуляют? Я вот, например, об этих распространенных мифах даже не слышал.
Ну и да — 3 абзаца на две статьи — это за гранью.

В общем блин. Жаль, что
-мегамозг закрылся
-в карму можно ставить только один минус
О, вот прям с утра от знакомых еще один прилетел:

http://openradar.appspot.com/radar?id=4971716266688512
https://bugs.swift.org/browse/SR-1502 вот, например. Страшный.
ввиде багов с ооочень долгим компиляцией массива

Это далеко не самый страшный баг свифта) но вернуться на обж-си я уже не могу, глаза вытекают…
Аргументированная критика? Ну… Это хорошая тема — когда за 600 долларов вложений вы планируете найти 3 клиентов — уже взрослых продуктов. Я полагал это стоит дороже)
тестируется как и любой другой хороший фреймворк.

Я, как вероятно и автор статьи — из мира мобилок) тут гораздо меньше таких вот «хороших подходов» — и тестируемость по прежнему считается достижением :-) Но вообще да, пожалуй согласен. Просто реактивный подход для меня оказался первым где получилось построить что-то действительно красивое — поэтому я его переоцениваю — хотя тех же результатов можно добиться и иначе.

Благодарю за беседу)
Большой профит RX — он очень хорошо тестируется. Соответственно если при разработке приложения высокие требования к качеству — я буду смотреть в сторону RX.

Засчет биндинга — он очень хорошо покрывает задачи где данные собираются больше чем с одного источника (неважно — разные эндпоинты API, системные ресурсы, БДшечка) и претерпевают какие-то преобразования попути. То есть очень похоже на развитие идей LINQ.

Минус — Быстродействие — соответственно — если у меня много разных маленьких элементиков и требования к 60fps — выберу что-то более простое и прямое

RX очень требователен к уровню команды — соответственно с разномастной командой я бы в RX не ввязывался — его невозможно отлаживать — только тестировать.

То есть если я буду писать быстрый прототипчик чего-нибудь или игру, или буду работать в команде возможностей которой я не знаю — я, вероятно, выберу не RX
Если я буду писать алгоритмически сложную задачу требовательную к ресурсам и нуждающуюся в магии — я выберу не RX
Иначе — RX
… а выше вы же писали, что чтобы реактивщина была семантически точной, ее нужно правильно готовить, что не очень просто.

Могу раскрыть мысль — выработка хорошего подхода при работе с реактивным кодом требует существенных затрат в начале. И Вообще имеет высокий порог входа. Однако после преодоления этого порога оказалось, что в итоговом коде нет проблем, которые возникали при аспектном подходе (хотя я не исключаю, что просто неправильно его готовил)

На мой взгляд эти два подхода просто решают различные задачи, хотя оба лежат в области стиля организации кода и борьбы с проблемами асинхронности, как вы упомянули
Хорошо. Странно говорить «Лучше всех» в IT — где каждое решение — компромисс))
Разные классы сущностей. Потоки RX — не про потоки и асинхронность — а про контракт монадного биндинга в первую очередь — то есть про декларативное описание последовательности действий.
Акторы больше похожи на аспектный подход.
Их странно сравнивать) Но если очень хочется — то по моему опыту. аспекты гораздо гибче и дают больший эффект при меньших вложениях сил — однако больше тяготеют к потере контроля над качеством кодовой базы.
Так может быть, если есть более простые способы достигнуть семантической точности (я сейчас не буду обсуждать семантическую точность полученной реактивщины, ее надо почитать для этого на конкретных примерах), не надо усложнять?

Да — вы правы — тут уже надо брать куски кода и разговаривать по ним. С чем сравниваю? Ну, скажем, со «средним по больнице» iOS репозиториям на гитхабе, с кодом в статьях и так далее, да я полагаю — что реактивный подход действительно хорошо справляется с задачей честного описания стейта сущности (включая транзитный) даже на уровне сигнатур.
А вы уверены, что речь идет о «против сиюминутной выгоды», а не «против семантической точности», скажем?

Ну вообще практика показывает — что правильно приготовленная реактивщина очень и очень семантически точна, но вопрос очень уместный — потому что правильно ее приготовить не очень просто. Насчет избыточности? Возникало такое ощущение, да, но в итоге пришел к тому, что это приемлемая цена за тестируемый код, с гарантированно меньшим количеством сайд-эффектов и высоким уровнем инкапсуляции

К сожалению, презентация заточена под устный доклад — поэтому возможно чего-то будет не хватать — но с удовольствием объясню все недостающее при желании узнать. Ссылко
С точки зрения молотка все — гвозди. И да, так можно жить, но это не всегда удобно.

разумеется RX не панацея — но цель автора статья, да и моя — показать, что это достаточно взрослая парадигма для того, чтобы занимать ключевую позицию в реальных задачах.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity