По шкале можно двигаться. Вернее, по ней в любом случае будешь двигаться. И если стремиться к комфорту, то это конечно проще здесь и сейчас, но со временем станет проблемой. Потому что прийдется взаимодействовать с людьми, независимо от своего желания и страха. А можно заниматься "закаливанием". Да, в моменте неприятно, зато на дистанции проще.
Я избрал второй путь, и да, как результат, мне сильно проще стало общаться и спорить в интернетах чем раньше. И статья именно об этом, что по шкале можно двигаться не только в сторону бородатого отшельника.
Можно зайти с другой стороны: мы не на необитаемом острове. И рано или поздно прийдет момент в стиле "пришло время поверки счетчика: найдите человека с сертификатом, пригласите его домой, получите акт, акт привезите в водоканал". И чтобы эта бытовуха не стала непреодолимым стрессом нужно периодически свои страхи бороть.
Социофоб шел к этому не один год, даже не одно десятилетие. Собственно моя мысль именно в этом: если вылезать из раковины, то потихоньку привыкаешь и адаптируешься. И многие активности, которые раньше пугали, становятся вполне сносными.
Просто что я вижу в перспективе: при развитии апи функция с пачкой параметров не удобна (не расширяема), а значит уже закладывается камень в фундамент будущего рефакторинга если же передавать словарь, то остается открытым вопрос, кто и где будет валидировать что в словаре. В случае с моделью это частично может сделать компилятор + магические строки в качестве ключей словаря
В общем, словарь хорошо если нужно делать быстро, но в перспективе вижу возможные неприятности.
Не совсем понятно в чем состоит "ненужность" моделей, тем более что их можно передавать аргументом в функцию (имхо один CreateAccountBody смотрится проще и понятней, чем перечень из 5 параметров)
Статья отличная и обязательна к изучению независимо от уровня. Но есть на мой взгляд одна тонкость — архитектура должна быть гибкой только там, где это необходимо. Если человекомеч пишется один раз и этот код не меняется годами — то это корректное решение, и оверхедить его нет смысла.
Идея понятна, ее я одобряю.
Не понятен именно подход делать запрос прямо с экрана.
Ок, запросы вы вынесли, но ведь UI может еще строится на основании БД, UserDefaults и т.д.
Не лучше ли вынести все это в модель, и мокать ее (как вариант на основании все того же тестового сервера). А так как модель связана по интерфейсу, то подменять его реализацию можно все тем же одним флагом
Статья конечно интересная, но вызывает вопрос подход:
На каждый экран приходится как минимум 1 запрос (а часто больше).
Если нужно написать UI, а серверная часть еще не готова, не лучше ли сделать цепочку
View-Protocol-Service
После чего просто сделать фейковую реализацию протокола для сервиса. При желании еще тестов добавить с этой фейковой реализацией.
Следующим этапом к слову можно сделать
Service-Protocol-Entity(Network data source)
Так же с фейковой реализацией и тестами.
В том то и дело что будет. Человек один раз уже ошибся, а ему вместо решения предлагают сделать ошибку в 2 раза больше. И при изменениях одного файла придется менять второй. Или не прийдется. В общем радость от поддержки в полной мере.
На претензию что такого не будет: будет.
Все в курсе про объекты-Боги, о SOLID. Но перегруженные AppDelegate все равно создаются.
Обычно класс AppDelegate выполняет много работы при запуске приложения. Он может настроить окно, построить базовую структуру пользовательского интерфейса приложения, выполнить регистрацию для получения уведомлений, настроить базу данных и даже иногда выполнять вызовы API для определенной службы серверного приложения
Возникло пару вопросов:
1. Как часто вы начинаете проект, если реально понадобился шаблон?
2. Неужели проекты настолько однотипны, что нужен шаблон? Это касается в частности Podfile
Выглядит как абстракции ради абстракций. Статья с названием «Как избавить проект от лишних килограммов» содержит в минусах «резко возрастающее количество протоколов» и «Иногда код может выглядеть не таким понятным, как при использовании обычных подходов»
Сейчас бы судить людей по статье, ага.
По шкале можно двигаться. Вернее, по ней в любом случае будешь двигаться. И если стремиться к комфорту, то это конечно проще здесь и сейчас, но со временем станет проблемой. Потому что прийдется взаимодействовать с людьми, независимо от своего желания и страха. А можно заниматься "закаливанием". Да, в моменте неприятно, зато на дистанции проще.
Я избрал второй путь, и да, как результат, мне сильно проще стало общаться и спорить в интернетах чем раньше. И статья именно об этом, что по шкале можно двигаться не только в сторону бородатого отшельника.
Можно зайти с другой стороны: мы не на необитаемом острове. И рано или поздно прийдет момент в стиле "пришло время поверки счетчика: найдите человека с сертификатом, пригласите его домой, получите акт, акт привезите в водоканал". И чтобы эта бытовуха не стала непреодолимым стрессом нужно периодически свои страхи бороть.
Статья, в том числе, один из шажков адаптации)
Норма - понятие субъективное. В статье не просто так слово "социофобушек". Это не медицинский диагноз. Но даже с диагнозом можно работать над собой.
И если этого не делать - есть риск со временем получить кучу серьезных проблем.
Социофоб шел к этому не один год, даже не одно десятилетие.
Собственно моя мысль именно в этом: если вылезать из раковины, то потихоньку привыкаешь и адаптируешься. И многие активности, которые раньше пугали, становятся вполне сносными.
Зависит от самой позиции. Если сплошные созвоны - то да. Если хватает работы с кодом/архитектурой - то уже не все так однозначно
Главное чтобы не было: "У моих ровесников нормальные 50, а у меня какие-то неправильные")
Нормальность и здоровье могут и не пересекаться. Можно сказать что нормальность - вкусовщина.
Просто что я вижу в перспективе:
при развитии апи функция с пачкой параметров не удобна (не расширяема), а значит уже закладывается камень в фундамент будущего рефакторинга
если же передавать словарь, то остается открытым вопрос, кто и где будет валидировать что в словаре. В случае с моделью это частично может сделать компилятор
+ магические строки в качестве ключей словаря
В общем, словарь хорошо если нужно делать быстро, но в перспективе вижу возможные неприятности.
Не совсем понятно в чем состоит "ненужность" моделей, тем более что их можно передавать аргументом в функцию (имхо один CreateAccountBody смотрится проще и понятней, чем перечень из 5 параметров)
Не пробовали реально мокать сервис целиком, а не только сетевой слой?
Не понятен именно подход делать запрос прямо с экрана.
Ок, запросы вы вынесли, но ведь UI может еще строится на основании БД, UserDefaults и т.д.
Не лучше ли вынести все это в модель, и мокать ее (как вариант на основании все того же тестового сервера). А так как модель связана по интерфейсу, то подменять его реализацию можно все тем же одним флагом
Если нужно написать UI, а серверная часть еще не готова, не лучше ли сделать цепочку
View-Protocol-Service
После чего просто сделать фейковую реализацию протокола для сервиса. При желании еще тестов добавить с этой фейковой реализацией.
Следующим этапом к слову можно сделать
Service-Protocol-Entity(Network data source)
Так же с фейковой реализацией и тестами.
На претензию что такого не будет: будет.
Все в курсе про объекты-Боги, о SOLID. Но перегруженные AppDelegate все равно создаются.
1. Как часто вы начинаете проект, если реально понадобился шаблон?
2. Неужели проекты настолько однотипны, что нужен шаблон? Это касается в частности Podfile