Ранее мы обсудили, что компонентный подход — это способ организации приложения в виде иерархии компонентов: UI-элементы ➜ функциональные блоки ➜ экраны ➜ флоу ➜ приложение.
Я говорил выше именно про блок вью. И про вот это взаимодействие: UI-элементы ➜ Составной UI-элемент. Остальные блоки (функциональные блоки, экраны, флоу, приложение) я не имел ввиду.
Теперь, что касается сравнения "Компоновщика" и "обычного" агрегирования (указал ссылки, откуда беру терминологию). Вы правы, что оба этих подхода спрячут детали реализации от внешнего мира. Однако, агрегирование подразумевает, что компонент (в терминах статьи, тут я уже и про UI-элементы, и фукнциональные блоки, и экраны, и флоу говорю) будет создан снаружи (соответственно, "Строителем"). И вот тут ключевое отличие.
Как думаете, должна ли вьюшка собирать себя сама или это должен делать кто-то снаружи? Имхо, гораздо проще получится, если она соберет себя сама. И я считаю, что во всех архитектурах, где есть вью (а есть ли архитектуры без вью?), этот паттерн на уровне вью должен присутствовать. Тем более, что Элл его рекомендует в своей документации. У нас у иосников принято свято доверять своему Богу :) Этот шаблон упростит реализацию вью. Компоновщик все же проще. Ну, просто потому, что не требует третьего класса, который собирает компонент в агрегации (Это шаблон "Строитель", насколько я понимаю). Но так глубоко я не рассматривал ни разу. Давайте вместе попробуем обсудить и разложить этот момент по полочкам. Мне будет полезно увидеть, где я ошибаюсь.
Теперь про уровни выше. Контроллеры/презентеры и вот это в терминах статьи: функциональные блоки ➜ экраны ➜ флоу ➜ приложение. Оказывается, мое утверждение справедливо и для них. Смотрите сами. По указанной выше ссылке на MVC вы можете заметить, что контроллер содержит шаблон "Стратегия", который вроде хорошо сочетается с созданием чего-то снаружи. Вроде как именно контроллер и может тогда реализовывать агрегирование (причем, больше подходит реализация композиции, обратите внимание на этот нюанс). Однако, обратите внимание, что сам шаблон "Стратегия" не подразумевает инжектирование и подмену алгоритмов внутри себя. Он этого не ограничивает. Т.е. потенциально и для контроллеров/презентеров (а значит, и для функциональные блоки ➜ экраны ➜ флоу ➜ приложение) тоже можно использовать шаблон "Компоновщик", а не композицию. Опять же из двух вариантов лучше всегда предпочитать тот, что проще. Как я уже и сказал, выше проще и понятнее по моему скромному мнению именно "Компоновщик".
Поэтому-то я и написал "обязан удовлетворять шаблону "Компоновщик". Но соглашусь, формулировку стоит поменять на "рекомендую, чтобы компонент удовлетворял шаблону "Компоновщик".
А о каком архитектурном паттерне идет речь? Архитектурные паттерны – это всегда? компоновка более мелких паттернов проектирования. Раньше я думал, что вью во всех (100%) архитектур всегда должен удовлетворять шаблону "Компоновщик". MVP, например, – это MVC с пассивной моделью. Так вот в ней черным по-английски написано, что view – это "компоновщик". Пруф. Смотрите сразу картинку 7.2. Если вы не используете компоновщик, то это уже у вас и не MVP, и не MVC с пассивной моделью. Значит, это что-то ваше собственное или что-то о чем я еще не знаю. Так о каком архитектурном паттерне речь? И из каких паттернов тогда состоит вью в нем? Мне правда интересно, т.к. сейчас собираю информацию об этом для доклада.
Только учитывайте, что одно общее состояние у Вас все равно складывается, как композиция конкретных состояний дочерних элементов. Число этих состояний равно произведению чисел состояний каждого конкретного дочернего элемента. 3 дочерних компонента по 3 состояния в каждом дают конечный автомат из 27 состояний. Теория комбинаторики же. Попытка все 27 впихнуть в 1 конечный автомат сделает Вам только больнее. А вот конечный автомат, который объединяет состояния трех вложенных компонентов будет иметь гораздо меньше состояний. Шаблон "Компоновщик" тоже очень помогает понять, как правильно работать с вложенными компонентами.
Можно еще отметить, что компонент обязан удовлетворять шаблону проектирования "Composite" ("Компоновщик"). Этот шаблон накладывает определенные ограничение на то, кто и как собирает компонент целиком. Спойлер - сам компонент себя собирает. Также этот шаблон накладывает ограничения на то, как внутренности компонента видны снаружи компонента, на то, каким вообще должен быть интерфейс компонента, и на то, как взаимодействуют вложенные и родительский компоненты друг с другом. Это тоже немаловажный момент при проектировании компонентов. Спойлера тут не будет. Предлагаю всем заинтересованным самим изучить шаблон и сообразить, как его применять на практике для проектирования компонентов.
Еще для взаимодействия дочерних и родительских компонентов крайне рекомендуется использовать шаблон проектирования "Команда". Он идеально сочетается с шаблоном "Компоновщик". И совсем высший пилотаж – это добавить в архитектуру компонента шаблон "Chain of response" или "Responder chain" (как его называет Apple), который еще прекраснее ложится на предыдущие 2 шаблона и, наверняка, должен быть реализован в Android из коробки (я iOS-разработчик, поэтому пока лишь делаю такое предположение). Эти 2 шаблона помогут вам сделать вашу схему гораздо менее связной и более переиспользуемой. Это про callback'и общения дочерних компонентов с родительскими и выше до контроллера (или презентера, или вьюмодели). Callback на самом деле в вашей схеме все очень сильно портит.
Все Ваши ссылки содержат понятие "рабочего места", а не "удаленной работы". Я это читаю так: по закону у вас должно быть рабочее место в иностранном государстве. Стул, стол, компьютер в офисе за рубежом, офис, видимо, зарегистрирован и оформлен по нормам местного законодательства. Понятно, что очень немногие российские компании могут этим похвастаться. Так что все же 30%, а не 0% :)
Сразу скажу, что я не юрист, чтобы не было завышенных ожиданий от дискуссии.
Можете это прокомментировать с профессиональной точки зрения?
Вот только бризер стоит у вас в комнате и создает шум. Объективно. Не создает шум он только в одном случае, если не работает. А централизованная приточка далеко от вас и шума не создает. Даже когда работает.
Второе, а какая разница что греть, если обогрев везде на газу? Ну, допустим, вы загоняете в дом воздух температурой 12-16 градусов, а потом он все равно греется водяным отоплением на газу внутри помещения. Почему его сразу не нагреть приточкой до 24х, например, тем же водяным отоплением на газу? Кажется, что КПД обоих случаев будет равным с погрешностью, которой вполне можно пренебречь. Нет?
Да, ваш совет работает в квартирах, где отопление -- центральное, а подогрев приточки -- электрический. В частном доме и то, и другое будут водяным на газу. Какая разница для частного дома?
Простите, все равно не прослеживаю связи. Как это бы сподвигло ее выжимать своего способного подчиненного? Пока это все равно выглядит, как неправильное понимание своей роли и восприятия конкуренции, и как следствие неправильное выполнение своих обязанностей и прямой саботаж работы собственного отдела. Все равно обсуждаемые советы - вредны.
Вот вы вскользь упомянули, что Ваша начальница Вас уволила. Это ведь тоже плохое поведение. Нельзя не только подсиживать, но и выживать способных из команды. А это по моему опыту в российском айти прям сплошь и рядом.
И советы по борьбе с подсиживанием тоже мне показались вредными. Любой руководитель должен стремиться делегировать максимум своих обязанностей подчиненным, чтобы максимум освободившегося времени тратить на самую важную свою задачу, которую делегировать подчиненным нельзя – стратегическое планирование. Задача не из простых, и чем меньше времени на нее тратится, тем хуже будут результаты команды и руководителя.
А если вы не делитесь специфической информацией с подчиненными, то не можете делегировать максимум своей работы. А значит, не сможете достойно осуществлять стратегию развития.
Аналогично, если вы не заменим и пытаетесь этот статус сохранить, то вы не можете ходить в отпуска. Вы постоянно под стрессом и "на стреме". Вы постоянно ждете, что вам упадет работа, которую никому кроме вас доверить нельзя, а выполнить ее нужно в конкретные, не всегда удобные, сроки.
И в противовес. Если вы подготовили себе хорошую смену, если вашу работу могут выполнять другие, то ваш начальник легко сможет Вас порекомендовать на рост. Он не будет бояться, что с вашим диагональным ростом или горизонтальным переходом работа вашего отдела (и его в том числе встанет). Вы не переживаете по поводу работы, которую не сделает никто, кроме вас. У вас меньше стресса, потому что есть 2-3 человека, которые легко выполнят любую работу за Вас.
При этом Вы защищены от подсиживания, потому что хороший руководитель (а Ваш руководитель определенно хороший, просто потому, что он Ваш руководитель, а не Вы его :) понимает, что главная задача руководителя – это стратегия развития. И если Вы ее выполняете на отлично, то никто вас и заменить не сможет. Ни одному Вашему подчиненному не хватит угла и высоты обзора, чтобы заниматься стратегией так же успешно, как Вам. Просто в силу того, что он занимает позицию ниже и сосредоточен на деталях. Вы же об этом постарались выше? Вы же погрузили его во все тонкости и нюансы Вашей работы :)
В итоге, ничего утаивать не нужно. Сотрудник Ваш сам никогда не увидит картину стратегически. А значит, не сможет превзойти или просто заменить Вас в этом компоненте никогда. А всем остальным нужно с сотрудниками делиться в обязательном порядке. Вашему подсиживанию это не угрожает.
Это очень хорошо прослеживается в компаниях с пирамидальными структурами управления. В засилье плоских организаций это, конечно, не видно, но оно работает точно так же.
Что думаете?
За пост – спасибо. Все по делу, кроме первого пункта.
Иногда разница хорошо раскрывается и самим названием.
Callback - обратный вызов (еще его называют замыканиями). Ожидается, что колбеки вызываются в конце асинхронной функции для возврата управления вызывающему коду. В любых других случаях их использование мне кажется моветоном.
Делегат - поведенческий паттерн, который применяется очень широко и за пределами программирования. И означает он передачу своей работы и ответственности другому лицу (в программировании – объекту).
Как видите, тут принципиальное отличие от колбека. Во-первых, делегаты можно вызывать несколько раз за время работы одного метода. Во-вторых, делегаты не просто возвращают управление, а они как бы перекладывают часть работы метода на кого-то еще. И уже кто-то другой обязан выполнить какой-то кусок работы для нашего метода. Колбеки не обязаны выполнять работу для других объектов или методов.
Типичный пример – делегат нажатия на ячейку. По идее табличка сама должна отработать нажатие, но она не знает как. Поэтому часть работы по распознаванию нажатия она выполняет сама, а вот дальнейшую работу по открытию другого экрана, например, уже делегирует тому, кто знает что и как делать.
В противовес колбек. Типичный пример - анимации переходов – асинхронная функция, по выполнению которой мы бы хотели получить управление обратно и выполнить еще какие-то действия.
И перемешивать области применения инструментов - тоже огромнейший моветон. Это очень сильно снижает восприятие кода.
Тем более, если калорифер еще и прогревают заранее, то датчик температуры сразу должен показать. Рост этой самой температуры, если его нет, то пускать вентилятор не стоит. В общем, непонятно, Вы сами же отрицаете существование проблемы, которую пытаетесь решить в статье.
Я не профи, но... "Холодный пуск" не поможет понять, что теплоноситель не теплоноситель? вы включаете приток не на полную, а на 10% мощности. тут же система видит на входе очень холодный воздух, автоматика предпринимает все, чтобы воздух подогреть: открывает теплоноситель на максимум. Но увы, эффекта нет, воздух все холоднее и холоднее. Автоматика понимает, что надо выключать приток. Теплоноситель не успел замерзнуть, хоть и немного охладился. Не так работают современные автоматики, оснащенные функцией холодного старта?
А еще вы забыли упомянуть про безопасность. Украденную цифровую денежку легко отследить и вернуть владельцу. И наказать мошенника. Особенно, если регистрироваться цифровые кошельки будут строго по паспорту (для физ.лица) или по ИГРН (для юр.лиц).
Именно для этого и поделили ^.^ Мы лишь показали, что для того, чтобы обрабатывать эту ситуацию, разумно выделить отдельный класс со своей ответственностью. Подменяя реализацию этого класса, вы можете работать с данными разной структуры. Ничего другого в схеме менять не придется в соответствие с принципами SOLID.
Мы решаем проблему дублирования кода из экрана в экран. Как обычно разработчики пишут табличные экраны? Каждый раз заводят контроллер, в котором реализуют источник данных и делегат таблицы, даже если в этих ответственностях совсем малые отличия. Как в вашем случае. Всего лишь меняется структура входных данных, но при этом разработчики сделают 2 совершенно разных контроллера, отличающихся парой строчек. Так? Наверняка так.
Далее, скорее всего разработчик попробует сделать какую-то универсальную связку датасорса и делегата, работающие во всех возможных случаях. Конечно, все случаи учесть все равно не получится и его решение будет работать далеко не всегда, а в неподходящих случаях придется городить огород, чтобы его решение можно было натянуть на глобус, или на сову ^.^ Таких решений на Хабре много. Вот из последнего. В итоге получается очень сложно и непонятно. Хотели упростить и сократить дублирование, а сделали непонятного франкенштейна.
Разбив же ответственности так, как мы предлагаем, вы сможете переиспользовать в обоих контроллерах все кроме провайдера данных. У вас будет всего лишь 2 разных провайдера данных, которые вы инжектируете в полностью идентичные контроллеры, источник данных и делегат. В итоге вы не напишите ни одной строчки дважды. У вас будет написан только различный код по работе с входными данными. Собственно, в этой статье это и показно.
Именно это и позволяет нам переиспользовать код из табличного экрана в табличный и создавать их практически за часы. При этом у нас нет сотен однотипных контроллеров, генерируемых кодогенераторами, как например, это делается в VIPER'е. И нет сложных монструозных решений, не работающих в частных случаях. Порог входа проверен небольшим числом новых разработчиков. Им понравилось.
"Пример NSURLCache в очередной раз показывает нам, насколько важно знать возможности системы, с которой работаешь.
Многие разработчики изобретают свой велосипед для организации кеширования, так как не знают о возможностях NSURLCache, инициализация которого занимает всего 2 строчки кода и делает работу в 100 раз эффективнее. Еще большее число вообще не задумывается о преимуществах сетевого кеширования и не использует его, нагружая свой сервер огромным количеством ненужных запросов."
Рекомендую к описанной практике добавить еще и максимальную декомпозицию задач.
80% задач в разработке программного обеспечения делятся на совершенно однотипные задачи типа: реализовать представление (вью), добавить валидаторы вводимых данных, реализовать пару-тройку запросов, реализовать преобразование данных из формата, вводимого пользователем в формат понимаемый сервером и обратно, реализовать бизнес логику и т.д.
80% этого дробления легко уложится в вашу практику. При этом все эти задачи будут атомарными и выполняться за полдня-день. Если задачи занимают больше времени, то их просто надо раздробить еще. До тех пор, пока они не станут размером в полдня-день.
После этого Вашу практику можно смело применять и в Scrum. В таком случае у вас будет в спринте не 1 задача, которая еще может и не влезть. А набор мелких задач, которые легко оцениваются на основании статистики и истории. И по этому набору мы можем уже гораздо более точно сказать, а влезет ли задача в спринт целиком, или какой-то ее кусок все же придется перетащить в следующий спринт.
Кажется, что размер стека – это параметр, который вполне может быть рассчитан на этапе компиляции (если Вы не используете рекурсию). Поэтому проблем с переполнением стека в вашей программе быть не должно (компилятор подсчитает и установит необходимый вам размер стека) и сам этот пункт можно исключить из списка недостатков структур.
Можно ли СПМ-пакет сформировать одновременно и с бинарником, и с исходниками? И на лету менять с кем линковаться? Бинарник – для быстрого запуска. Исходники – для тех, кто хочет разобраться во внутрянке или подебажить?
Да, я понял, где разница. Спасибо. Вот цитата:
Я говорил выше именно про блок вью. И про вот это взаимодействие: UI-элементы ➜ Составной UI-элемент. Остальные блоки (функциональные блоки, экраны, флоу, приложение) я не имел ввиду.
Теперь, что касается сравнения "Компоновщика" и "обычного" агрегирования (указал ссылки, откуда беру терминологию). Вы правы, что оба этих подхода спрячут детали реализации от внешнего мира. Однако, агрегирование подразумевает, что компонент (в терминах статьи, тут я уже и про UI-элементы, и фукнциональные блоки, и экраны, и флоу говорю) будет создан снаружи (соответственно, "Строителем"). И вот тут ключевое отличие.
Как думаете, должна ли вьюшка собирать себя сама или это должен делать кто-то снаружи? Имхо, гораздо проще получится, если она соберет себя сама. И я считаю, что во всех архитектурах, где есть вью (а есть ли архитектуры без вью?), этот паттерн на уровне вью должен присутствовать. Тем более, что Элл его рекомендует в своей документации. У нас у иосников принято свято доверять своему Богу :) Этот шаблон упростит реализацию вью. Компоновщик все же проще. Ну, просто потому, что не требует третьего класса, который собирает компонент в агрегации (Это шаблон "Строитель", насколько я понимаю). Но так глубоко я не рассматривал ни разу. Давайте вместе попробуем обсудить и разложить этот момент по полочкам. Мне будет полезно увидеть, где я ошибаюсь.
Теперь про уровни выше. Контроллеры/презентеры и вот это в терминах статьи: функциональные блоки ➜ экраны ➜ флоу ➜ приложение. Оказывается, мое утверждение справедливо и для них. Смотрите сами. По указанной выше ссылке на MVC вы можете заметить, что контроллер содержит шаблон "Стратегия", который вроде хорошо сочетается с созданием чего-то снаружи. Вроде как именно контроллер и может тогда реализовывать агрегирование (причем, больше подходит реализация композиции, обратите внимание на этот нюанс). Однако, обратите внимание, что сам шаблон "Стратегия" не подразумевает инжектирование и подмену алгоритмов внутри себя. Он этого не ограничивает. Т.е. потенциально и для контроллеров/презентеров (а значит, и для функциональные блоки ➜ экраны ➜ флоу ➜ приложение) тоже можно использовать шаблон "Компоновщик", а не композицию. Опять же из двух вариантов лучше всегда предпочитать тот, что проще. Как я уже и сказал, выше проще и понятнее по моему скромному мнению именно "Компоновщик".
Поэтому-то я и написал "обязан удовлетворять шаблону "Компоновщик". Но соглашусь, формулировку стоит поменять на "рекомендую, чтобы компонент удовлетворял шаблону "Компоновщик".
А о каком архитектурном паттерне идет речь? Архитектурные паттерны – это всегда? компоновка более мелких паттернов проектирования. Раньше я думал, что вью во всех (100%) архитектур всегда должен удовлетворять шаблону "Компоновщик". MVP, например, – это MVC с пассивной моделью. Так вот в ней черным по-английски написано, что view – это "компоновщик". Пруф. Смотрите сразу картинку 7.2. Если вы не используете компоновщик, то это уже у вас и не MVP, и не MVC с пассивной моделью. Значит, это что-то ваше собственное или что-то о чем я еще не знаю. Так о каком архитектурном паттерне речь? И из каких паттернов тогда состоит вью в нем? Мне правда интересно, т.к. сейчас собираю информацию об этом для доклада.
Только учитывайте, что одно общее состояние у Вас все равно складывается, как композиция конкретных состояний дочерних элементов. Число этих состояний равно произведению чисел состояний каждого конкретного дочернего элемента. 3 дочерних компонента по 3 состояния в каждом дают конечный автомат из 27 состояний. Теория комбинаторики же. Попытка все 27 впихнуть в 1 конечный автомат сделает Вам только больнее. А вот конечный автомат, который объединяет состояния трех вложенных компонентов будет иметь гораздо меньше состояний. Шаблон "Компоновщик" тоже очень помогает понять, как правильно работать с вложенными компонентами.
Можно еще отметить, что компонент обязан удовлетворять шаблону проектирования "Composite" ("Компоновщик"). Этот шаблон накладывает определенные ограничение на то, кто и как собирает компонент целиком. Спойлер - сам компонент себя собирает. Также этот шаблон накладывает ограничения на то, как внутренности компонента видны снаружи компонента, на то, каким вообще должен быть интерфейс компонента, и на то, как взаимодействуют вложенные и родительский компоненты друг с другом. Это тоже немаловажный момент при проектировании компонентов. Спойлера тут не будет. Предлагаю всем заинтересованным самим изучить шаблон и сообразить, как его применять на практике для проектирования компонентов.
Еще для взаимодействия дочерних и родительских компонентов крайне рекомендуется использовать шаблон проектирования "Команда". Он идеально сочетается с шаблоном "Компоновщик". И совсем высший пилотаж – это добавить в архитектуру компонента шаблон "Chain of response" или "Responder chain" (как его называет Apple), который еще прекраснее ложится на предыдущие 2 шаблона и, наверняка, должен быть реализован в Android из коробки (я iOS-разработчик, поэтому пока лишь делаю такое предположение). Эти 2 шаблона помогут вам сделать вашу схему гораздо менее связной и более переиспользуемой. Это про callback'и общения дочерних компонентов с родительскими и выше до контроллера (или презентера, или вьюмодели). Callback на самом деле в вашей схеме все очень сильно портит.
Но ведь давно уже придуманы size classes, разве нет? https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/Size-ClassSpecificLayout.html
Погодите, погодите.
Все Ваши ссылки содержат понятие "рабочего места", а не "удаленной работы". Я это читаю так: по закону у вас должно быть рабочее место в иностранном государстве. Стул, стол, компьютер в офисе за рубежом, офис, видимо, зарегистрирован и оформлен по нормам местного законодательства. Понятно, что очень немногие российские компании могут этим похвастаться. Так что все же 30%, а не 0% :)
Сразу скажу, что я не юрист, чтобы не было завышенных ожиданий от дискуссии.
Можете это прокомментировать с профессиональной точки зрения?
Вот только бризер стоит у вас в комнате и создает шум. Объективно. Не создает шум он только в одном случае, если не работает. А централизованная приточка далеко от вас и шума не создает. Даже когда работает.
Второе, а какая разница что греть, если обогрев везде на газу? Ну, допустим, вы загоняете в дом воздух температурой 12-16 градусов, а потом он все равно греется водяным отоплением на газу внутри помещения. Почему его сразу не нагреть приточкой до 24х, например, тем же водяным отоплением на газу? Кажется, что КПД обоих случаев будет равным с погрешностью, которой вполне можно пренебречь. Нет?
Да, ваш совет работает в квартирах, где отопление -- центральное, а подогрев приточки -- электрический. В частном доме и то, и другое будут водяным на газу. Какая разница для частного дома?
Простите, все равно не прослеживаю связи. Как это бы сподвигло ее выжимать своего способного подчиненного? Пока это все равно выглядит, как неправильное понимание своей роли и восприятия конкуренции, и как следствие неправильное выполнение своих обязанностей и прямой саботаж работы собственного отдела. Все равно обсуждаемые советы - вредны.
Интересно, про "подсиживание".
Вот вы вскользь упомянули, что Ваша начальница Вас уволила. Это ведь тоже плохое поведение. Нельзя не только подсиживать, но и выживать способных из команды. А это по моему опыту в российском айти прям сплошь и рядом.
И советы по борьбе с подсиживанием тоже мне показались вредными. Любой руководитель должен стремиться делегировать максимум своих обязанностей подчиненным, чтобы максимум освободившегося времени тратить на самую важную свою задачу, которую делегировать подчиненным нельзя – стратегическое планирование. Задача не из простых, и чем меньше времени на нее тратится, тем хуже будут результаты команды и руководителя.
А если вы не делитесь специфической информацией с подчиненными, то не можете делегировать максимум своей работы. А значит, не сможете достойно осуществлять стратегию развития.
Аналогично, если вы не заменим и пытаетесь этот статус сохранить, то вы не можете ходить в отпуска. Вы постоянно под стрессом и "на стреме". Вы постоянно ждете, что вам упадет работа, которую никому кроме вас доверить нельзя, а выполнить ее нужно в конкретные, не всегда удобные, сроки.
И в противовес. Если вы подготовили себе хорошую смену, если вашу работу могут выполнять другие, то ваш начальник легко сможет Вас порекомендовать на рост. Он не будет бояться, что с вашим диагональным ростом или горизонтальным переходом работа вашего отдела (и его в том числе встанет). Вы не переживаете по поводу работы, которую не сделает никто, кроме вас. У вас меньше стресса, потому что есть 2-3 человека, которые легко выполнят любую работу за Вас.
При этом Вы защищены от подсиживания, потому что хороший руководитель (а Ваш руководитель определенно хороший, просто потому, что он Ваш руководитель, а не Вы его :) понимает, что главная задача руководителя – это стратегия развития. И если Вы ее выполняете на отлично, то никто вас и заменить не сможет. Ни одному Вашему подчиненному не хватит угла и высоты обзора, чтобы заниматься стратегией так же успешно, как Вам. Просто в силу того, что он занимает позицию ниже и сосредоточен на деталях. Вы же об этом постарались выше? Вы же погрузили его во все тонкости и нюансы Вашей работы :)
В итоге, ничего утаивать не нужно. Сотрудник Ваш сам никогда не увидит картину стратегически. А значит, не сможет превзойти или просто заменить Вас в этом компоненте никогда. А всем остальным нужно с сотрудниками делиться в обязательном порядке. Вашему подсиживанию это не угрожает.
Это очень хорошо прослеживается в компаниях с пирамидальными структурами управления. В засилье плоских организаций это, конечно, не видно, но оно работает точно так же.
Что думаете?
За пост – спасибо. Все по делу, кроме первого пункта.
Иногда разница хорошо раскрывается и самим названием.
Callback - обратный вызов (еще его называют замыканиями). Ожидается, что колбеки вызываются в конце асинхронной функции для возврата управления вызывающему коду. В любых других случаях их использование мне кажется моветоном.
Делегат - поведенческий паттерн, который применяется очень широко и за пределами программирования. И означает он передачу своей работы и ответственности другому лицу (в программировании – объекту).
Как видите, тут принципиальное отличие от колбека. Во-первых, делегаты можно вызывать несколько раз за время работы одного метода. Во-вторых, делегаты не просто возвращают управление, а они как бы перекладывают часть работы метода на кого-то еще. И уже кто-то другой обязан выполнить какой-то кусок работы для нашего метода. Колбеки не обязаны выполнять работу для других объектов или методов.
Типичный пример – делегат нажатия на ячейку. По идее табличка сама должна отработать нажатие, но она не знает как. Поэтому часть работы по распознаванию нажатия она выполняет сама, а вот дальнейшую работу по открытию другого экрана, например, уже делегирует тому, кто знает что и как делать.
В противовес колбек. Типичный пример - анимации переходов – асинхронная функция, по выполнению которой мы бы хотели получить управление обратно и выполнить еще какие-то действия.
И перемешивать области применения инструментов - тоже огромнейший моветон. Это очень сильно снижает восприятие кода.
Тем более, если калорифер еще и прогревают заранее, то датчик температуры сразу должен показать. Рост этой самой температуры, если его нет, то пускать вентилятор не стоит. В общем, непонятно, Вы сами же отрицаете существование проблемы, которую пытаетесь решить в статье.
Я не профи, но...
"Холодный пуск" не поможет понять, что теплоноситель не теплоноситель? вы включаете приток не на полную, а на 10% мощности. тут же система видит на входе очень холодный воздух, автоматика предпринимает все, чтобы воздух подогреть: открывает теплоноситель на максимум. Но увы, эффекта нет, воздух все холоднее и холоднее. Автоматика понимает, что надо выключать приток. Теплоноситель не успел замерзнуть, хоть и немного охладился. Не так работают современные автоматики, оснащенные функцией холодного старта?
А еще вы забыли упомянуть про безопасность. Украденную цифровую денежку легко отследить и вернуть владельцу. И наказать мошенника. Особенно, если регистрироваться цифровые кошельки будут строго по паспорту (для физ.лица) или по ИГРН (для юр.лиц).
За код презентации во вьюшечке отдельный респект. Хоть статья и не об этом.
Именно для этого и поделили ^.^ Мы лишь показали, что для того, чтобы обрабатывать эту ситуацию, разумно выделить отдельный класс со своей ответственностью. Подменяя реализацию этого класса, вы можете работать с данными разной структуры. Ничего другого в схеме менять не придется в соответствие с принципами SOLID.
Мы решаем проблему дублирования кода из экрана в экран. Как обычно разработчики пишут табличные экраны? Каждый раз заводят контроллер, в котором реализуют источник данных и делегат таблицы, даже если в этих ответственностях совсем малые отличия. Как в вашем случае. Всего лишь меняется структура входных данных, но при этом разработчики сделают 2 совершенно разных контроллера, отличающихся парой строчек. Так? Наверняка так.
Далее, скорее всего разработчик попробует сделать какую-то универсальную связку датасорса и делегата, работающие во всех возможных случаях. Конечно, все случаи учесть все равно не получится и его решение будет работать далеко не всегда, а в неподходящих случаях придется городить огород, чтобы его решение можно было натянуть на глобус, или на сову ^.^ Таких решений на Хабре много. Вот из последнего. В итоге получается очень сложно и непонятно. Хотели упростить и сократить дублирование, а сделали непонятного франкенштейна.
Разбив же ответственности так, как мы предлагаем, вы сможете переиспользовать в обоих контроллерах все кроме провайдера данных. У вас будет всего лишь 2 разных провайдера данных, которые вы инжектируете в полностью идентичные контроллеры, источник данных и делегат. В итоге вы не напишите ни одной строчки дважды. У вас будет написан только различный код по работе с входными данными. Собственно, в этой статье это и показно.
Именно это и позволяет нам переиспользовать код из табличного экрана в табличный и создавать их практически за часы. При этом у нас нет сотен однотипных контроллеров, генерируемых кодогенераторами, как например, это делается в VIPER'е. И нет сложных монструозных решений, не работающих в частных случаях. Порог входа проверен небольшим числом новых разработчиков. Им понравилось.
Очень подробно мотивация описана в нашей первой статье. Рекомендую прочитать ее, если вы еще ее не читали. https://habr.com/ru/company/psb/blog/588332/
Мне удалось ответить на Ваш вопрос?
Цитата по ссылке:
"Пример NSURLCache в очередной раз показывает нам, насколько важно знать возможности системы, с которой работаешь.
Многие разработчики изобретают свой велосипед для организации кеширования, так как не знают о возможностях NSURLCache, инициализация которого занимает всего 2 строчки кода и делает работу в 100 раз эффективнее. Еще большее число вообще не задумывается о преимуществах сетевого кеширования и не использует его, нагружая свой сервер огромным количеством ненужных запросов."
https://habr.com/ru/post/179349/
Рекомендую к описанной практике добавить еще и максимальную декомпозицию задач.
80% задач в разработке программного обеспечения делятся на совершенно однотипные задачи типа: реализовать представление (вью), добавить валидаторы вводимых данных, реализовать пару-тройку запросов, реализовать преобразование данных из формата, вводимого пользователем в формат понимаемый сервером и обратно, реализовать бизнес логику и т.д.
80% этого дробления легко уложится в вашу практику. При этом все эти задачи будут атомарными и выполняться за полдня-день. Если задачи занимают больше времени, то их просто надо раздробить еще. До тех пор, пока они не станут размером в полдня-день.
После этого Вашу практику можно смело применять и в Scrum. В таком случае у вас будет в спринте не 1 задача, которая еще может и не влезть. А набор мелких задач, которые легко оцениваются на основании статистики и истории. И по этому набору мы можем уже гораздо более точно сказать, а влезет ли задача в спринт целиком, или какой-то ее кусок все же придется перетащить в следующий спринт.
Кажется, что одно из перечисленных приложений (или даже оба) должно справиться с этим:
1. https://github.com/nicklockwood/Tribute
2. https://github.com/carloe/LicenseGenerator-iOS
Кажется, что размер стека – это параметр, который вполне может быть рассчитан на этапе компиляции (если Вы не используете рекурсию). Поэтому проблем с переполнением стека в вашей программе быть не должно (компилятор подсчитает и установит необходимый вам размер стека) и сам этот пункт можно исключить из списка недостатков структур.
Можно ли СПМ-пакет сформировать одновременно и с бинарником, и с исходниками? И на лету менять с кем линковаться? Бинарник – для быстрого запуска. Исходники – для тех, кто хочет разобраться во внутрянке или подебажить?