Обосновать свое утверждение сможете? Своими словами, на конкретном примере, а не цитатками из псевдоумных книжек.
В итоге получаем так же 2 сущности, только работать с этим проще.
Это не так. Доступ к сигнлтону есть из любого места в проекте и осуществляется одной строчкой. Передача зависимостей в конструкторы завставляет постоянно возиться с этой передачей, организовывать процесс создания и раздачи зависимостей. Это не проще ни в какой из логик. И 2 сущности у вас до тех пор, пока вам не надоест таскать зависимости руками, там уже появляются менеджеры зависимостей — это уже 3 как минимиум сущности.
Использовать зависимости вместо синглтонов следует когда ограничения накладываемые синглтонами в проекте неприемлемы
Скорее дело в том, что ipad pro на арме уже давно мощнее (по крайней мере в синтетике) airов и базовых прошек на x86. При том что батарейку держит сильно дольше.
Второй поинт в том, что эппол очевидно хочет через пару итераций объеденить ipados и макось, как когдато хотели микрософт с их плиточной 8кой. И судя по тому, что они менее резко и более грамотно подходят к вопросу, у них может получиться. Учитывая что в ноутбуках батарейка почти в 2 раза более емкая, то и время работы маков можно поднять раза в 2, часов до 15-20 и даже до полного рабочего дня (8 часов) под нагрузкой.
Ну и вендор лок, куда уж без него.
Вот только пока не придумали, как нам бы еще и дизайнеров всех опрокинуть снова
Это как раз придумали, на новые иконки для макоси посмотрите…
Реактивность — это не технология, это простенький паттерн, который юзали все и везде, до того как обхайпованные придумали ему название. Называть это технологией, всеравно что называть технологией 2+2=4
Под написано мало — я имею ввиду, когда реально ничего не написано.
Ну типа «вася пупкин, работал столько то в одной компании, столько то в другой, и столько то в третьей». Никаких вывовов тут толком не сделаешь, кроме того что человек имея опыт поиска работы не осиливает написать более менее нормальное резюме. Пару раз таких видел — они реально оказывались бестолковыми.
Просто «головой» без опыта не придумаешь, что там важнее рассказать среднему читателю резюме, насколько детально и с каких сторон.
Ну это же элементарно, всегда можно попросить примеры резюме у друзей, коллег и чето похожее сострапять. Погуглить примеры в конце концеов. Если человек даже гуглить не умеет, то как он работу будет делать? На которой гуглить каждый день приходится.
Вы привели бредовый пример, который на практике неприменим. Что сразу выдает человека, который не понимает о чем говорит. Что значит слово передергиваение — почитайте в соседней вкладке, явно не то что вы имеете ввиду.
Вы же натурально говорите, что проще и дешевле выкинуть ваш код и написать заново
Да, зачастую небольшой кусок кода дешевле выкинуть и написать заново, чем строить систему таким образом, чтобы любой кусок можно было заменить за 2 строчки кода. Вы же тратите по 100 рублей каждый день, чтобы раз в два года потратить 5 рублей вместо 1000.
вообще невозможно написать транслятор со swift на другие платформы
Более того, его можно даже не писать — код на свифте комплиляется на разные платформы, на винду вроде тоже при желании можно. Вот только приложение это не только язык программирования, это еще и api системы и для мобилок первую очередь UI api. И большая часть приложения — взаимодейтсвие с этими api. В итоге вам даже с clean architecture придется переписать всю реализации, за исключением кода который предназначен для связки этих реализаций. Т.е. вы полностью перепишете приложение с ios под windows, только на уебанском стеке.
Я-то кросс-платформенные приложения разрабатываю
Судя по стилистике и бредовости утверждений разрабатываете на React Native. И да, это оскорбление.
Никакое глобально видимое состояние не должно быть открыто к изменениям
А еще код UI и бизнес логику всегда нужно разделять, океания всегда воевала с остазией, а земля покоится на трех китах. Смешно что человек, который мыслит догмами и цитатками из гуру, тут же просит от меня каких то доказательств.
Обоснуйте это свое утверждение. Приведите конкретные кейсы в которых static без const приведет к ошибкам. Приведите сколько таких кейсов в типичном приложении на ios (пусть будет обычный rest клиент). И оцените вероятность того что я вообще столкнусь с проблемой доступа из разных потоков, если я вообще не обращаюсь к глобальным состояниям из фоновых потоков.
Ах, ну и да. Чтобы избежать усложнения архитектуры, вкрутив синхронизацию доступа, вы предлагаете усложнить вообще все остальное избегая использования static. Где тут логика?
Адекватные люди знают, что один запуск CI-сервера с тестами всегда будет дешевле, чем гонять толпу индусов и тестировать всё руками
Тесты на этом CI-сервере видимо сами материализуются, и всегда в актуальном состоянии. Кроме того автотесты не отменяют ручного тестирования.
>Сильное утверждение. Докажите.
Ну вообщето кейс приводится в следующем же абзаце. Вы тестируете сущность А, которая работает с моком B. Вы так не поймаете ошибки, специфичные для связки сущности A и реального UI. Но тесты будут проходиться.
>Ещё одно сильное утверждение.
Типичное мобильное приложение — это рест клиент, в таком приложении код отправку запросов к беку, парсинг ответов от бека, ui код и перекладывалку данных от бека в этот ui код. Работа с сетью и парсинг — готовые либы, 100 раз оттестированные, перкладывалка данных (вы называете ее бизнес-логикой, хотя вся логика на беке) — 3.5 строчки кода. Все остальное это код работающий с UI. Так как этого кода больше всего, и он наименнее протестирован — то и вероятность ошибок там больше всего. Вообще, человек работавший вменяемое время в мобилками, на практике видит сколько косяков лезет в ui (особенно на андроиде) и доказательств этого очевидного наблюдения просить не будет
А то ведь я даже не сказал, зачем и как, но вы уже решили, будто я не понимаю
Так вы же сами сказали что не понимаете, просто этого не поняли. Поставьте лайк, если и эту фразу тоже не смогли понять.
Впрочем, я уже вижу, что изначальное моё предположение было верным — вы адекватный разработчик, и просто сразу пишете всё без багов.
Мы же говорим о вакансиях где надо головой работать, а не бургеры с бумажками перекладывать.
Даже если представить специалиста, который работал 20 лет на одной работе, он наверное додумается написать в резюме побольше информации чем, «2000-2020, software engeener in Vector ltd». А если не додумается, то он вероятно и по своей специальности так же херово думает
Ну да, главная помеха переноса ios приложения под windows это же реализация настроек.
Я видимо в точку попал, говоря про (не)адекватность. Вы несете полную чушь. Приложение написанное на swift\objc никогда не будет перенесено под windows, только если написать отдельное приложение с нуля.
Абстракции из вашего примера разумно делать, только для кроссплатформенных приложений (например на Qt или flutter), и то там все нужные абсракции сделаны во фреймворке, а каждая новая такая абстракция в юзеркоде только добавляет гемороя (надо же под каждую ОС новую реализацию писать).
Если настройки не меняются — это константы, а не настройки.
А если человек не видит различия между static и const, то кто он?
И тесты нормальные разработчики конечно же не пишут?
Адекватные люди пишут тесты там где написание тестов дешевле отлова ошибок, появляющихся без тестов. Например разумно тестировать апишки сервера, разумно тестрировать единичные критичные части кода.
А усложнение ахритектуры в несколько раз, только для того чтобы тестировать бизнес-логику, которая только и делает что перекладывает данные из jsonов в кнопки на экране — это абсурдный бред. Потому что время на фикс и ловлю 3.5 ошибок в этой примитивной бизнес-логике намного дешевле чем время на написание тестов + на работу с более сложным кодом + на время на фикс и ловлю десятков новых ошибок в коде, прослойках, абстракциях которые вообще не должны существовать.
Кроме того, излишние количество сущностей и связей порождает ошибки связанные с этими конкретными реализациями, которые тестами не поймаешь вообще.
Ну и вишенка на торте. Вот есть у вас сущность A которую вы тестируете, и есть замоканый инерфейс B с которым она взаимодействует. Так как основной источник ошибок в мобильных приложениях это системный код UI, а в тесте мы вместо него используем мок, который ведет себя далеко не так как реальный UI, то получается что мы тестируем НИЧЕГО. Т.е. мы вместо реальной работы мы тестируем абстрактную. Из 10 ошибок мы поймаем 2, зато скажем что тесты зелененькие.
Вот вы выучили что надо делать абстракции, выучили что нужно писать тесты, а КАК и главное ЗАЧЕМ они делаются вы не понимаете.
>Идеальный для кого?
Идеальный для того, чтобы максимально точно оценить навыки кандидата
Понятно что тестовое не всегда можно дать, поэтому приходится искать компромиссные варианты в виде собеседований и т.п.
Вообще лично мне, например проще сделать тестовое за вечер, чем болтать с зачастую неадекватными интервьюерами, которые спрашивают полную херню. И уж точно лучше чем ходить на 3 или 5 собесов.
Что приводит к ухудшению понимания кода разработчиками, увеличению количества мест где можно сделать баг, увеличению количества багов и т.д.
Конкретный пример — есть локальное хранилище в мобильном приложении, по clean architecture получается что надо сделать интерфейc Storage, и сделать конкретную реализацию например SqlLiteStorage. Все логично, ведь тогда можно будет легко поменять реализацию хранилища. А теперь внутри хранилища мне надо получить данные, например из настроек приложения. Все просто, делаем интерфейс Settings и IosSharedPrefsSettings реализацию, и передаем ее в SqlLiteStorage как зависимость. Зависимостей в проекте таким образом получается очень много, поэтому делаем еще менеджер зависимостей для всего этого.
В итоге получили 5 сущностей с кучей связей друг между другом.
Нормальный разработчик сначала оценит какова вероятность того что в приложении надо будет менять реализацию хранилища, реализацию настроек и вероятность того что их понадобится в рантайме подменять. Для большинства приложений вероятность смены хранилища (Например с CoreData на SQLite) — ничтожна, а реализации настроек и подмены этих вещей в рантайме — так вообще нулевая. Поэтому сделает хранилище синглтоном, а настройки вообще статиками.
В итоге получаем 2 сущности, вместо 5.
Система стала в 2 раза проще, следовательно стала понятнее для разработчиков, поэтому в нее быстрее и проще вносить изменения и чинить баги, она надежнее потому что намного меньше мест где можно совершить ошибку, следовательно меньше багов, и намного меньше трудновоспроизводимых багов связанных со связами между подсистемами.
Что будет если реализацию хранилища всетаки придется сменить? Ну потратить немного времени чтобы переписать внутрянку класса Storage всяко будет дешевле чем тратить время на поддержку и тестрирование и фикс возросшего количества багов зоопарка из clean architecture каждый день.
Вот и все. Нет ничего плохого, в том чтобы делать интерфейс и разные реализации если это реально нужно. Например если есть уверенность что реализацию точно придется менять, или вероятность этого приближается к 50%.
Вот только таких мест у вас в приложении будет одно-два. А clean architecture предлагает делать такое на каждый чих. Т.е для большинства случаев clean architecture решает проблему, которая в вашем проекте НЕ СУЩЕСТВУЕТ, принося десятки новых проблем усложняя код. Вывод из этого только один: люди, которые всегда и везде применяют сlean architecture, не только тотально некомпетентны как проектировщики, но еще и не адекватны.
Разве адекватный человек будет создавать себе новые проблемы, чтобы решить проблему которой нет?
Вы выкинули фреймворк и дефакто написали вместо него свой. Я же указываю вам на то, что проблема значительно глубже.
Да, вы показали что место популярного решения можно накостылить свое, которое работает быстрее. А то что в реально маленьком приложении у вас настоящий dependency hell из десятков зависимостей, к которому нужна хлипкая конструкция которая их разруливает вас не смущает.
Именно в этом некомпетентность, в том что вы считаете такую ситуацию нормальной. В том что у вас глаз не дергается, когда видит код в котором зависимостей больше чем кнопок на экране, решающий задачу передачи данных из jsonов в лейблы и кнопки.
Если передать экземпляр класса в конструктор — DI, а DI container — использовать для этого фреймворк, который раздает зависимости, то да, путаю.
А чем собственно плох DI в маленьких проектах?
Во-первых тем что в маленьких проектах нет большого количества зависимостей и необходимости их менеджить. Если проект маленький, а зависимостей много — вы вообще что-то в корне не так делаете.
Во-вторых, городить архитектуру с передачей зависимостей объектам, когда можно обойтись сигнлтонами, это бессмысленное и значительное усложнение кодовой базы на пустом месте.
Передавать единичные зависимости в конструктор — это ок, строить на этом архитектуру без нужных оснований — не ок.
Вы просто вырезали аргументы из моих слов. Давайте разберем по пунктам
внедрения DI — уже маркер некомпетентности (честно, как это связано?)
Хорошо, раз вы не понимаете, давайте проясним. Простой вопрос — вот есть такой подход — Dependency Injection, есть фреймворки для него. Объясните какую проблему\задачу этот подход решает? Какие есть альтернативы ему? Какие у него минусы, и какие плюсы? Почему в конкретно вашем приложении по вашему мнению стоит использовать именно его?
посмотрите какую хрень сделали дебилы в легаси, и какими костылями мне пришлось это решать
Эта фраза наиболее точно и емко описывает ситуацию, описываемую вами в вашей статье про DI. Вы с этим не согласны?
внедрения DI — уже маркер некомпетентности (честно, как это связано?
Я еще в первом комментарии написал. В небольшом rest-клиенте под ios на десяток экранов этих проблем которые решает DI не существует. Если вы используете такой подход в этом проекте, значит вы не понимаете что делаете. Если вы не понимаете что делаете, значит в вопросах проектирования вы некомпетентны.
на должности руководителей команды разработки попадают люди, которые не умеют проектировать
Если вы руководите разработкой проекта и не компетенты в вопросах проектирования, то вы не можете принимать правильных решений на этой должности. Что в итоге приводит к проблемам, порой детским, как в вашей статье.
Подход к собесам в додо провальный уже потому, что вы akaDuality там работаете.
А если вы на эту должность попали, не имея нужны скиллов, то что-то в процессе найма не так. Тем более что отбор в додо не самый простой, и есть много этапов собеседований. Я сильно сомневаюсь в валидности такого отбора, при таких итоговых результатах.
не понимает как позорится
Вы написали статью, которая показывает что ваша команда не в состоянии нормально написать типовое приложение. А вы даже не понимаете что тут не так.
обозначает ваш уровень как специалиста
дать вам проект с нуля написать — точно нет (одних только пет проектов у меня 4 штуки)
Я оцениваю ваш уровень, исходя из тех знаний которые вы демонстрируете. Доверить делать проект с нуля, человеку у которого rest клиент грузится 5 минут изза архитектурных проблем, я например не могу.
Вы просто не умеете их читать (про резюме)
Вы написали целую статью на тему того, что люди плохо пишут резюме и как по вашему мнению их надо писать. Я же ответил вам, про то что даже плохо написанное резюме несет много информации. Например, если в резюме написано мало, это говорит о недостаточном опыте кандидата. Не потому что он мало что умеет, и поэтому ничего не написал. А потому что имей он опыт, знал бы что надо писать побольше, чтобы можно было оценить. Вы же такую информацию из резюме извлекать не умеете (иначе бы не стали писать гиганскую статью с жалобами на резюме), следовательно не умеете в полной мере их читать (резюме)
Это делит на ноль весь ваш комментарий. Чистая архитектура — разновидность бизнес-религии, придуманная чтобы продавать консалтинговые услуги менеджменту крупных компаний, в т.ч. тренинги и прочее. Это аналог scrum/agile/safe, но для программирования. Посмотрите основное место работы Роберта Мартина, если вам не понятно. К проектированию никакого отношения не имеет, скорее наоборот поощряет вас делать ошибки, для решения которых потом будут платить за консалтинг.
Слушайте, я просто высказываю свое мнение, причем аргументированно. А вы называете мои аргументы хейтом или передергиванием — это же и есть настоящее передергивание.
Про книги не подскажу к сожалению, не знаю таких. Может кто-то другой ответит, буду рад.
Могу посоветовать писать побольше пет-проектов и придумывать там архитектуру с нуля. Лучше всего взять какуюто тему, где еще нет массовых готовых архитетур, игры например.
но на собеседованиях куда чаще попадаются «задачки, технологии и паттерны».
Что я могу сделать, самого это калит
А что имеется в виду под умением проектировать и какие вы вопросы на этот счет задаете?
Ну это умение организовывать архитектуру приложения, понимать по каким принципам она делается. Не выучить паттерны из книжки и лепить из них, а понимать по каким принципам эти шаблоны придумываются. Понимать почему в этом проекте уместно взять готовую архитектуру, а в этом сделать свою, почему в этом месте проекта надо брать такой подход, а в этом другой. Понимать почему тут можно воткнуть костыль, а тут вообще никак нельзя. Почему например эту задачу стоит решить готовой либой, а эту лучше самому написать. Вообще это элементарные навыки, которые появляются у любого кто несколько проектов с нуля сделал, не по шаблону конечно.
Если хотите практических примеров, то на примере коментария выше: умение проектировать это понимать что такое DI, какие проблемы он решает, когда его стоит использовать, а когда нет, какие есть альтернативные подходы, какой вариант DI (compile\runtime) лучше подходит к текущему проекту, и какую конечную реализацию выбрать. А не умение выбирать из 3 модных реализаций DI и опыт работы с ними.
и какие вы вопросы на этот счет задаете?
Спрашиваю мнение о тех или иных популярных решениях. Но в первую очередь смотрю на опыт. Если нет опыта разработки с нуля 2-3 проектов, спрашивать бессмысленно — навыков проектирования у него нет. Поэтому всегда обращаю внимание на наличие своих пет-проектов и их сложность. Опыт показывает что например джун, который активно разрабатывает пет-проекты оказывается на несколько голов выше чем мидл который 2-3 года учавствовал только в комерческой разработке. Есть еще большая проблема, у мобильщиков например — все проекты шаблонные, люди просто читают про какойто модных подход, а потом лепят тупо копируют его у себя в проектах. В итоге понимания как нужно проектировать не образуется, и они по факту зависают в развитии на уровне мидла, хотя лычки изза опыта прокачиваются. В итоге массовый рассинхрон между лычкой и уровнем скиллов.
Я вижу это иначе: статья про DI в runtime и compile time, часто популярные опенсурс решения могут приносить проблемы
Проблемы приносят не опенсурс решения, а отсутствие базовых навыков проектирования.
Проблема не в том что вы взяли херовую реализацию DI, а потом заменили на «нормальную». А то что вы вообще используете DI в маленьком ios проекте на десяток экранов, что и порождает кучу проблем.
Вы у себя в канале ссылаетесь на легаси, но это банальная отмаза. Мне бы например было стремно светить то что у меня в проекте так обстоят дела, пусть и изза легаси. Я бы просто не стал писать про это статью. Если бы меня заставили ее написать, то статья бы начиналась с дисклеймера типа «посмотрите какую хрень сделали дебилы в легаси, и какими костылями мне пришлось это решать»
Но вы то написали статью по своему желанию, и про легаси изначально ничего не сказали. Выходит что вы не считаете что такое состояние дел в проекте проблемой.
Я еще раз подчеркну, DI предназначен для решения опредленного набора проблем. В проекте вашего профиля и масштаба этих проблем не существует. Сам факта внедрения DI — уже маркер некомпетентности. Тот факт что вы этого не понимаете, а наличие статьи и запоздалые отмазки про легаси показывают что не понимаете, очень четко обозначивает ваш уровень как специалиста. Такое простительно для линейного мидла с 2-3 годами опыта работы. Для синьера или выше — это стоп-флаг.
Будь я вашим руководителем, я бы например мог спокойно давать вам такси в проекте и не переживать за то что они будут сделаны. Но например, дать вам проект с нуля написать — точно нет, или под большим присмотром. Чтобы потом надо мной юзеры и коллеги не смеялись, что у нас приложуха по 5 минут грузится.
Смотрите, это ведь один пример. А учитывая уровень проектирования, я думаю у вас в проекте еще не мало таких проблем. Проблемы бывают у всех, но это же rest-клиент. Шаблонная задача, которую ну все буквально делали.
Ваша статья по факту про то, что отдел ios разработки додо испытывает проблемы в написании простых rest-клиентов. Это позор.
Да, для зумерков ваша статья выглядит как «Они заменили модный фрейморк А на модный фреймворк B, круто, coding matters!». Но для любого разраба уровнем выше мидла, она показатель состояния дел в команде.
Посмотреть код очень важно, но с тестовым заданием много проблем: его объём, время на решение, оплата труда и т.д.
Главный минус тестового — нежелание кандидатов их делать. Но раз у ваших кандидатов хватает запала по 5 собесам ходить, но и на тестовое хватит.
Что я не понял, так это про какой уровень кандидатов мы нанимаете
Разных, мидлов, джунов синьеров.
Тестовое нормально покажет только джуна-мидла
Это неправда, тестовое нормально покажет любого, кому надо писать код. К тому же можно давать разные тестовые для разных уровней кандидатов.
Синьеров собеседовать проще всего, там код и опыт видно по резюме. Чаще всего достаточно просто за жизнь поболтать — и это будет лучшим вариантом.
Крутой спец конечно разберется во фреймворках, но есть разница между знанием и опытом
Не считаю фреймворки таким серьезным знанием, чтобы там требовался большой опыт. Одно дело конечно опыт работы с SDK ОС, это понятно, но спрашивать опыт работы с очередным говно-эвентбасом, запрашивалкой rest-запросов или парсилкой jsonнов это абсурд. Гораздо важнее чтобы кандидат понимал что зачем нужно и как сделано. Мне нужен бармен который шарит как мешать коктели, а не который выучил рецепт пинаколады, а отвертку намешать не может.
Это я уже проходил.
Вредных советов там не меньше чем хороших. Сопроводительное письмо? Может мне еще фотку прикрепить? Сам стиль и формат резюме может рассказать о человеке и его опыте много больше чем он сам захочет написать. Резюме сеньера отличается от резюме мидла или джуна с первого взгляда, также легко как резюме дебича от нормального человека. А вы хотите чтобы все кандидаты под одну гребенку вам писали. Вы просто не умеете их читать.
Подход к собесам в додо провальный уже потому, что вы akaDuality там работаете.
Чтобы понять что за человек, обычно достаточно внимательно посмотреть в резюме. В 80% случаев абсолютно понятно кто придет на собеседование.
А додо устраивает по 5 собесов, и в итоге на должности руководителей команды разработки попадают люди, которые не умеют проектировать, и у которых элементарный rest клиент из семи экранов 2 минуты запускается. И который даже не понимает как позорится, выкладывая такое состояние дел в проекте на всеобщее обозрение.
Идеальный вариант собеса это тестовое + собес по результатам тестового. Только так можно понять как человек программирует.
Какие скиллы я стараюсь оценить на собеседовании?
Умение проектировать/скорость работы/умение разбираться с говнофремворками, либами, говнокодом и т.п. Это вещи которые требуются в работе разработчика каждый день.
Умение проектировать — ключевой скилл, путь в нормальные руководители разработки без этого скилла закрыт. Руководителем вы конечно можете стать, но ни одного внятного решения без этого принять не сможете. Команда разрабов который руководит неумеющий проектировать человек — говноделы. Человек без этого скила — максимум линейный разраб, за которым периодически надо присматривать. Он может быть хорошим линейным разработчиком, но давать ему на откуп проект — значит завалить проект.
Умение разбираться с новым кодом (чужим говнокодом/либами/фремворками) — второй по важности скилл. Любой линейный разраб должен это уметь. Исправить баг в легаси говнокоде, вкорячить в проект кривожопый фреймворк, найти готовую либу решение для задачи, и выбрать из альтернативных вариантов — это все любой нормальный мидл должен делать без вопросов.
Скорость работы — ну тут все понятно. Если человек в среднем таски выполняет медленно, он просто не тянет работу.
Что я не НЕ спрашиваю на собесе?
В первую очередь это алгоритмические задачи. Потому что умение программировать и умение решать такие задачи — никак не связано. И опыт показывает что часто если человек умеет и любит решать задачки, то программировать он не умеет. Неоднократно видел как брали человека, основываясь на его умениях в задачках, а потом он испыталку не проходил.
Так же я не спрашиваю умение работы с т.н. «технологиями». Rx, DI, паттерны, фреймворки, архитерктуры, языки программирования (в разумных пределах) и т.п. Причина проста — это бесполезно. Если человек толковый, то он на ходу разберется с фреймворками и паттернами которые есть в проекте. Если совсем толковый то еще и понимает какие «технологии» уместны в проекте, а какие нет. А если бестолковый, но зато знает фреймворки — то он нахер не нужен.
Это не так. Доступ к сигнлтону есть из любого места в проекте и осуществляется одной строчкой. Передача зависимостей в конструкторы завставляет постоянно возиться с этой передачей, организовывать процесс создания и раздачи зависимостей. Это не проще ни в какой из логик. И 2 сущности у вас до тех пор, пока вам не надоест таскать зависимости руками, там уже появляются менеджеры зависимостей — это уже 3 как минимиум сущности.
Использовать зависимости вместо синглтонов следует когда ограничения накладываемые синглтонами в проекте неприемлемы
Второй поинт в том, что эппол очевидно хочет через пару итераций объеденить ipados и макось, как когдато хотели микрософт с их плиточной 8кой. И судя по тому, что они менее резко и более грамотно подходят к вопросу, у них может получиться. Учитывая что в ноутбуках батарейка почти в 2 раза более емкая, то и время работы маков можно поднять раза в 2, часов до 15-20 и даже до полного рабочего дня (8 часов) под нагрузкой.
Ну и вендор лок, куда уж без него.
Это как раз придумали, на новые иконки для макоси посмотрите…
Реактивность — это не технология, это простенький паттерн, который юзали все и везде, до того как обхайпованные придумали ему название. Называть это технологией, всеравно что называть технологией 2+2=4
Ну типа «вася пупкин, работал столько то в одной компании, столько то в другой, и столько то в третьей». Никаких вывовов тут толком не сделаешь, кроме того что человек имея опыт поиска работы не осиливает написать более менее нормальное резюме. Пару раз таких видел — они реально оказывались бестолковыми.
Ну это же элементарно, всегда можно попросить примеры резюме у друзей, коллег и чето похожее сострапять. Погуглить примеры в конце концеов. Если человек даже гуглить не умеет, то как он работу будет делать? На которой гуглить каждый день приходится.
Вы привели бредовый пример, который на практике неприменим. Что сразу выдает человека, который не понимает о чем говорит. Что значит слово передергиваение — почитайте в соседней вкладке, явно не то что вы имеете ввиду.
Да, зачастую небольшой кусок кода дешевле выкинуть и написать заново, чем строить систему таким образом, чтобы любой кусок можно было заменить за 2 строчки кода. Вы же тратите по 100 рублей каждый день, чтобы раз в два года потратить 5 рублей вместо 1000.
Более того, его можно даже не писать — код на свифте комплиляется на разные платформы, на винду вроде тоже при желании можно. Вот только приложение это не только язык программирования, это еще и api системы и для мобилок первую очередь UI api. И большая часть приложения — взаимодейтсвие с этими api. В итоге вам даже с clean architecture придется переписать всю реализации, за исключением кода который предназначен для связки этих реализаций. Т.е. вы полностью перепишете приложение с ios под windows, только на уебанском стеке.
Судя по стилистике и бредовости утверждений разрабатываете на React Native. И да, это оскорбление.
А еще код UI и бизнес логику всегда нужно разделять, океания всегда воевала с остазией, а земля покоится на трех китах. Смешно что человек, который мыслит догмами и цитатками из гуру, тут же просит от меня каких то доказательств.
Обоснуйте это свое утверждение. Приведите конкретные кейсы в которых static без const приведет к ошибкам. Приведите сколько таких кейсов в типичном приложении на ios (пусть будет обычный rest клиент). И оцените вероятность того что я вообще столкнусь с проблемой доступа из разных потоков, если я вообще не обращаюсь к глобальным состояниям из фоновых потоков.
Ах, ну и да. Чтобы избежать усложнения архитектуры, вкрутив синхронизацию доступа, вы предлагаете усложнить вообще все остальное избегая использования static. Где тут логика?
Тесты на этом CI-сервере видимо сами материализуются, и всегда в актуальном состоянии. Кроме того автотесты не отменяют ручного тестирования.
>Сильное утверждение. Докажите.
Ну вообщето кейс приводится в следующем же абзаце. Вы тестируете сущность А, которая работает с моком B. Вы так не поймаете ошибки, специфичные для связки сущности A и реального UI. Но тесты будут проходиться.
>Ещё одно сильное утверждение.
Типичное мобильное приложение — это рест клиент, в таком приложении код отправку запросов к беку, парсинг ответов от бека, ui код и перекладывалку данных от бека в этот ui код. Работа с сетью и парсинг — готовые либы, 100 раз оттестированные, перкладывалка данных (вы называете ее бизнес-логикой, хотя вся логика на беке) — 3.5 строчки кода. Все остальное это код работающий с UI. Так как этого кода больше всего, и он наименнее протестирован — то и вероятность ошибок там больше всего. Вообще, человек работавший вменяемое время в мобилками, на практике видит сколько косяков лезет в ui (особенно на андроиде) и доказательств этого очевидного наблюдения просить не будет
Так вы же сами сказали что не понимаете, просто этого не поняли. Поставьте лайк, если и эту фразу тоже не смогли понять.
Вообще просто попробуйте троллить менее бездарно
Даже если представить специалиста, который работал 20 лет на одной работе, он наверное додумается написать в резюме побольше информации чем, «2000-2020, software engeener in Vector ltd». А если не додумается, то он вероятно и по своей специальности так же херово думает
Я видимо в точку попал, говоря про (не)адекватность. Вы несете полную чушь. Приложение написанное на swift\objc никогда не будет перенесено под windows, только если написать отдельное приложение с нуля.
Абстракции из вашего примера разумно делать, только для кроссплатформенных приложений (например на Qt или flutter), и то там все нужные абсракции сделаны во фреймворке, а каждая новая такая абстракция в юзеркоде только добавляет гемороя (надо же под каждую ОС новую реализацию писать).
А если человек не видит различия между static и const, то кто он?
Адекватные люди пишут тесты там где написание тестов дешевле отлова ошибок, появляющихся без тестов. Например разумно тестировать апишки сервера, разумно тестрировать единичные критичные части кода.
А усложнение ахритектуры в несколько раз, только для того чтобы тестировать бизнес-логику, которая только и делает что перекладывает данные из jsonов в кнопки на экране — это абсурдный бред. Потому что время на фикс и ловлю 3.5 ошибок в этой примитивной бизнес-логике намного дешевле чем время на написание тестов + на работу с более сложным кодом + на время на фикс и ловлю десятков новых ошибок в коде, прослойках, абстракциях которые вообще не должны существовать.
Кроме того, излишние количество сущностей и связей порождает ошибки связанные с этими конкретными реализациями, которые тестами не поймаешь вообще.
Ну и вишенка на торте. Вот есть у вас сущность A которую вы тестируете, и есть замоканый инерфейс B с которым она взаимодействует. Так как основной источник ошибок в мобильных приложениях это системный код UI, а в тесте мы вместо него используем мок, который ведет себя далеко не так как реальный UI, то получается что мы тестируем НИЧЕГО. Т.е. мы вместо реальной работы мы тестируем абстрактную. Из 10 ошибок мы поймаем 2, зато скажем что тесты зелененькие.
Вот вы выучили что надо делать абстракции, выучили что нужно писать тесты, а КАК и главное ЗАЧЕМ они делаются вы не понимаете.
Идеальный для того, чтобы максимально точно оценить навыки кандидата
Понятно что тестовое не всегда можно дать, поэтому приходится искать компромиссные варианты в виде собеседований и т.п.
Вообще лично мне, например проще сделать тестовое за вечер, чем болтать с зачастую неадекватными интервьюерами, которые спрашивают полную херню. И уж точно лучше чем ходить на 3 или 5 собесов.
Что приводит к ухудшению понимания кода разработчиками, увеличению количества мест где можно сделать баг, увеличению количества багов и т.д.
Конкретный пример — есть локальное хранилище в мобильном приложении, по clean architecture получается что надо сделать интерфейc Storage, и сделать конкретную реализацию например SqlLiteStorage. Все логично, ведь тогда можно будет легко поменять реализацию хранилища. А теперь внутри хранилища мне надо получить данные, например из настроек приложения. Все просто, делаем интерфейс Settings и IosSharedPrefsSettings реализацию, и передаем ее в SqlLiteStorage как зависимость. Зависимостей в проекте таким образом получается очень много, поэтому делаем еще менеджер зависимостей для всего этого.
В итоге получили 5 сущностей с кучей связей друг между другом.
Нормальный разработчик сначала оценит какова вероятность того что в приложении надо будет менять реализацию хранилища, реализацию настроек и вероятность того что их понадобится в рантайме подменять. Для большинства приложений вероятность смены хранилища (Например с CoreData на SQLite) — ничтожна, а реализации настроек и подмены этих вещей в рантайме — так вообще нулевая. Поэтому сделает хранилище синглтоном, а настройки вообще статиками.
В итоге получаем 2 сущности, вместо 5.
Система стала в 2 раза проще, следовательно стала понятнее для разработчиков, поэтому в нее быстрее и проще вносить изменения и чинить баги, она надежнее потому что намного меньше мест где можно совершить ошибку, следовательно меньше багов, и намного меньше трудновоспроизводимых багов связанных со связами между подсистемами.
Что будет если реализацию хранилища всетаки придется сменить? Ну потратить немного времени чтобы переписать внутрянку класса Storage всяко будет дешевле чем тратить время на поддержку и тестрирование и фикс возросшего количества багов зоопарка из clean architecture каждый день.
Вот и все. Нет ничего плохого, в том чтобы делать интерфейс и разные реализации если это реально нужно. Например если есть уверенность что реализацию точно придется менять, или вероятность этого приближается к 50%.
Вот только таких мест у вас в приложении будет одно-два. А clean architecture предлагает делать такое на каждый чих. Т.е для большинства случаев clean architecture решает проблему, которая в вашем проекте НЕ СУЩЕСТВУЕТ, принося десятки новых проблем усложняя код. Вывод из этого только один: люди, которые всегда и везде применяют сlean architecture, не только тотально некомпетентны как проектировщики, но еще и не адекватны.
Разве адекватный человек будет создавать себе новые проблемы, чтобы решить проблему которой нет?
Да, вы показали что место популярного решения можно накостылить свое, которое работает быстрее. А то что в реально маленьком приложении у вас настоящий dependency hell из десятков зависимостей, к которому нужна хлипкая конструкция которая их разруливает вас не смущает.
Именно в этом некомпетентность, в том что вы считаете такую ситуацию нормальной. В том что у вас глаз не дергается, когда видит код в котором зависимостей больше чем кнопок на экране, решающий задачу передачи данных из jsonов в лейблы и кнопки.
Кекну если у вас там еще какойнибудь VIPER.
Если передать экземпляр класса в конструктор — DI, а DI container — использовать для этого фреймворк, который раздает зависимости, то да, путаю.
Во-первых тем что в маленьких проектах нет большого количества зависимостей и необходимости их менеджить. Если проект маленький, а зависимостей много — вы вообще что-то в корне не так делаете.
Во-вторых, городить архитектуру с передачей зависимостей объектам, когда можно обойтись сигнлтонами, это бессмысленное и значительное усложнение кодовой базы на пустом месте.
Передавать единичные зависимости в конструктор — это ок, строить на этом архитектуру без нужных оснований — не ок.
Хорошо, раз вы не понимаете, давайте проясним. Простой вопрос — вот есть такой подход — Dependency Injection, есть фреймворки для него. Объясните какую проблему\задачу этот подход решает? Какие есть альтернативы ему? Какие у него минусы, и какие плюсы? Почему в конкретно вашем приложении по вашему мнению стоит использовать именно его?
Эта фраза наиболее точно и емко описывает ситуацию, описываемую вами в вашей статье про DI. Вы с этим не согласны?
Я еще в первом комментарии написал. В небольшом rest-клиенте под ios на десяток экранов этих проблем которые решает DI не существует. Если вы используете такой подход в этом проекте, значит вы не понимаете что делаете. Если вы не понимаете что делаете, значит в вопросах проектирования вы некомпетентны.
Если вы руководите разработкой проекта и не компетенты в вопросах проектирования, то вы не можете принимать правильных решений на этой должности. Что в итоге приводит к проблемам, порой детским, как в вашей статье.
А если вы на эту должность попали, не имея нужны скиллов, то что-то в процессе найма не так. Тем более что отбор в додо не самый простой, и есть много этапов собеседований. Я сильно сомневаюсь в валидности такого отбора, при таких итоговых результатах.
Вы написали статью, которая показывает что ваша команда не в состоянии нормально написать типовое приложение. А вы даже не понимаете что тут не так.
Я оцениваю ваш уровень, исходя из тех знаний которые вы демонстрируете. Доверить делать проект с нуля, человеку у которого rest клиент грузится 5 минут изза архитектурных проблем, я например не могу.
Вы написали целую статью на тему того, что люди плохо пишут резюме и как по вашему мнению их надо писать. Я же ответил вам, про то что даже плохо написанное резюме несет много информации. Например, если в резюме написано мало, это говорит о недостаточном опыте кандидата. Не потому что он мало что умеет, и поэтому ничего не написал. А потому что имей он опыт, знал бы что надо писать побольше, чтобы можно было оценить. Вы же такую информацию из резюме извлекать не умеете (иначе бы не стали писать гиганскую статью с жалобами на резюме), следовательно не умеете в полной мере их читать (резюме)
Это делит на ноль весь ваш комментарий. Чистая архитектура — разновидность бизнес-религии, придуманная чтобы продавать консалтинговые услуги менеджменту крупных компаний, в т.ч. тренинги и прочее. Это аналог scrum/agile/safe, но для программирования. Посмотрите основное место работы Роберта Мартина, если вам не понятно. К проектированию никакого отношения не имеет, скорее наоборот поощряет вас делать ошибки, для решения которых потом будут платить за консалтинг.
Могу посоветовать писать побольше пет-проектов и придумывать там архитектуру с нуля. Лучше всего взять какуюто тему, где еще нет массовых готовых архитетур, игры например.
Ну это умение организовывать архитектуру приложения, понимать по каким принципам она делается. Не выучить паттерны из книжки и лепить из них, а понимать по каким принципам эти шаблоны придумываются. Понимать почему в этом проекте уместно взять готовую архитектуру, а в этом сделать свою, почему в этом месте проекта надо брать такой подход, а в этом другой. Понимать почему тут можно воткнуть костыль, а тут вообще никак нельзя. Почему например эту задачу стоит решить готовой либой, а эту лучше самому написать. Вообще это элементарные навыки, которые появляются у любого кто несколько проектов с нуля сделал, не по шаблону конечно.
Если хотите практических примеров, то на примере коментария выше: умение проектировать это понимать что такое DI, какие проблемы он решает, когда его стоит использовать, а когда нет, какие есть альтернативные подходы, какой вариант DI (compile\runtime) лучше подходит к текущему проекту, и какую конечную реализацию выбрать. А не умение выбирать из 3 модных реализаций DI и опыт работы с ними.
Спрашиваю мнение о тех или иных популярных решениях. Но в первую очередь смотрю на опыт. Если нет опыта разработки с нуля 2-3 проектов, спрашивать бессмысленно — навыков проектирования у него нет. Поэтому всегда обращаю внимание на наличие своих пет-проектов и их сложность. Опыт показывает что например джун, который активно разрабатывает пет-проекты оказывается на несколько голов выше чем мидл который 2-3 года учавствовал только в комерческой разработке. Есть еще большая проблема, у мобильщиков например — все проекты шаблонные, люди просто читают про какойто модных подход, а потом лепят тупо копируют его у себя в проектах. В итоге понимания как нужно проектировать не образуется, и они по факту зависают в развитии на уровне мидла, хотя лычки изза опыта прокачиваются. В итоге массовый рассинхрон между лычкой и уровнем скиллов.
Проблема не в том что вы взяли херовую реализацию DI, а потом заменили на «нормальную». А то что вы вообще используете DI в маленьком ios проекте на десяток экранов, что и порождает кучу проблем.
Вы у себя в канале ссылаетесь на легаси, но это банальная отмаза. Мне бы например было стремно светить то что у меня в проекте так обстоят дела, пусть и изза легаси. Я бы просто не стал писать про это статью. Если бы меня заставили ее написать, то статья бы начиналась с дисклеймера типа «посмотрите какую хрень сделали дебилы в легаси, и какими костылями мне пришлось это решать»
Но вы то написали статью по своему желанию, и про легаси изначально ничего не сказали. Выходит что вы не считаете что такое состояние дел в проекте проблемой.
Я еще раз подчеркну, DI предназначен для решения опредленного набора проблем. В проекте вашего профиля и масштаба этих проблем не существует. Сам факта внедрения DI — уже маркер некомпетентности. Тот факт что вы этого не понимаете, а наличие статьи и запоздалые отмазки про легаси показывают что не понимаете, очень четко обозначивает ваш уровень как специалиста. Такое простительно для линейного мидла с 2-3 годами опыта работы. Для синьера или выше — это стоп-флаг.
Будь я вашим руководителем, я бы например мог спокойно давать вам такси в проекте и не переживать за то что они будут сделаны. Но например, дать вам проект с нуля написать — точно нет, или под большим присмотром. Чтобы потом надо мной юзеры и коллеги не смеялись, что у нас приложуха по 5 минут грузится.
Смотрите, это ведь один пример. А учитывая уровень проектирования, я думаю у вас в проекте еще не мало таких проблем. Проблемы бывают у всех, но это же rest-клиент. Шаблонная задача, которую ну все буквально делали.
Ваша статья по факту про то, что отдел ios разработки додо испытывает проблемы в написании простых rest-клиентов. Это позор.
Да, для зумерков ваша статья выглядит как «Они заменили модный фрейморк А на модный фреймворк B, круто, coding matters!». Но для любого разраба уровнем выше мидла, она показатель состояния дел в команде.
Главный минус тестового — нежелание кандидатов их делать. Но раз у ваших кандидатов хватает запала по 5 собесам ходить, но и на тестовое хватит.
Разных, мидлов, джунов синьеров.
Это неправда, тестовое нормально покажет любого, кому надо писать код. К тому же можно давать разные тестовые для разных уровней кандидатов.
Синьеров собеседовать проще всего, там код и опыт видно по резюме. Чаще всего достаточно просто за жизнь поболтать — и это будет лучшим вариантом.
Не считаю фреймворки таким серьезным знанием, чтобы там требовался большой опыт. Одно дело конечно опыт работы с SDK ОС, это понятно, но спрашивать опыт работы с очередным говно-эвентбасом, запрашивалкой rest-запросов или парсилкой jsonнов это абсурд. Гораздо важнее чтобы кандидат понимал что зачем нужно и как сделано. Мне нужен бармен который шарит как мешать коктели, а не который выучил рецепт пинаколады, а отвертку намешать не может.
Вредных советов там не меньше чем хороших. Сопроводительное письмо? Может мне еще фотку прикрепить? Сам стиль и формат резюме может рассказать о человеке и его опыте много больше чем он сам захочет написать. Резюме сеньера отличается от резюме мидла или джуна с первого взгляда, также легко как резюме дебича от нормального человека. А вы хотите чтобы все кандидаты под одну гребенку вам писали. Вы просто не умеете их читать.
Чтобы понять что за человек, обычно достаточно внимательно посмотреть в резюме. В 80% случаев абсолютно понятно кто придет на собеседование.
А додо устраивает по 5 собесов, и в итоге на должности руководителей команды разработки попадают люди, которые не умеют проектировать, и у которых элементарный rest клиент из семи экранов 2 минуты запускается. И который даже не понимает как позорится, выкладывая такое состояние дел в проекте на всеобщее обозрение.
Идеальный вариант собеса это тестовое + собес по результатам тестового. Только так можно понять как человек программирует.
Какие скиллы я стараюсь оценить на собеседовании?
Умение проектировать/скорость работы/умение разбираться с говнофремворками, либами, говнокодом и т.п. Это вещи которые требуются в работе разработчика каждый день.
Умение проектировать — ключевой скилл, путь в нормальные руководители разработки без этого скилла закрыт. Руководителем вы конечно можете стать, но ни одного внятного решения без этого принять не сможете. Команда разрабов который руководит неумеющий проектировать человек — говноделы. Человек без этого скила — максимум линейный разраб, за которым периодически надо присматривать. Он может быть хорошим линейным разработчиком, но давать ему на откуп проект — значит завалить проект.
Умение разбираться с новым кодом (чужим говнокодом/либами/фремворками) — второй по важности скилл. Любой линейный разраб должен это уметь. Исправить баг в легаси говнокоде, вкорячить в проект кривожопый фреймворк, найти готовую либу решение для задачи, и выбрать из альтернативных вариантов — это все любой нормальный мидл должен делать без вопросов.
Скорость работы — ну тут все понятно. Если человек в среднем таски выполняет медленно, он просто не тянет работу.
Что я не НЕ спрашиваю на собесе?
В первую очередь это алгоритмические задачи. Потому что умение программировать и умение решать такие задачи — никак не связано. И опыт показывает что часто если человек умеет и любит решать задачки, то программировать он не умеет. Неоднократно видел как брали человека, основываясь на его умениях в задачках, а потом он испыталку не проходил.
Так же я не спрашиваю умение работы с т.н. «технологиями». Rx, DI, паттерны, фреймворки, архитерктуры, языки программирования (в разумных пределах) и т.п. Причина проста — это бесполезно. Если человек толковый, то он на ходу разберется с фреймворками и паттернами которые есть в проекте. Если совсем толковый то еще и понимает какие «технологии» уместны в проекте, а какие нет. А если бестолковый, но зато знает фреймворки — то он нахер не нужен.