Переписывание приложения на другом языке

[mazzy]

Цитата:

Сообщение от AlexeyS

Любое приложение это набор сущностей, плюс связи между ними плюс язык.

хм... давайте я попробую в последний раз.

корпоративное приложение = любое приложение + корпоративные пользователи.
корпоративные пользователи != обычные пользователи.
корпоративные пользователи ~ много-много-много обычных пользователей.

поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений.

но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения".

Цитата:

Сообщение от mazzy

причем люди - не только программисты.
поэтому - нет, не дешевле

[sukhanchik]

Цитата:

Сообщение от belugin

https://habrahabr.ru/post/219651/i/


Наконец выходит первая публичная бета-версия Netscape 6.0. Версии 5.0 не существует. Предыдущий мажорный релиз — версия 4.0 — был выпущен почти три года назад. Три года — это невероятно большой срок в мире интернета. Все это время в Netscape сидели и беспомощно наблюдали за тем, как уменьшается их доля рынка.

Это немного подло с моей стороны критиковать их за столь долгое ожидание между релизами. Они ведь не специально это сделали, правда?

Неправда! Именно так они и сделали. И этим они совершили единственную самую большую стратегическую ошибку, которую когда-либо может сделать софтверная компания.

Они решили переписать код с нуля.

Максим (Белугин) - ничего не имею против тебя лично, но видеть это сообщение от сотрудника Microsoft - это очень прикольно, когда вспоминаешь, как MS "отрефакторил" AX 2012 и впоследующем - AX 7 / Dynamics 365 for Operations по сравнению даже с AX 2009 (не будем уж вспоминать эмоции по поводу появления ГАК в AX 2009 после AX 4). Я конечно понимаю, что лица, которые принимали решение - не сидят в российском офисе MS, но ... с обывательской т.з. российский офис и штаб квартира - один фиг - одна контора .

Прочитав статью - сразу вспомнилась история наследования таблиц в AX 2012 RTM и в AX 2012 R2 и далее ))).

Ну т.е. глобальная проблема развития АХ согласно этой статье состоит в том, что код решили переписать "с нуля". Были "ужасные" проблемы с тем, что ключевое поле - это строка, длиной 10, а то и 20 символов (это к примеру). Я уж не говорю, что многие клиенты (в частности, в РФ) явно страдали от невозможности вести в единой системе учет для каждой страны (за исключением Eastern Europe) раздельно ).

Ответы на эти вопросы понятны и не стоит на них отвечать. Просто статья уж больно врезалась в "больное место".

Еще раз повторяю - это не наезды личные - это ирония "в воздух". Т.о. прошу никого из сотрудников MS не воспринимать сие, как личную обиду. Заранее прошу прощения, если кого задел.

[ax_mct]

Цитата:

Сообщение от mazzy

хм... давайте я попробую в последний раз.

корпоративное приложение = любое приложение + корпоративные пользователи.
корпоративные пользователи != обычные пользователи.
корпоративные пользователи ~ много-много-много обычных пользователей.

поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений.

но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения".

Ага, то есть
+ много-много пользователей
+ обеспечение непрерывности
Я бы добавил зависимость от пользователей как специфику
+ они капризны
+ рядом с тобой

То есть в случае онлайн-магазина/продукта требования определяются без политики и множества участников, а в случае корпоративного ПО - прямое удовлетворение ожиданий конкретных пользователей.

То есть в случае корпоративного ПО не ты предлагаешь пользователям новый интерфейс, а они диктуют что они хотят.
На практике это означает что они хотят принципиально тот же UI чтобы им было как привычно.

Думаю что вот это вот связывание по рукам и ногам привычками пользователей - и есть особенность корпоративного ПО. А много и непрерывность - это не только там.

P.S. MS как небожитель - исключение, я беру ситуацию не вендора который далек от пользователей, а интегратора/IT на земле.

P.P.S. То есть миграция корпоративного ПО отличается необходимостью сохранения пользовательского опыта. В большей степени чем любой другой софт, так как корпоративное ПО - это рабочее место так как это есть для водителя автомобиля. И скорее всего "миграция" интерфейса важнее чем миграция кода.

