Можно и нужно. Ведь в работе с кодом на этом языке и заключается основная часть работы.
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался. Но вы ругаете платформу без предложения разумной альтернативы для данной предметной области, из которой в итоге вообще ушли. Достаточно странно при таких вводных давать советы о том какие технологии для этой предметной области необходимо использовать.
Так там типов и нет толком. Я вот как раз немало людей встречал кто, как и я, ушел из-за языка.
И куда ушли в итоге? Когда я начинал работать с платформой 1С:Предприятие 7.7 в ней не было вообще ничего, ни функциональности платформы, ни функциональности типовых решений. Было огромное количество неофициальных библиотек, которые позволяли заставить все это как-то работать. Рядом была Axapta 3.0, которая была лишена большинства из этих недостатков и многие переходили на нее. Но потом вышла платформа 1С:Предприятие 8 и после выхода 1С:УПП поток желающих перейти резко остановился, а после выходя 1С:ERP пошел обратный процесс.
А это вообще странное заявление. Может для тех кто только внедрением типовых занимается и их доработкой оно и оправдано
Это оправдано прежде всего с точки зрения клиента. Ему вообще без разницы какой там язык и какая платформа. Ему нужно получить определенную функциональность за определенную стоимость с определенной стоимостью владения.
Вы мне сейчас пытаетесь доказать что то что я при работе с 1с ненавидел и от чего ощущал дискомфорт - это плюсы, а не минусы
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
Если это такие вот плюсы, чего же во всех современных языках перешли на нормальное управление зависимостями вместо прямого включения и прочих вариантов?
Я не говорил что это плюс, это особенность и чтобы понять хорошо это или плохо нужна для сравнения другая система с сопоставимой по размеру кодовой базой и построенная на других архитектурных принципах. Но такой нет, есть либо явно недотягивающие по функциональности, типа Odoo или iDempiere, либо явно недотягивающие по удобству SAP, OEBS. Отдельным особняком всегда стояла Axapta, но там уже много лет такой застой, что она ко второй группе присоединилась
На 1с тоже пишут, но страдают. Есть у меня опыт участия в разработке коробочных решений, писать и поддерживать сотни тысяч строк кода коробки 1сной это боль без типов.
Не смотря на то, что для ряда проектов (в том числе коробочного решения) использую EDT никогда не обращал внимание на типы. И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
Не знаю что вы там подразумевали. typescript это вполне себе отдельный язык от microsoft которой в js транспилируется.
В js много чего транслируется, в том числе 1С. Но я никогда не воспринимал TypeScript как отдельный язык, скорее как надстройна над JavaScript. Но не буду утверждать, т.к. ни строчки кода на нем никогда не написал.
УГ именно язык на котором нужно для них писать.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие. Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C. По-отдельности они никому не интересны. Кроме того, 1С генерирует байт-код обычной стековой машины, что теоретически позволяет скомпилировать в него код "более современного" языка программирования. Но я о таких попытках не слышал, возможно из-за того что никому это особо не интересно.
Ну и где десятки тысяч библиотек со всякими служебными функциями для 1с вроде аналогов gson, кастомных логгеров, какой нибудь кастомной работы с датами и временем, парсингом html/xml нестандартным?
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
Так оно нужно. Но оно не должно торчать в тот код который этим будет пользоваться. А предоставляться только через абстракции
Я уже писал ранее, что на проекте внедрения все ваши идеально построенные абстракции могут накрыться медным тазом из-за специфических требований клиента. Система изначально создана для внесения изменений в любую часть функциональности и лишние уровни абстракции тут только вредят. Хотя, например, я бы полностью поддержал появление в платформе интерфейсов для модулей.
Насчет python тут точно не скажу как там в коммьюнити к этому относятся, на мой взгляд это язык либо для датасатанистов, у них вариантов тупо нет других толком, либо для того чтобы наколеночные поделия клепать, если писать без типов
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
Но вот с typescript вы точно ошибаетесь, там без типов никто не пишет насколько мне известно
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Но что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
В теории и на брейнфаке можно код писать. Мне как программисту важно чтобы на языке было писать просто и приятно. ... А если мне нужно страдать от неудобства работы с языком - значит язык уг.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы. В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
Соглашусь по поводу 1С:PDM, то что это решение получило сертификат 1С:Совместимо является дискредитацией самой системы сертификации. Но тут дело наверное в том, что отсутствуют аналоги, а они отсутствуют в том числе потому, что все толковые специалисты заняты на проектах внедрения, выхлоп от которых гораздо больше. А тут нужно заморозить огромное количество денег с непонятной перспективой окупить вложения. 1С:УПП хороший продукт для своего времени, единственным недостатком которого являются обычные формы Искренне не понимаю, какие могут быть претензии к 1С:Документооборот, т.к. продукт изначально разрабатывался на управляемых формах
В теории да, на практике не делают этого. Причин много, какие-то я возможно себе надумываю, какие-то реальные, но важно то что выходит на практике
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт. Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Пространство имен в случае 1с общее
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
модуль может быть подключен для использования в других модулях и попадать в их пространство имен, а может быть не подключен, и тогда не засоряет его
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
Плюс в 1с нет аналога package private. Потому внутренности модуля на все пространство имен торчат.
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
При этом даже в python завезли type hinting. А в случае веба на крупных проектах переходят на typescript с js.
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
По сути в python два режима сейчас, полностью динамическая типизация, которая подходит для скриптов и мелких проектов, и режим статической типизации, который подходит для крупных проектов
Впервые слышу об этом. Вижу кучу популярных публичных библиотек без всяких типов и возбуждаются от отсутствия типов только адепты языков со статической типизацией
Это пожалуй было одной из наибольших болей для меня. В упор не понимаю почему замыканий или просто хотя бы ссылок на функции не добавить
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
Отсутствие системы управления зависимостями Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода" Отсюда же идет отсутствие модульности Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии. Отсутствие ООП / Отсутствие лямбд/замыканий Отчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи Динамическая типизация Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C. Печальная поддержка плагинов Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Необходимо учитывать следующие моменты разработки платформы и типовых решений:
В платформу добавляется только то, что жизненно необходимо, т.к. реализовывать это приходится для нескольких ОС/СУБД/клиентов
Типовые решения содержат огромное количество функциональности, каждую часть которой разрабатывают разные команды разработчиков. При таком подходе создание сложных многоуровневых иерархий классов если и возможно, то будет скорее вредить. Так как на любом более крупном проекте внедрения эта функциональность обрастет дополнительными требованиями от клиентов. А требования конечного пользователя могут погубить самую лучшую архитектуру.
Ориентированность на язык запросов. Началось это с момента разработки ERP, а когда у вас большая часть функциональности связана с построением запросов иерархия классов тоже не пригодится
Какого экспириенса разработчику 1с по-вашему не хватает? Разработчик прежде всего выбирает предметную область и затем фреймворк для наиболее эффективного решения задач. Мне нравится предметная область - системы учета и 1С вполне справляется с ролью наиболее эффективного фреймворка. В более менее крупном франче разработчик никогда не будет общаться с бизнесом, только с аналитиками (как франча, так и клиента) и разработчиками клиента, которые часто общаются с бизнесом. Что касается используемых технологий, то помимо 1С приходится использовать:
C++ для написания библиотек для работы с отсутствующей в 1С функциональностью, причем мультиплатформенный, как минимум для Windows и Linux, но иногда требуется включать и MacOS
Python - обработка текстов, парсинг сайтов, несложные сайты на Django и HTTP сервисы
bash - анализ файлов технологического журнала, скрипты devops
WinCMD - локальные скрипты автоматизации
T-SQL и PL/pgSQL - оптимизация запросов к СУБД
COM - манипуляция с документами Microsoft Office
Web/HTTP-сервисы, брокеры сообщений и мессенджеры, работа с XML и JSON
Сначала вы пишите, что на сервер клиента нельзя устанавливать сторонний софт, но при этом устанавливаете и запускаете свои приложения
Сколько часов, которые вы потратили на расследование оплатил клиент, сколько оплатила вам компания, а сколько за свой счет. Я веду для себя список проблем для расследования, но никто оплачивать это не хочет, а свое свободное время ограничено.
Проблема действительно нетривиальная, т.к. большинство админов забывают, что VCredist должны обновляться как и остальные компоненты. Но как можно было пропустить разные версии библиотеки у клиента и у вас - ума не приложу. Очень похоже на то, что вы просто не знали, что платформа использует общую библиотеку, а не из каталога приложения
Глупо все-таки завязываться на онлайн сервисы. Должна быть локальная инфраструктура, а онлайн-сервисы использоваться только как дополнение, но лучше вообще без них.
Обычно начинающим разработчикам дают несложные задачи, которые они делают по всем правилам и которые после ревью попадают в репозиторий. Если бы мне, когда я был начинающим разработчиком, предложили бы исправлять чужое г%#но, когда его автор сидит рядом и производит новое, я бы ушёл оттуда немедленно. Видимо есть какая-то другая причина, по которой стажёра у вас работают. Например любовь к мирному атому
То есть опытные разработчики делают ошибки, а неопытные должны за ними исправлять? Очень странное решение. Вряд ли молодые разработчики заходят работать в такой "команде"
Не вижу в подходе iOS никакой разницы по сравнению с Android, разве что модифицированные приложения создать сложне. В Android по умолчанию установка приложений из файлов требует подтверждения с предупреждением, а на телефонах детей с помощью Family Link может быть вообще закрыта
Если у вас 2 apk файла, при этом один скачан с сайта сбербанка и подписан их ключом, а второй модифицирован и подписан сгенерированным ключом, то для андроида они одинаково небезопасно и требуют подтверждения при установке. Как с этим обстоит дело в iOS её в курсе.
Оно будет подписано сторонним сертификатом. Автор написал, что для iOS такое тоже возможно, только сертификат нужен выпущенный компанией Apple, а не сгенерированный самостоятельно.
Тем не менее такая возможность есть, и мне очень пригождалось несколько раз. Обычные пользователи могут обратиться к знакомым IT-шникам или неоффициальным сервисам. Можно ли то же самое сделать с iOS?
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался. Но вы ругаете платформу без предложения разумной альтернативы для данной предметной области, из которой в итоге вообще ушли. Достаточно странно при таких вводных давать советы о том какие технологии для этой предметной области необходимо использовать.
И куда ушли в итоге? Когда я начинал работать с платформой 1С:Предприятие 7.7 в ней не было вообще ничего, ни функциональности платформы, ни функциональности типовых решений. Было огромное количество неофициальных библиотек, которые позволяли заставить все это как-то работать. Рядом была Axapta 3.0, которая была лишена большинства из этих недостатков и многие переходили на нее. Но потом вышла платформа 1С:Предприятие 8 и после выхода 1С:УПП поток желающих перейти резко остановился, а после выходя 1С:ERP пошел обратный процесс.
Это оправдано прежде всего с точки зрения клиента. Ему вообще без разницы какой там язык и какая платформа. Ему нужно получить определенную функциональность за определенную стоимость с определенной стоимостью владения.
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
Я не говорил что это плюс, это особенность и чтобы понять хорошо это или плохо нужна для сравнения другая система с сопоставимой по размеру кодовой базой и построенная на других архитектурных принципах. Но такой нет, есть либо явно недотягивающие по функциональности, типа Odoo или iDempiere, либо явно недотягивающие по удобству SAP, OEBS. Отдельным особняком всегда стояла Axapta, но там уже много лет такой застой, что она ко второй группе присоединилась
Не смотря на то, что для ряда проектов (в том числе коробочного решения) использую EDT никогда не обращал внимание на типы. И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
В js много чего транслируется, в том числе 1С. Но я никогда не воспринимал TypeScript как отдельный язык, скорее как надстройна над JavaScript. Но не буду утверждать, т.к. ни строчки кода на нем никогда не написал.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие. Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C. По-отдельности они никому не интересны. Кроме того, 1С генерирует байт-код обычной стековой машины, что теоретически позволяет скомпилировать в него код "более современного" языка программирования. Но я о таких попытках не слышал, возможно из-за того что никому это особо не интересно.
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
Я уже писал ранее, что на проекте внедрения все ваши идеально построенные абстракции могут накрыться медным тазом из-за специфических требований клиента. Система изначально создана для внесения изменений в любую часть функциональности и лишние уровни абстракции тут только вредят. Хотя, например, я бы полностью поддержал появление в платформе интерфейсов для модулей.
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Но что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы.
В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
Соглашусь по поводу 1С:PDM, то что это решение получило сертификат 1С:Совместимо является дискредитацией самой системы сертификации. Но тут дело наверное в том, что отсутствуют аналоги, а они отсутствуют в том числе потому, что все толковые специалисты заняты на проектах внедрения, выхлоп от которых гораздо больше. А тут нужно заморозить огромное количество денег с непонятной перспективой окупить вложения.
1С:УПП хороший продукт для своего времени, единственным недостатком которого являются обычные формы
Искренне не понимаю, какие могут быть претензии к 1С:Документооборот, т.к. продукт изначально разрабатывался на управляемых формах
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт.
Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
Впервые слышу об этом. Вижу кучу популярных публичных библиотек без всяких типов и возбуждаются от отсутствия типов только адепты языков со статической типизацией
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
Отсутствие системы управления зависимостями
Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода"
Отсюда же идет отсутствие модульности
Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии.
Отсутствие ООП / Отсутствие лямбд/замыканий
Отчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи
Динамическая типизация
Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C.
Печальная поддержка плагинов
Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Необходимо учитывать следующие моменты разработки платформы и типовых решений:
В платформу добавляется только то, что жизненно необходимо, т.к. реализовывать это приходится для нескольких ОС/СУБД/клиентов
Типовые решения содержат огромное количество функциональности, каждую часть которой разрабатывают разные команды разработчиков. При таком подходе создание сложных многоуровневых иерархий классов если и возможно, то будет скорее вредить. Так как на любом более крупном проекте внедрения эта функциональность обрастет дополнительными требованиями от клиентов. А требования конечного пользователя могут погубить самую лучшую архитектуру.
Ориентированность на язык запросов. Началось это с момента разработки ERP, а когда у вас большая часть функциональности связана с построением запросов иерархия классов тоже не пригодится
Какого экспириенса разработчику 1с по-вашему не хватает? Разработчик прежде всего выбирает предметную область и затем фреймворк для наиболее эффективного решения задач. Мне нравится предметная область - системы учета и 1С вполне справляется с ролью наиболее эффективного фреймворка.
В более менее крупном франче разработчик никогда не будет общаться с бизнесом, только с аналитиками (как франча, так и клиента) и разработчиками клиента, которые часто общаются с бизнесом. Что касается используемых технологий, то помимо 1С приходится использовать:
C++ для написания библиотек для работы с отсутствующей в 1С функциональностью, причем мультиплатформенный, как минимум для Windows и Linux, но иногда требуется включать и MacOS
Python - обработка текстов, парсинг сайтов, несложные сайты на Django и HTTP сервисы
bash - анализ файлов технологического журнала, скрипты devops
WinCMD - локальные скрипты автоматизации
T-SQL и PL/pgSQL - оптимизация запросов к СУБД
COM - манипуляция с документами Microsoft Office
Web/HTTP-сервисы, брокеры сообщений и мессенджеры, работа с XML и JSON
Сначала вы пишите, что на сервер клиента нельзя устанавливать сторонний софт, но при этом устанавливаете и запускаете свои приложения
Сколько часов, которые вы потратили на расследование оплатил клиент, сколько оплатила вам компания, а сколько за свой счет. Я веду для себя список проблем для расследования, но никто оплачивать это не хочет, а свое свободное время ограничено.
Проблема действительно нетривиальная, т.к. большинство админов забывают, что VCredist должны обновляться как и остальные компоненты. Но как можно было пропустить разные версии библиотеки у клиента и у вас - ума не приложу. Очень похоже на то, что вы просто не знали, что платформа использует общую библиотеку, а не из каталога приложения
Глупо все-таки завязываться на онлайн сервисы. Должна быть локальная инфраструктура, а онлайн-сервисы использоваться только как дополнение, но лучше вообще без них.
Обычно начинающим разработчикам дают несложные задачи, которые они делают по всем правилам и которые после ревью попадают в репозиторий. Если бы мне, когда я был начинающим разработчиком, предложили бы исправлять чужое г%#но, когда его автор сидит рядом и производит новое, я бы ушёл оттуда немедленно. Видимо есть какая-то другая причина, по которой стажёра у вас работают. Например любовь к мирному атому
То есть опытные разработчики делают ошибки, а неопытные должны за ними исправлять? Очень странное решение. Вряд ли молодые разработчики заходят работать в такой "команде"
Не вижу в подходе iOS никакой разницы по сравнению с Android, разве что модифицированные приложения создать сложне. В Android по умолчанию установка приложений из файлов требует подтверждения с предупреждением, а на телефонах детей с помощью Family Link может быть вообще закрыта
Если у вас 2 apk файла, при этом один скачан с сайта сбербанка и подписан их ключом, а второй модифицирован и подписан сгенерированным ключом, то для андроида они одинаково небезопасно и требуют подтверждения при установке. Как с этим обстоит дело в iOS её в курсе.
Оно будет подписано сторонним сертификатом. Автор написал, что для iOS такое тоже возможно, только сертификат нужен выпущенный компанией Apple, а не сгенерированный самостоятельно.
Ну давайте поучите ещё меня поиском пользоваться:
https://stackoverflow.com/questions/44618906/xcode-how-to-monitor-cpu-usage-for-any-running-third-party-app
https://stackoverflow.com/questions/12119407/use-xcode-to-instrument-profile-third-party-app
То что можно выполнять отладку своего приложения на реальном устройстве, я и без вас знаю.
Просьба уточнить по первым 2-м пунктам, речь идет о реальном устройстве или о симуляторе?
Я спросил про конкретные функции:
Просмотр системного журнала iOS
Мониторинг работы произвольного приложения
Декомпиляция, исправление и последующая сборка произвольной приложения
Тем не менее такая возможность есть, и мне очень пригождалось несколько раз. Обычные пользователи могут обратиться к знакомым IT-шникам или неоффициальным сервисам. Можно ли то же самое сделать с iOS?
Nubia X например
Для кого-то S24 Ultra провал, а кто-то наконец дождался плоского экрана с квадратными углами.