И винят в этом скрам. Якобы при вотерфоле или канбане выгореть нельзя.
Я о том, что правильный скрам дает автономию команде в том числе и в планировании. Но бывают и карго культы, которые под видом скрама по факту просто устанавливают регулярные интервалы для удара кнутом: легкий удар каждый день (дейли) и хороший хлесткий удар в конце спринта.
Еще бывает конечно низкое чсв членов команды, что приводит к самобичеванию. В этом случае нужен мотивирующий наставник, сейчас для этого есть отдельная роль - аджайл коач. Я работал с несколькими и могу сказать, что не все аджайл коачи одинаково полезны.
Грамотный менеджмент закладывает риски и мыслит стратегически в том числе и о человеческих ресурсах. Дедлайны ставят либо наивные, либо ушлые, чтобы красиво отчитаться и продвинуться по карьерной лестнице ценой выгорания команды исполнителей.
Из моего опыта 50%-70% спринтов в итоге "проваливаются" по различным причинам: неучтенная сложность, внешние зависимости, болезни и т.п. Но на самом деле это неважно. Важен сам факт пересмотра целей в конце каждого спринта. Если есть дедлайн, то можно пересмотреть подходы, которые не сработали, поискать возможности срезать углы или предупредить менеджмент о том, что в сроки не уложимся заранее, а не в последнюю неделю. Настоящие дедлайны случаются раз в пару лет (например требования законодательства), все остальные - выдумки эффективных менеджеров, с которыми каши не сваришь при любом процессе.
Зависит от компании. Аджайл - про то что можно сделать здесь и сейчас. В стартапе не проблема решить подобный вопрос в течении дней-недель, в то время как в энтерпрайзе на согласование могут уйти многие месяцы, даже если все команды живут аджайлом, так как бюджеты по отделам на текущий год уже спланированы.
В итоге через некоторое время многие команды плюют на Agile и работают на его подобии адаптированной к реалиям.
Многие аджайл коачи топят за самоорганизацию, в том числе и в выборе процессов внутри команды, скрам, канбан, скрамбан и т.п. Но это не всегда сочетается с видением менеджмента, который может хотеть, чтоб все команды гребли в такт. Т.е. в идеале от аджайла не уходят, если целью остается работающий продукт и работа над тем, что действительно важно в данный момент.
А написан он так "криво" потому что спринты, неправильная оценка трудозтарат, внезапные срочные задачи и дедлайны заказчиков взятые с потолка, т.к. при заключения договора не было все четко зафиксировано, плохой кодревью и т.п.
Дедлайны - это уже, по определению, не аджайл, так же как заключение fixed-price договоров. Спринты - всего лишь механизм для переоценки приоритетов. Если руководство не понимает, зачем им аджайл, то он не полетит, и недовольными останутся все.
"Фреймворк" не в смысле подключаемой библиотеки, а в смысле организации кода.
Вайпер всего лишь позволяет не ломать голову над названиями разных сущностей из разных слоев.
Тут вообще спорно, что VIPER про разные слои. По идее так должно быть, но по факту, все, кроме Entity относиться к UI слою (из тех примеров что я видел), так как Interactor обычно тесно связан с логикой UI.
Кстати, почему-то авторы VIPER совершенно забыли про Controller, в CA именно он должен вызывать Interactor, Presenter работает в другую сторону. И Presenter и Controller являются адаптерами между UI и Interactor.
VIPER есть ни что иное, как криво преподнесенный MVP, который Боб Мартин прямо приводит в качестве примера, внезапно, Clean Architecture. А что такое MVC в iOS? Да то же самое! Так как там View так же ничего не знает о Model. Model в MVP - делает то же самое, что и Interactor в Viper. Все что добавляет VIPER - интерфейсы, которые и так должны быть, если вы следуете DI принципу. Clean Architecture, чистая в первую очередь от фреймворков.
Если VIPER не понимать буквально, он просто перестанет существовать :).
Кстати т.н. Clean Architecture - по сути всего лишь про абстракции и создание границ между слоями, что есть ни что иное как DI из SOLID. То есть про возможность менять части системы по отдельности. Ни о каком фреймворке там речи не шло.
VIPER же похож на какой-то карго культ, особенно в попытке натянуть его на SwiftUI.
Еще часто замечаю, что утилитные методы любят прятать в extensions к какому либо типу.
В Swift есть пространства имен на основе типов, их можно вкладывать один в другой, за исключением протоколов. Чтобы не засорять глобальное пространство имен, все типы-сателиты лучше определять вложенными в основной тип.
Полностью согласен. Я имел в виду, что не скрам сам по себе создает условия для выгорания.
И винят в этом скрам. Якобы при вотерфоле или канбане выгореть нельзя.
Я о том, что правильный скрам дает автономию команде в том числе и в планировании. Но бывают и карго культы, которые под видом скрама по факту просто устанавливают регулярные интервалы для удара кнутом: легкий удар каждый день (дейли) и хороший хлесткий удар в конце спринта.
Еще бывает конечно низкое чсв членов команды, что приводит к самобичеванию. В этом случае нужен мотивирующий наставник, сейчас для этого есть отдельная роль - аджайл коач. Я работал с несколькими и могу сказать, что не все аджайл коачи одинаково полезны.
Да, но скрам тут абсолютно не причем.
Грамотный менеджмент закладывает риски и мыслит стратегически в том числе и о человеческих ресурсах. Дедлайны ставят либо наивные, либо ушлые, чтобы красиво отчитаться и продвинуться по карьерной лестнице ценой выгорания команды исполнителей.
В марафоне нет остановок. В скраме они предусмотрены в виде церемоний.
Из моего опыта 50%-70% спринтов в итоге "проваливаются" по различным причинам: неучтенная сложность, внешние зависимости, болезни и т.п. Но на самом деле это неважно. Важен сам факт пересмотра целей в конце каждого спринта. Если есть дедлайн, то можно пересмотреть подходы, которые не сработали, поискать возможности срезать углы или предупредить менеджмент о том, что в сроки не уложимся заранее, а не в последнюю неделю.
Настоящие дедлайны случаются раз в пару лет (например требования законодательства), все остальные - выдумки эффективных менеджеров, с которыми каши не сваришь при любом процессе.
В конце каждого спринта в SCRUM предусмотрены ретроспектива и планирование, как раз для того, чтобы остановиться и подумать.
Если отбросить церемонии, то SCRUM - это всего лишь планирование на короткие промежутки времени, пара недель вместо 3-х месяцев.
Дедлайны не имеют прямого отношения к SCRUM. Менеджмент решает, делать конец спринта дедлайном или нет.
Функция "release" переводиться как "освободить", и уменьшает счетчик ссылок на 1. Так что формулировка вполне корректная.
Зависит от компании. Аджайл - про то что можно сделать здесь и сейчас. В стартапе не проблема решить подобный вопрос в течении дней-недель, в то время как в энтерпрайзе на согласование могут уйти многие месяцы, даже если все команды живут аджайлом, так как бюджеты по отделам на текущий год уже спланированы.
Многие аджайл коачи топят за самоорганизацию, в том числе и в выборе процессов внутри команды, скрам, канбан, скрамбан и т.п. Но это не всегда сочетается с видением менеджмента, который может хотеть, чтоб все команды гребли в такт. Т.е. в идеале от аджайла не уходят, если целью остается работающий продукт и работа над тем, что действительно важно в данный момент.
Дедлайны - это уже, по определению, не аджайл, так же как заключение fixed-price договоров. Спринты - всего лишь механизм для переоценки приоритетов.
Если руководство не понимает, зачем им аджайл, то он не полетит, и недовольными останутся все.
"Фреймворк" не в смысле подключаемой библиотеки, а в смысле организации кода.
Тут вообще спорно, что VIPER про разные слои. По идее так должно быть, но по факту, все, кроме Entity относиться к UI слою (из тех примеров что я видел), так как Interactor обычно тесно связан с логикой UI.
Кстати, почему-то авторы VIPER совершенно забыли про Controller, в CA именно он должен вызывать Interactor, Presenter работает в другую сторону. И Presenter и Controller являются адаптерами между UI и Interactor.
VIPER есть ни что иное, как криво преподнесенный MVP, который Боб Мартин прямо приводит в качестве примера, внезапно, Clean Architecture. А что такое MVC в iOS? Да то же самое! Так как там View так же ничего не знает о Model. Model в MVP - делает то же самое, что и Interactor в Viper.
Все что добавляет VIPER - интерфейсы, которые и так должны быть, если вы следуете DI принципу. Clean Architecture, чистая в первую очередь от фреймворков.
Если VIPER не понимать буквально, он просто перестанет существовать :).
Кстати т.н. Clean Architecture - по сути всего лишь про абстракции и создание границ между слоями, что есть ни что иное как DI из SOLID. То есть про возможность менять части системы по отдельности. Ни о каком фреймворке там речи не шло.
VIPER же похож на какой-то карго культ, особенно в попытке натянуть его на SwiftUI.
Моки никак нельзя назвать переиспользованием, потому что это код тестов, а не приложения.
Да, редактор в новом дизайне хабра довольно странный. Должно быть:
Тогда нужно бы упомянуть, для чего нам классы-значения в принципе нужны в повседневной жизни и в чем их преимущество перед структурами.
Для этого в iOS SDK вроде бы все есть из коробки, и система сама все развернет, если верстка не привязана к left/right, а использует leading/trailing.
Впервые слышу о проблемах анимации на iOS. Если не загружать главный поток, то все всегда плавно. Может это особенность именно SwiftUI?
В Swift есть пространства имен на основе типов, их можно вкладывать один в другой, за исключением протоколов. Чтобы не засорять глобальное пространство имен, все типы-сателиты лучше определять вложенными в основной тип.
Верно, для 90% задач протоколов с дефолтной имплементацией должно быть достаточно.
Иногда нужно создать базовый класс на основе библиотечного (например
UIViewController) и тут мой пример сtypealiasможет пригодиться.Похоже автор не разобрался до конца в Swift и пытается применить паттерны из C++, при том, что последний с трудом можно назвать ООП-языком.
Для этих целей в Swift принято использовать enum'ы без case'ов, так как они не имеют инициализатора по-умолчанию и не позволяют наследование.