Зы: MS "чтобы все выглядело как MS Office" для "того же пользовательского опыта" - не рассматриваю. Это опять неудачное исключение. Не дизайн, а расположение - вот что есть пользовательский опыт. Рычаг ручного тормоза в бардачке но выполненный в привычной форме того что мы привыкли держать в правой руке - это не тот же пользовательский опыт.

[ax_mct]

Цитата:

Сообщение от belugin

https://habrahabr.ru/post/219651/i/

этим они совершили единственную самую большую стратегическую ошибку, которую когда-либо может сделать софтверная компания.

Они решили переписать код с нуля.

Оттуда где-то перешел на
http://russian.joelonsoftware.com/Ar...theWaronA.html

Как Microsoft проиграла битву за API
Автор: Джоэл Сполски
Переводчик: Алексей Бушмин
10. 01. 2005

Лично у меня до сих пор не нашлось времени для глубокого изучения .NET, и мы до сих пор не портировали два проекта нашей компании Fog Creek с классического ASP и Visual Basic 6.0 на .NET, так как для нас нет прибыли от инвестиций. Нету. Это просто «Огонь и движение»: Microsoft понравится, если я перестану добавлять новые возможности в нашу систему по отслеживанию ошибок в программном обеспечении и в систему управления контентом, а вместо этого потрачу несколько месяцев, портируя их в другую среду разработки, что не принесет пользы ни одному клиенту, а следовательно не даст ни одной дополнительной продажи, а следовательно это пустая трата нескольких месяцев...

Статья достойна прочтения так как показывает начало конца.

А по теме:
Давно пора взять Open-source ERP и подняться с колен. Сила AX в людях и эти люди - вы!

[belugin]

Цитата:

Сообщение от sukhanchik

Ну т.е. глобальная проблема развития АХ согласно этой статье состоит в том, что код решили переписать "с нуля".

В каком смысле с нуля?

1) Давайте введем какую-то метрику, которая обозначит процент переписанного и посмотрим сколько по ней изменилось - мне кажется не так много но изменения сквозные.

2) Обратите внимание, что в статье говорится о переписывании ВСЕГО с нуля. Переписывание каких-то кусков там рекомендуется.

[AlexeyS]

Цитата:

Сообщение от mazzy

хм... давайте я попробую в последний раз.

корпоративное приложение = любое приложение + корпоративные пользователи.
корпоративные пользователи != обычные пользователи.
корпоративные пользователи ~ много-много-много обычных пользователей.

поэтому миграция массовых приложений (вконтакте, фейсбук, инстаграм, paypal и т.п.) похожа на миграцию корпоративных приложений.

но миграция корпоративных приложений отличается от миграции "любого приложения" именно наличием работающих пользователей. и не сводится к миграции "любого приложения".

ненене, давай разделять мед и пчел
корпоративные пользователи в отличие от обычных пользователей имеют влияние, хоть и опосредованное, на производителя ПО.

граничные случаи хороши наглядностью
вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема.
Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках.

[mazzy]

давайте.

Цитата:

Сообщение от AlexeyS

граничные случаи хороши наглядностью
вот представь такой вариант, люди работают на 3 аксапте 10 лет, а утром приходят и видят, что вместо иконки на рабочем столе у них ярлычок от браузера. они запускают его и РАБОТАЮТ КАК РАНЬШЕ, может быть только чуть-чуть отличаются шрифты и цветовая схема.
Язык поменялся? да. И теперь их клиент в браузере на HTML5, а в бэкэнде вообще непонятно что, то-ли PHP, то-ли NET и вообще NoSQL в облаках.

прекрасный граничный случай.
только и вы тоже где-то вне контекста. или уводите разговор в сторону.

если вам так угодно, пожалуйста, не меняя контекста, приведите полную цепочку рассуждений от вопроса, заданного в начале автором, через "написать с нуля", вплоть до вашего вывода.


было.

Цитата:

Сообщение от ax_mct

Дешевле написать с нуля улучшенную версию чем мигрировать.

я ответил: поэтому - нет, не дешевле

и мы все еще говорим:

Цитата:

Сообщение от NetBus

