Так цель работодателя возложить все функции на работника. Зачем ему общаться с ИИ когда можно нанять работника который будет общаться с ИИ?
Скорее всё пойдёт по пути того что задачи станут менее формализованными и более неопределёнными. Не добавь "кнопку на экран", а более в сторону "сделай что бы всем было хорошо".
Да в целом я это и хотел сказать, вы все правильно поняли.
Насчет 20-30 тыс. строк кода как будто бы довольно странное утверждение, учитывая, что проекты бывают совершенно разные.
Да приложения бывают разные, но рефакторинг и повторное использования кода позволяют удерживать кодовую базу в разумных приделах. Что-то вроде эффекта сжатия - когда архивируется небольшой кусок текста, например, LZW алгоритмом, то эффективность сжатия низкая, а когда кусок текста большой - эффективность растёт настолько что конечный размер архива практически перестаёт зависеть от объёма текста.
Вот даже картинка есть (LZW compression results-text length dependence):
Что-то подобное происходит и с кодовой базой за счёт повторного использования.
Конечно речь не про супераппы где могут быть объединены приложения совершенно разной природы, а когда функционал наращивается в конкретной доменной области.
Суммарно получилось 2072 часа рабочего времени Android-разработчиков и 843 часа рабочего времени iOS-разработчиков. Получается, что затраты на iOS часть составили всего 40% от затрат на общую и Android части!
Не понятно как вы сделали этот вывод. Предположим если без KMM у вас было 1000 на Android и 1000 часов на iOS, потом появился KMP и к этому коду добавился еще 1000 часов. То все равно выглядело бы так что на iOS ушло всего 50% времени разработки!
> По количеству строк кода тоже заметна польза. Android, common и iOS части приложения получились примерно равными по количеству строк. Получается из каждого приложения, Android и iOS, мы вынесли в общий модуль примерно половину их кода. А это уменьшение затрат на разработку на 33%!
Тот же аргумент. Процент iOS кода уменьшился только благодаря тому что Android кода стало больше.
Если я был должен Васе 100 рублей, потом занял у Пети 900 рублей это не значит что мой долг Васе сократился в 10 раз (со 100% до 10%).
Плюс подмечу, что по моему опыту, в проект на 20-30 тыс. строчек кода без учёта кода библиотек и т.д. можно упихнуть практически любой функционал. Так что если для поддержки основного кода требуется наличие такого количество iOS кода, то выглядит всё отнюдь не радужно.
Говорят Apple очень сильно ограничивает возможности PWA: - PWAs cannot access native iOS components like ARKit, Bluetooth, iMessage, FaceTime, etc. - Unfortunately, iOS limits the ability of service workers to provide these services to PWAs. - iOS drastically limits PWAs’ access to phone storage. As a result, PWAs cannot use as much storage as they want. Currently, PWAs can access up to 50 MB of storage. This is a minuscule amount of storage.
Новая модель работы с многопоточкой async/await абстрагирует разработчика от понятий потоков и очередей. Новая модель включает в себя Cooperative Thread Pull, который инкапсулирует всю логику по работе с потоками и очередями.
Стейт-машина – это полезный паттерн, который поможет вам запрограммировать множество состояний и переходов между ними когда это необходимо.
Тут нужно оговорить что сам паттерн State в статье не рассмотрен. Потому что никакого отношения к enum'ам он не имеет. Наоборот, это уход от enum'ов к ООП.
Паттерн state на Swift обычно реализуют примерно так: 1. Формируется список методов которые описывают внешние действия protocol State { func startCall() -> State func endCall() -> State }
2. Реализуется возможные состояния: class InactiveState: State { func startCall() -> State { print("Call is active") return StartedState() }
func endCall() -> State { print("Error: can't end the call, call is already inactive") return self } }
class ActiveState: State { func startCall() -> State { print("Error: can't start the call, call is already active") return self }
func endCall() -> State { print("Call is active") return InactiveState() } }
3. Далее класс state используется в следующем виде: class StateUser { private var state: State = InitialState()
В англосаксонских странах важно не биологическое родство, а законное. А т.к. снохачество это связь между father in law и daughter in law, то это классифицируется как инцест. И в некоторых штатах может быть срок за это, довольно приличный.
В 4е? В США это миниммум 1 млн. долларов за первую версию которую выдадут через год, а потом еще столько же за развитие и поддержку. Причём со временем ценник будет только расти, т.к. клиент зависим становится.
Так цель работодателя возложить все функции на работника. Зачем ему общаться с ИИ когда можно нанять работника который будет общаться с ИИ?
Скорее всё пойдёт по пути того что задачи станут менее формализованными и более неопределёнными. Не добавь "кнопку на экран", а более в сторону "сделай что бы всем было хорошо".
Да в целом я это и хотел сказать, вы все правильно поняли.
Да приложения бывают разные, но рефакторинг и повторное использования кода позволяют удерживать кодовую базу в разумных приделах. Что-то вроде эффекта сжатия - когда архивируется небольшой кусок текста, например, LZW алгоритмом, то эффективность сжатия низкая, а когда кусок текста большой - эффективность растёт настолько что конечный размер архива практически перестаёт зависеть от объёма текста.
Вот даже картинка есть (LZW compression results-text length dependence):
Что-то подобное происходит и с кодовой базой за счёт повторного использования.
Конечно речь не про супераппы где могут быть объединены приложения совершенно разной природы, а когда функционал наращивается в конкретной доменной области.
Не понятно как вы сделали этот вывод. Предположим если без KMM у вас было 1000 на Android и 1000 часов на iOS, потом появился KMP и к этому коду добавился еще 1000 часов. То все равно выглядело бы так что на iOS ушло всего 50% времени разработки!
> По количеству строк кода тоже заметна польза. Android, common и iOS части приложения получились примерно равными по количеству строк. Получается из каждого приложения, Android и iOS, мы вынесли в общий модуль примерно половину их кода. А это уменьшение затрат на разработку на 33%!
Тот же аргумент. Процент iOS кода уменьшился только благодаря тому что Android кода стало больше.
Если я был должен Васе 100 рублей, потом занял у Пети 900 рублей это не значит что мой долг Васе сократился в 10 раз (со 100% до 10%).
Плюс подмечу, что по моему опыту, в проект на 20-30 тыс. строчек кода без учёта кода библиотек и т.д. можно упихнуть практически любой функционал. Так что если для поддержки основного кода требуется наличие такого количество iOS кода, то выглядит всё отнюдь не радужно.
Говорят Apple очень сильно ограничивает возможности PWA:
- PWAs cannot access native iOS components like ARKit, Bluetooth, iMessage, FaceTime, etc.
- Unfortunately, iOS limits the ability of service workers to provide these services to PWAs.
- iOS drastically limits PWAs’ access to phone storage. As a result, PWAs cannot use as much storage as they want. Currently, PWAs can access up to 50 MB of storage. This is a minuscule amount of storage.
https://www.koombea.com/blog/progressive-web-apps-for-ios
Cooperative Thread Pool, паттерн такой https://en.wikipedia.org/wiki/Thread_pool
Тут нужно оговорить что сам паттерн State в статье не рассмотрен. Потому что никакого отношения к enum'ам он не имеет. Наоборот, это уход от enum'ов к ООП.
Паттерн state на Swift обычно реализуют примерно так:
1. Формируется список методов которые описывают внешние действия
protocol State {
func startCall() -> State
func endCall() -> State
}
2. Реализуется возможные состояния:
class InactiveState: State {
func startCall() -> State {
print("Call is active")
return StartedState()
}
func endCall() -> State {
print("Error: can't end the call, call is already inactive")
return self
}
}
class ActiveState: State {
func startCall() -> State {
print("Error: can't start the call, call is already active")
return self
}
func endCall() -> State {print("Call is active")
return InactiveState()
}
}
3. Далее класс state используется в следующем виде:
class StateUser {
private var state: State = InitialState()
func makeCall() {
self.state = state.startCall()
self.state = state.endCall()
}
}
В чем плюсы паттерна:
Количество состояний не ограниченно - можно добавлять/убирать новые не меняя код у пользователя - если количество действий не меняется.
Обработка конкретного состояния ограничено конкретным классов
Список воздействия и состояния развязаны. Список воздействий определяются списком методов State'а, а список состояний - списком классов.
В англосаксонских странах важно не биологическое родство, а законное. А т.к. снохачество это связь между father in law и daughter in law, то это классифицируется как инцест. И в некоторых штатах может быть срок за это, довольно приличный.
В 4е? В США это миниммум 1 млн. долларов за первую версию которую выдадут через год, а потом еще столько же за развитие и поддержку. Причём со временем ценник будет только расти, т.к. клиент зависим становится.