душой я с вами согласен) но порой реалии бизнеса таковы, что приходится оценивать что дороже - уболтать человека, убедить, помочь и дать ему советы, либо тратить время и деньги на поиск нового сотрудника 🤷♂️
Добрый вечер! Если кратко отвечать - зависит от человека)
А если более подробно... Есть такая поведенческая модель людей под названием DISC, попытаюсь через неё пояснить. Если сжато передать смысл (думаю, в случае ошибки меня в комментариях поправят) - есть "интроверты", есть "экстраверты". И есть люди, для которых на первом месте чувства и эмоции как свои, так и других людей, и есть те, для которых более важен результат. Далее комбинаторика, два на два, в итоге 4 психотипа получается.
Так вот в основании всего этого деления вроде как не просто ИМХО, а научные исследования, говорящие что интроверты не просто так стараются не лезть в шумные компании с незнакомыми людьми, а экстраверты - наоборот. А потому, что мозг работает таким образом: одни получают серотонин, когда находятся в центре внимания, другие - когда либо отдыхают в одиночестве, либо в компании с близкими людьми. И точно так же с эмпатией и нацеленностью на результат - одним важны чувства и эмоции, другим - следование правилам и эффективность, тоже потому что так голова устроена.
И вот теперь, приняв за правду такую модель, кому будет приятно копаться в чужом коде, встречать наверняка очевидные косяки других людей, и регулярно доказывать коллегам, что они не правы? Как будто только экстравертам, ориентированным на задачи. А вот у интроверта, оринтированного на результат, скорее всего бомбить будет от непонимания у других людей, как ему кажется, очевидных вещей. А если еще и какие-то договоренности нарушаются, которые вроде как не сложно соблюсти - то вдвойне) А интероверты вообще все эти терки в гробу видали.
А вот если просто делать задачу, тут практически всем хорошо при любом раскладе (с учетом того, что мы все же все разработчики и какой-никакой код писать да должны). Хочешь меньше взаимодействия с другими людьми - общайся только по рабочим вопросам, хочешь больше - найди единомышленника и обменивайся мыслями с ним в течение дня. А если еще задача хорошо проработана да спроектирована - то вообще думать можно минимально, остается просто сидеть да работать.
Но только в голове стоит держать, что в этой картине "код ревью" - это не просто проглядеть нейминг да соблюдение архитектурных принципов по диагонали за 5 минут, затрекав полчаса, параллельно попить чаек и сгоняв на перекур)
Добрый день! Так точно, все правильно поняли, пока только во время активной разработки используется. Но, в целом, ничего не мешает попробовать внедрить решение на этап тестирования, только тут надо будет обдумать и посоветоваться с QA-командой. Опыт написания автотестов у нас имеется, но пишутся они все же на реальное приложение - помимо проверки логики модуля можно попутно проверить и его интеграцию. Если говорить о ручном тестировании и проведении смоука - тут опять же важно понять, не отвалилась ли интеграция той или иной проверяемой фичи.
Возможное применение, которое я вижу - проведение тестов большой фичи со сложной логикой, которая, к тому же, располагается в труднодоступном месте, в таком вспомогательном приложении во время ручных/автотестов (чтоб время на перемещение между экранами не терять) + отдельное проведение интеграционных тестов на реальном приложении.
Помимо тестов такая система неплохо помогает, если есть весьма похожие внешне экраны с практически или совершенно разной логикой: ViewInput/Output протоколы позволяют легко и непринужденно подсунуть к готовой View другой Presenter с новой логикой.
В качестве примера, из последнего, когда такой прием применял — экран карты неких объектов. В одном кейсе экран представлял собой просто View с минимум логики, где даже запрос не выполнялся, в другом — самостоятельный полноценный экран -> View одна и она переиспользуется, просто к ней подсовывается в каждом случае свой Presenter
Отлично, спасибо за информацию! Тогда точно пора обратить свой взор на настройку окружение через .xcconfig.
Но отдельно замечу, что хотя подход с таким скриптом сам по себе решает одну определенную проблему, которую и можно было бы избежать в принципе, но сам опыт оказался полезным. Приятно было отвлечься и попробовать себя в несколько иной роли, кроме iOS-разработчика, плюс найти подход и выявить проблемы с запуском самописных скриптов)
Чувствую, пора еще раз посмотреть в сторону .xcconfig)
Только один вопрос есть. Где-то полгода назад на онбординге один разработчик как-то пытался реализовать такой подход, но завяз с тем, что разные бандлы => разные проекты в firebase => разные .plist файлы для конфигурации аналитики. И реализовать корректное их подтягивание в зависимости от конфигурации у него с ходу не получилось. Может быть у вас есть какие-то рецепты для таких случаев?
Значит, я вас все же правильно понял) Да, это уход в сторону дробления приложения на модули, и в данный момент новые проекты у нас уже создаются с многомодульной архитектурой. И это, конечно, правильно) Но, как сказал выше, тратить время на проект в стадии неспешной поддержки, с вероятностью скорого её прекращения, да к тому же с большими шансами получить гору импакта, показалось нецелесообразным.
А не могли бы вы более детально раскрыть суть вопроса? Вся кодовая база у нас естественно лежит в общем репозитории, с которым работает вся команда. Если же вы имели в виду, что можно весь проект разбить на отдельные модули, в рамках которых описанных проблем бы не возникло, — то данный подход не рассматривался, ибо второй таргет был добавлен «на коленке» в свободное от работы время, а времени на внедрение многомодульной архитектуры не было) Да и нецелесообразно это было, в силу большого количества легаси-кода на проекте, и как следствие большой сложности и огромного количества импакта
В свое время в студии мы проводили исследование, где выясняли, что нам лучше подходит для разделения сборок под разное окружение, в котором в том числе рассматривался подход и с .xcconfig, и со схемами, и с разными таргетами. Выбор тогда пал на использование таргетов, так как описанный подход позволяет более явно разделять файлы (вроде GoogleService-Info.plist) между таргетами, плюс на тот момент в разработке были проекты, где нужны были реально разные инстансы приложений (случай брендирования одного приложения с дополнением различной логики в зависимости от конкретного таргета). Но соглашусь с вами, это добавляет головной боли, и в конкретно данном случае вполне мог подойти подход с использованием указанной вами связки)
душой я с вами согласен) но порой реалии бизнеса таковы, что приходится оценивать что дороже - уболтать человека, убедить, помочь и дать ему советы, либо тратить время и деньги на поиск нового сотрудника 🤷♂️
Добрый вечер! Если кратко отвечать - зависит от человека)
А если более подробно... Есть такая поведенческая модель людей под названием DISC, попытаюсь через неё пояснить. Если сжато передать смысл (думаю, в случае ошибки меня в комментариях поправят) - есть "интроверты", есть "экстраверты". И есть люди, для которых на первом месте чувства и эмоции как свои, так и других людей, и есть те, для которых более важен результат. Далее комбинаторика, два на два, в итоге 4 психотипа получается.
Так вот в основании всего этого деления вроде как не просто ИМХО, а научные исследования, говорящие что интроверты не просто так стараются не лезть в шумные компании с незнакомыми людьми, а экстраверты - наоборот. А потому, что мозг работает таким образом: одни получают серотонин, когда находятся в центре внимания, другие - когда либо отдыхают в одиночестве, либо в компании с близкими людьми. И точно так же с эмпатией и нацеленностью на результат - одним важны чувства и эмоции, другим - следование правилам и эффективность, тоже потому что так голова устроена.
И вот теперь, приняв за правду такую модель, кому будет приятно копаться в чужом коде, встречать наверняка очевидные косяки других людей, и регулярно доказывать коллегам, что они не правы? Как будто только экстравертам, ориентированным на задачи. А вот у интроверта, оринтированного на результат, скорее всего бомбить будет от непонимания у других людей, как ему кажется, очевидных вещей. А если еще и какие-то договоренности нарушаются, которые вроде как не сложно соблюсти - то вдвойне) А интероверты вообще все эти терки в гробу видали.
А вот если просто делать задачу, тут практически всем хорошо при любом раскладе (с учетом того, что мы все же все разработчики и какой-никакой код писать да должны). Хочешь меньше взаимодействия с другими людьми - общайся только по рабочим вопросам, хочешь больше - найди единомышленника и обменивайся мыслями с ним в течение дня. А если еще задача хорошо проработана да спроектирована - то вообще думать можно минимально, остается просто сидеть да работать.
Но только в голове стоит держать, что в этой картине "код ревью" - это не просто проглядеть нейминг да соблюдение архитектурных принципов по диагонали за 5 минут, затрекав полчаса, параллельно попить чаек и сгоняв на перекур)
плюсую, как вариант, выглядит годным 👍
простите, не оправдали ожиданий)
Добрый день! Так точно, все правильно поняли, пока только во время активной разработки используется. Но, в целом, ничего не мешает попробовать внедрить решение на этап тестирования, только тут надо будет обдумать и посоветоваться с QA-командой. Опыт написания автотестов у нас имеется, но пишутся они все же на реальное приложение - помимо проверки логики модуля можно попутно проверить и его интеграцию. Если говорить о ручном тестировании и проведении смоука - тут опять же важно понять, не отвалилась ли интеграция той или иной проверяемой фичи.
Возможное применение, которое я вижу - проведение тестов большой фичи со сложной логикой, которая, к тому же, располагается в труднодоступном месте, в таком вспомогательном приложении во время ручных/автотестов (чтоб время на перемещение между экранами не терять) + отдельное проведение интеграционных тестов на реальном приложении.
В качестве примера, из последнего, когда такой прием применял — экран карты неких объектов. В одном кейсе экран представлял собой просто View с минимум логики, где даже запрос не выполнялся, в другом — самостоятельный полноценный экран -> View одна и она переиспользуется, просто к ней подсовывается в каждом случае свой Presenter
Но отдельно замечу, что хотя подход с таким скриптом сам по себе решает одну определенную проблему, которую и можно было бы избежать в принципе, но сам опыт оказался полезным. Приятно было отвлечься и попробовать себя в несколько иной роли, кроме iOS-разработчика, плюс найти подход и выявить проблемы с запуском самописных скриптов)
Только один вопрос есть. Где-то полгода назад на онбординге один разработчик как-то пытался реализовать такой подход, но завяз с тем, что разные бандлы => разные проекты в firebase => разные .plist файлы для конфигурации аналитики. И реализовать корректное их подтягивание в зависимости от конфигурации у него с ходу не получилось. Может быть у вас есть какие-то рецепты для таких случаев?