про миграцию корпоративных приложении с одного языка на другой?

[sukhanchik]

Цитата:

Сообщение от belugin

В каком смысле с нуля?

1) Давайте введем какую-то метрику, которая обозначит процент переписанного и посмотрим сколько по ней изменилось - мне кажется не так много но изменения сквозные.

2) Обратите внимание, что в статье говорится о переписывании ВСЕГО с нуля. Переписывание каких-то кусков там рекомендуется.

А ну если ключевое слово ВСЕГО, то я согласен - переписывалось кусками.
Но из того, чтобы я отнес к "ВСЕГО" - это:
1. Глобальная переделка интерфейса. Также, как Office 2003-2007. При этом в D365O тоже ведь интерфейс поменялся.
2. Нормализация таблиц.
Общий принцип, по которому были переписаны настройки ГК (LedgerDimension), справочники номенклатур (EcoRes*), ГАК (DirParty*; это конечно появилось еще в 2009-й версии).
Тут некорректно говорить, что изменение случилось именно в одной версии. Скорее это плавное изменение концепта. Но ... глобального концепта. Может это и не совсем подходит под статью - там все-таки упор был в рамках одной версии. Это изменение концепта ударило по схемам внедрения в рамках импорта данных. Тут конечно формально дело не в MS, но с т.з. покупателя - он особо-то не разделяет покупку лицензий от внедрения системы - т.е. ему нужен результат.

В D365O - из глобального "ВСЕГО" - это опять смена интерфейса и уход в Azure. Да, это не совсем разработка, но это опять глобальное изменение в системе, в результате которого опять заново нужно менять схему внедрения системы. И схему разработки.Т.е. с т.з. "доведения системы до эксплуатации" - процесс глобально меняется.
Мне кажется, что это подходит под ВСЕГО, нет? У автора статьи были конечно немного иные мысли в статье, но суть их как мне кажется в том, что как только мы чего-то (неважно чего - код, платформу, интерфейс, идеологию и т.д.) меняем глобально - то это как раз-таки та ситуация, в которой мы тормозимся на рынке перед конкурентами. Потому что пока все участники рынка (и в первую очередь специалисты по системе) адаптируются к новым изменениям - будет упущено время.

Я неправ?

[belugin]

Цитата:

Сообщение от sukhanchik

1. Глобальная переделка интерфейса. Также, как Office 2003-2007. При этом в D365O тоже ведь интерфейс поменялся.

2. Нормализация таблиц.
....
Мне кажется, что это подходит под ВСЕГО, нет?

Мне кажется вы смотрите только на то, что изменилось. Попробуйте также сравнить то, что осталось на месте.

Что больше diff(Ax2012, Ax3) или diff(Sap R/3, Ax3)

[ax_mct]

Цитата:

Originally Posted by ax_mct
Дешевле написать с нуля улучшенную версию чем мигрировать

Цитата:

Сообщение от mazzy

я ответил: поэтому - нет, не дешевле
и мы все еще говорим:
"про миграцию корпоративных приложении с одного языка на другой"

Те примеры которые у меня в голове это либо достаточно легкие приложения которые легче с чистого листа либо в принципе неподьемные которые невозможно переписать.

Например занесение рабочего времени/командировочных расходов через web-interface на базе AX EP и Sharepoint. Тормозит, не нравится интерфейс, требуются кастомизации в силу специфики. Берется open-source PHP как например time tracking http://www.kimai.org/ или похожее и кастомизируется.
О какой миграции тут может быть речь?

Какие-то свои шурупы, крюки и пристройки в AX которые образуют "свое", специфичное. Невозможно это переписать на другой язык, так как речь может быть только о миграции бизнеса на другую платформу с новой разработкой при необходимости. Но переписывание приложения что настолько в симбиозе - невозможно, нужен новые дырки в новых местах с другими шурупами.

А писать "с нуля" - это я про кастомизации в новой системе с нуля. Мы же не ожидаем что кто-то после/из AX/D365 захочет написать свое ERP c нуля?
Нет, этот кто-то возьмет как платформу что-то типа https://github.com/odoo/odoo
и будет писать кастомизации с нуля. Потому как переносить старый код и старую логику прутик за прутиком - не эффективно.

[sukhanchik]

Цитата:

Сообщение от belugin

Мне кажется вы смотрите только на то, что изменилось. Попробуйте также сравнить то, что осталось на месте.

Что больше diff(Ax2012, Ax3) или diff(Sap R/3, Ax3)

Дак... я ж естественно смотрю на то, что изменилось. Статья-то об изменениях.
Я согласен, что есть то, что не поменялось. Есть нужные изменения, например, модуль бюджетирования или то, как переписали финансовый блок (я пока не говорю об его архитектуре, а говорю пока про внешность). Т.е. конечно что-то стало и неудобным (ввод данных пользователем по счетам в ЖГК без автоподстановок аналитик к примеру), что-то стало удобным (гибкость аналитик в зависимости от счета и связка их со справочниками к примеру, а модуль бюджетирования научился наконец-таки контролировать).
Есть то, что мало поменялось (склад) и даже можно теперь увеличить количество складских аналитик - все это здорово. И то, что поменялось и то, что осталось тем же. ОСы российские к примеру, не поменялись и это тоже здорово. (я пока говорю про АХ 2012 и АХ 3)

Но есть некоторые вещи, которые поменялись глобально. Навскидку пока приходят 2 вещи - это интерфейс и структура данных. Хорошо это или плохо - это покажет время. То самое время, за которое все адаптируются к новым реалиям. Все - это специалисты - внедренцы, это новые специалисты, которые не видели предыдущих версий, это пользователи старых и новых версий и ЛПР (лица, принимающие решения).
Вот про это я и говорю.

А какой смысл сравнивать разницу между AX2012 и AX3 с разницей между SAP R/3 и AX 3? SAP R/3 не объявляет себя преемницей AX3 с одной стороны, а с другой стороны - MS не позиционирует AX 2012 / D365O, как отдельный продукт, который продается параллельно с АХ3. Более того, по сути - MS на правах владельца - не выпускает больше AX3.

Здесь более корректно сравнивать развитие AX 3 до AX 2012 / D365O и SAP R/3.
У SAP есть один очень важный момент - основной код ядра уже не менялся лет так ... дцать. Со всеми своими багами и фичами. И все специалисты по SAP знают эти особенности и научились их обходить. И в этом сила SAP, что есть понятный сценарий внедрения SAP, который можно оценить и реализовать. Да, кому-то по карману, а кому-то и не по карману, но все это прогнозируемо.
А с АХ получилось так, что со времен я думаю даже 2.5 и до 2009 был некий плюс-минус единый механизм внедрения и использования системы. Был плюс-минус единый интерфейс форм и можно было найти заветную кнопку чуть ли не вслепую.
Было понимание, что каждая форма смотрит на одну-две таблицы (множество датасорсов не приветствовалось) и можно легко выгрузить данные (Ctrl+C, Ctrl+V). А связи между таблицами тоже были плюс-минус осмысленные (ГК234323 все же легче запоминается человеком, нежели 234765323 (RecId), который еще и вдобавок системой генерится (самому неотредактировать RecId).

Конечно сейчас сделано много инструментов - интеграция с офисом, запоминание кнопок на уровне иконок в ленте, всякие DMF, SSRS и все такое, но ко всем этим инструментам рынок должен будет успеть адаптироваться. Это и сейчас видно - если даже посмотреть на MS, то все продукты выходят с опережением. Например, Office 2016 вышел в начале 2016-го года (или даже раньше); при этом сейчас многие используют Office 2013 или 2016, ну на крайняк - 2010. И уж думаю, что 2007-ю или уж паче 2003-ю версию никто не используют. К 2007-й все привыкали и наконец привыкли.
В случае с АХ - получается, что 2012-ю версию выпустили в 2011 году (в августе) и ... к ней все сейчас адаптируются. Кто-то уже работает, кто внедряется, а кто еще остался на 2009-й. Но ... на дворе 2017-й год и AX 2015 не выходила. Именно АХ, как продолжение. Потому что рынок еще адаптировался.

Поэтому для успешного повторения пути SAP - MS-у нужно остановиться в разработке и начать усиленно продвигать процесс внедрения последней версии. Это обучающие материалы, методические указания, демо-данные и т.д. Естественно все на языке той страны, в которой она будет внедряться.

А иначе - для тех, кто "не успел" перейти с АХ 3 или АХ 4 - D365O будет совершенно новой системой, где изменено "ВСЕГО".

[macklakov]

Цитата:

Сообщение от sukhanchik

У автора статьи были конечно немного иные мысли в статье, но суть их как мне кажется в том, что как только мы чего-то (неважно чего - код, платформу, интерфейс, идеологию и т.д.) меняем глобально - то это как раз-таки та ситуация, в которой мы тормозимся на рынке перед конкурентами.

С откровениями Джоэла надо быть аккуратнее, нельзя забывать чем он занимается сам. У него небольшая контора, производящая нишевый софт. Поэтому он на все смотрит со своей колокольни. Да, для мелюзги очень важно постоянно в движении быть, иначе крупные монстры их раздавят. Но у крупных монстров выигрышная тактика может быть совсем другой.
Рассматривая приведенный пример, MS может переписывать свой IE несколько раз с нуля и рано или поздоно у них получится написать что-то востребованное рынком. Для Netscape первая же ошибка стала фатальной.
В нашем случае, идет битва титанов, которые немного неповоротливы, но ресурсами не обделены. SAP все переписывает на Hana, MS перевел все на .net, а теперь в облако. Т.е. переписывание "с нуля" не просто имеет смысл, оно активно используется обеими сторонами.

[griefon]

Цитата:

Сообщение от macklakov

По моему личному опыту, в CRM что-то делать в несколько раз дольше, чем в AX

Очень зависит от конкретной задачи. Некоторые вещи делаются заметно быстрее. В несколько раз дольше, это когда из CRM начинают делать учетную систему.

[griefon]

Цитата:

Сообщение от trud

О.. кстати 2 дня назад мне такой же вопрос задал босс. нужно оценить потенциальное время на перевод решения с AX D365 на другие языки(само решение - порядка 100 форм, большинство функциональности сбоку, что-то типа русских договоров). на выбор были предложены С#, навижн, CRM..(но можно предложить что-то свое)
кто-нибудь имел опыт кодирования в этих системах - насколько там все сложно или просто кодировать по сравнению с АХ?

Могу про CRM сказать - сильно зависит от количества логики и расчетов. Чем больше расчетов, тем сложнее. Если просто формы, таблицы, связи и отчеты - то легко.

[belugin]

Цитата:

Сообщение от sukhanchik

Дак... я ж естественно смотрю на то, что изменилось. Статья-то об изменениях.

Статья про переписывание с нуля в стиле того, что предлагает ax_mct. Не всякое изменение есть переписывание. Замена искусственных ключей на суррогатные есть просто преобразование кода. Для этого не надо ставить задачу за ново и писать код с чистого листа. Распил таблицы на несколько - это тоже инкрементное изменение.

1) У меня впечатление, что большая часть кодовой базы осталась на месте, только подвергнута инкрементным преобразованиям в некоторой части

2) Иногда последовательность таких преобразований накопленная за три года выглядит как переписывание.

3) Некоторые куски действительно были переписаны

Цитата:

Но есть некоторые вещи, которые поменялись глобально. Навскидку пока приходят 2 вещи - это интерфейс и структура данных.

Я не вижу кардинальных изменений в интерфейсе в его семантике. В-основном изменилось оформление и какие-то общие правила. Группы почти все остались на месте и после усвоения почти все навыки можно использовать. (С Ax7 в этом смысле знаком меньше - но внутри примерно то же самое, как мне кажется).

То есть изменилось не описание интерфейса бизнесобъекта, а набор правил, по которым преобразуется в UI.

Цитата:

А какой смысл сравнивать разницу между AX2012 и AX3 с разницей между SAP R/3 и AX 3?

Статья про переписывание с нуля - соответстенно надо понять, что переписано, что преобразовано, что осталось как было. Для этого сравниваем с другой системой.

Если смотреть только на изменения, то согласен - 100% изменено .

Цитата:

Поэтому для успешного повторения пути SAP - MS-у нужно остановиться в разработке и начать усиленно продвигать процесс внедрения последней версии. Это обучающие материалы, методические указания, демо-данные и т.д. Естественно все на языке той страны, в которой она будет внедряться.

Это, мне кажется, офтопик - здесь мы про миграцию на разные платформы и переписывание с нуля. С моей точки зрения, ни Ax6 ни Ax7 не являются системой переписанной с нуля. Какие-то куски - да.

[fed]

В дискуссии belugin vs sukhanchik я бы просто посоветовал различать оправданный и неоправданный рефакторинг. Оправданный рефакторинг позволяет разрабатывать новую функциональность востребованную конечными заказчиками, неоправданный рефакторинг делается только потому что кто-то в Микрософт решил что так лучше. И я бы сказал что процентов 60-70 изменений сделанных в Микрософт - это неоправданный рефакторинг. Реальных новых полезных на внедрениях фич он не принес, а затраты на изучение и внедрение - поднял. Отсюда и раздражение на рынке по поводу этих "инноваций"...
P.S. И вправду - выделили бы эту дискуссию в отдельную тему.

[mazzy]

Цитата:

Сообщение от belugin

Не всякое изменение есть переписывание.

да

Цитата:

Сообщение от belugin

Замена искусственных ключей на суррогатные есть просто преобразование кода. Распил таблицы на несколько - это тоже инкрементное изменение.

нет.
структура базы - это публичный интерфейс.

Цитата:

Сообщение от mazzy

...люди - не только программисты.
поэтому - нет, не дешевле

[mazzy]

Цитата:

Сообщение от NetBus

про миграцию корпоративных приложении с одного языка на другой?

Цитата:

Сообщение от fed

...оправданный и неоправданный рефакторинг.
...
И вправду - выделили бы эту дискуссию в отдельную тему.

миграция и рефакторинг - это две стороны одной медали.

насколько я понимаю, выше как раз обсуждают условия и границы, когда применим рефакторинг, а когда миграция.

[mazzy]

Цитата:

Сообщение от belugin

Я не вижу кардинальных изменений в интерфейсе в его семантике.

исчез MDI, исчез dynalink

Цитата:

Сообщение от belugin

Статья про переписывание с нуля - соответстенно надо понять, что переписано, что преобразовано, что осталось как было.

мне кажется кардинально неправильным подходить к задаче переписывания со стороны вендора.
как ты уже говорил, в принципе все равно что делает разработчик вендора.

к задаче переписывания нужно подходить со стороны пользователя и внешнего разработчика (который пользуется документированными API).

если пользователю придется изменять свои навыки - система изменена (и не важно как оно внутри устроено)
если разработчику придется менять свои наработки под другое API - система изменена (и не важно как оно внутри устроено)


типичный пример, 64битное приложение и 32битная версия.
FAR какой-нибудь, Total Commander, FireFox, MS Office.

с точки зрения вендора приложение то же самое. но многие плагины не работают.
поэтому с точки зрения пользователя это другое приложение.
и вендору приходится прилагать много усилий по поддержке обеих версий, по сближению обеих версий.

типичный пример легко переписываемого с нуля приложения - ipscan
https://github.com/angryziber/ipscan, http://angryip.org/
выступление автора, где он рассказывает историю приложения и как он дошел до версии 3
https://www.youtube.com/watch?v=y8yKxmz6iDY

===============
возвращаясь к исходному вопросу:

миграция на другой язык неизбежно приведет к смене API и к смене требуемых навыков со стороны пользователя.
именно поэтому миграция и является очень дорогой для корпоративных приложений.

для корпоративных приложений доля трудозатрат со стороны вендора как правило очень невелика по сравнению с общими трудозатратами всех людей, связанных с корпоративным приложением.

[belugin]

Цитата:

Сообщение от fed

В дискуссии belugin vs sukhanchik я бы просто посоветовал различать оправданный и неоправданный рефакторинг.

С моей точки зрения, это не является частью темы "Переписываения приложения на другом языке". (Мы обсуждали переписывать с нуля или не с нуля, и как делает MS но не надо делать какие-то не связанные с этим преобразования или не надо)