Нужна помощь.
Есть конфа, которую нужно перевести на управляйки, в ней есть куча говнокода местами на пару десятков тысяч строк. Читаю код и кровь из глаз. Человек который писал это, писал все от руки и почти все б... в нижнем регистре. типа
Пытаюсь хоть как-то это причесать до читабельного вида. Конфа развернута в обычном конфигураторе. Попробовала причесать через обработку Автоформатирование кода и локализация, которая с сайта ИТС, ссылка на нее есть в описании стандартов оформления текста модулей. Но она только может причесать ключевые слова в запросах и ключевые слова (стандарт 427 п.1) и ключевые слова встроенного языка (стандарт 441 п.1). Т.е. поправит всякие "если, процедура, функция, или", а вот методы, свойства, обращение к объектам метаданных увы и ах. Причем весь прикол, что после ее запуска исправления появились только в тех модулях где такие ошибки были единичны, такое ощущение, что дойдя до этих модулей с тысячами строк говнокода обработка сказала "данунахяпошла".
Посмотрела встроенный инструментарий форматирования в EDT, там фактически тот же аналоги что и в обработке Автоформатирование кода и локализация, ну плюсом пробелы ставит между "=".
Вопрос, может еще что-то есть чем можно исправить в автоматическом режиме тонну говнокода именно в части методов, свойств. Какой-то плагин к EDT есть? По АПК и SonarQube на сколько понимаю только анализ кода, автоправок они делать не умеют. А вручную это через стандартные "найти-заменить" это конечно та еще песня, в воспитательных целях я автору сего шедевра могу конечно дать задачку, но мне как-то надо еще с этим работать в сжатые сроки. Код давно на продуктиве еще. Про отступы, закомменченный код, названия процедур/переменных я конечно вообще молчу.
(7) Попробуйте эту обработку. Названия собственных переменных и функций в соответствии с верблюжьей нотацией она, конечно не исправит.
В макете есть список возможных слов встроенного языка, если захотите переделать.
(12) чтобы что-то написать, надо сначала прочитать. А читать это просто невозможно. Там один справочник расписан в общей сложности на 19 с лишним тысяч строк кода (если суммировать по всем его формочкам).
Т.е. для визуального понимания объема: Одна страница обычного печатного текста 11 шрифтом занимает примерно 30 строк, итого получаем более 600 страниц текста, пачка офисной бумаги типа Снегурочка это 500 листов. И вот теперь представьте, что вам вот этот объем надо перефигачить на управляйки и при этом весь код в стиле "зачемстандартыработаетиладно". Возьметесь без переформатирования?
(17) боюсь такие вещи выкладывать тут как запросы в цикле, лишние переменные и т.п. никаких ресурсов форума не хватит. Да и не правятся такие вещи никакими обработками, а только собственными мозгами, ручками, ручками и еще раз ручкам. Максимум автоматизации в этом процессе это анализ кода на соответствие стандартам.
В данной ветке решался вопрос лишь автоматического приведения кода в читабельный вид, и он с определенным уровнем успеха был решен.
(4) Да переменные и имена процедур черт бы с ними уже, как-то руками пусть причесывают через рефакторинг. Сейчас бы причесать стандартные платформенные методы, свойства, коллекции, обращения к метаданным. В идеале и имена этих метаданных.
Как минимум
(6) Значения в кавычках не получится заменить автоматически. Предполагается, что значение, взятое в кавычки, должно остаться ровно в том виде, в каком оно записано – на то они и кавычки, иначе возможно нарушение логики кода.
(11) Это логично, т.к. там тексты для оповещения пользователя могут быть, логи, плюс тексты запросов у которых вообще свои стандарты на написание ключевых слов. Попробовала, вполне годная штука, спасибо огромнейшее. Осталось дело за малым, провести аудит на реально используемый функционал, вырезать к чертям неиспользуемый код и посадить автора за исправление кода через эту обработочку, да остатки через типовой рефакторинг да поиск/замену. По исправлению названий объектов метаданных думаю обработочку можно будет тоже наклепать, тут попроще, основной затык был со словарем 1С-овских методов, свойств и т.п.
СПАСИБО!!!!
Есть уже мысль что придется какую-то тулзу самостоятельно писать, но вопрос тогда встает, где выдернуть какую-то библиотеку с перечнем методов и свойств. Теоретически можно было бы тупо копипастить текст модуля, запускать по перечню методов и свойств поиск по коду без учета регистра и предлагать подменять найденные фрагменты текста формируя итоговый текст модуля. А дальше уже копипастить текст из обработки в конфигурацию.
Но вдруг уже все сделано до нас и такая тулза уже существует.
(7) Можно попробовать взять какой-нибудь 1С:Language Tool и перевести конфигурацию на английский, а потом обратно на русский. Если не поможет, то доставит море удовольствия при чтении.
(9) боюсь вариант не вариант. Если бы речь шла о г...коде в управляйках, может и можно было бы что подгрузить и развернуть в рамках EDT и бахнуть этим плагином перевод. Пока на скорую руку попрбовала бахнуть через 1С:Переводчик, банально не смог он прогрузить из XML исходные тексты на перевод. На управляйки тексты сохраняются в формате bsl, на обычных формах это bin файлы, возможно в этом весь затык. Возможно это и причина почему в т.ч. ИТС-овская обработка Автоформатирование кода и локализация ничего не смогла с этими модулями сделать. Поэтому сомневаюсь что и 1C:Language Tool будет с бинарниками работать. Прикол что 1С:Переводчик даже не вытянул ручной перевод текста модулей, т.е. копипаст корявой процедуры в окно с исходным текстом. При попытке перевести он тупо выдал перечень всех слов, предложив мне ручками написать их перевод. При этом разбивка была с учетом регистра, т.е. на слова "ссылка", "Ссылка" требуется задать 2 перевода. Короче, для перевода интерфейса может штука и годная, а вот для корявых исходников похоже такой вариант совсем не вариант.
(7) Попробуйте эту обработку. Названия собственных переменных и функций в соответствии с верблюжьей нотацией она, конечно не исправит.
В макете есть список возможных слов встроенного языка, если захотите переделать.
т.е. воспользоваться результатом большого объема проделанной работы предыдущим программистом это нормально, и при этом его попытку простейшей обфускации кода называть "говнокодом" это нормально?
В таком случае любая программа на С++ это "говнокод". Там же после дизассемблирования такая "хрень" получается...
(16) Как вы примерно оцениваете в денежном эквиваленте цену такой чудесной обфускации для компании?
На проект уже трижды заходили разработчики, в т.ч. компании, с попытками перевода на УФ. И все три попытки провалились. И глядя на текущее состояние кода, я прекрасно понимаю почему. Помимо кода, там еще целый ряд архитектурных проблем. При этом что не тронь, тут же попадаешь на такой уровень зависимостей, что мозг взрывается, переписываешь один небольшой справочник и параллельно тучу общих модулей, документов, отчетов и обработок.
Прикидывайте себе процесс поиска методов открытия формы вида:
И вот вы перепиливайте одну даже простенькую формочку, а потом лопатите вот это через глобальный поиск, прощелкивая свыше тысячи строк, такого стиля. И так же по имени объекта метаданных пытаетесь шерстить весь код в поисках, а нет ли попытки открытия формы элемента с наложением отборов или корявой передачей в нее данных, что в УФ не поддерживается и должно быть переделано на передачу Параметров, а не попыткой задать значения элементам формы. Наверное эту "обфускацию" надо оставить как есть?
И всё это вертится в нескольких увесистых нагруженных продах, и на все это еще различные интеграции навешаны, начиная от обменов данными через вэб сервисы, заканчивая прочими конфигурациями для управленческого и регламентного учета. Все это запускается в режиме совместного использования обычных и управляек, с заливкой на проды, с которых не должен произойти никакой отвал функционала. И при этом часть таких "обфусцированных" модулей тупо валятся на синтаксическом контроле. Благо код не весь такой, а только отдельные его части, которые писал конкретный человек, основная часть кода написанная другим разработчиком вполне поддается переработке.
Обфускация это осознанное действие над кодом в целях защиты авторских прав. В данном же случае это увы и ах, но говнокод, как результат неумения пользоваться клавишами Shift, Ctrl+space, Ctrl+c, Ctrl+v, Ctrl+q, Alt+Shift+F и не знания самых базовых основ работы с обычным конфигуратором и самого простого базового стандарта оформления программного кода.
Итог сей "обфускации", для компании, это деньги уже затраченные на неудачные попытки перевода конфы, т.е. сумма с 6 нулями. И будущие затраты на аналитиков, разработчиков, которым сейчас придется разбираться со всей этой "обфускацией". Затраты на выплату зарплаты штатным программистам, которые сейчас вынуждены будут приостанавливать большую часть плановых работ и работ по текущей поддержке пользователей и заниматься устранением технического долга. И расходы на простой в запуске проекта еще по одному проду, предполагаю, что и затраты на покупку и адаптацию совершенно другого программного обеспечения, стоимостью минимум в 5-6 нулей, т.к. успеть перевести на УФ конфу в таком состоянии до запуска очередного прода - анриал. Вся эта "обфускация" писалась не на голом энтузиазме, а за деньги компании.
Так что давайте не будем путать терминологию.
PS: Эксперимента ради, можете тут забацать статью с заголовком "говнокод как средство защиты программного кода", это будет фурор.
(19) из вот этого, я вижу попытки компании "сэкономить" и Ваши попытки "сэкономить". И из-за этого обозвать чужой код.
Я не вижу весь код, но очень ярко светит высказывание: " Человек который писал это, писал все от руки и почти все б... в нижнем регистре.". Именно это называете "говнокодом", что дальше обсуждать просто нечего.
Предложите компании разработать нужный функционал, а не попытки перевести код, да еще автоматом в УФ.
Разный подход.
PS. Если весь код в нижнем регистре, то это не означает, что он написан исключительно от руки и без автодополнения. Скопировать текст, перевести его в нижний регистр и заменить в исходнике даже не рассматривали? Сразу огульно "говнокодом" обозвать конечно проще.
(22) если бы мне нужно было чего-то доказывать руководству, я бы вообще не парилась вопросами поиска технических средств для приведения существующего кода в читабельный вид.
(29) Хорошая статья, спасибо. Пока по диагонали просмотрела, почитаю завтра за утренним кофе.
Впринципе, те же подходы, что описаны в статье сейчас и использую на проекте. Т.е. анализ, диаграммы, перевод кода как есть (если можно вообще применять этот термин в отношении УФ), т.е. алгоритмы и архитектура на первом этапе сохраняются, какие есть, пусть кривые, пусть косые, со всеми неоптимальностями в производительности и т.п. Получаем тот же функционал, но в новом оформлении и более менее нормальным кодом под капотом.
Изменение архитектуры и логики, оптимизация - это уже будет следующий этап, т.к. если сейчас впихнуть его на первом этапе, при всем объеме работ пытаться еще распыляться на него, это значит из-за зависимостей утонуть в тонне не переработанного старого кода, тратя силы и время на решение проблем с совместимостью с новым функционалом. Кода который в последствии все равно так же нужно будет на 100% переписывать.
Опять же многие вещи по сравнению с данной статьей приходится упрощать, те же диаграммы пока рисовать в упрощенном виде, т.к. в противном случае если садиться и прорисовывать диаграммы по всем канонам проектирования, по всей конфе сразу, можно будет сказать через год-два руководству: "Смотри какие классные картинки я нарисовала. Правда там сейчас у вас уже всё 100500 раз поменялось, ну ничего я еще с пол годика посижу порисую".
Короче, тема эта большая, интересная, но не для этой ветки.
PS: Нашли, что искали?
Да:)
(25) Изначально так и планировалось. Чисто запуск на новом проде. Переделка по отдельным функциональным блокам с запуском на новый прод. Сделали блок, пользователи начали заполнение НСИ, начали работу с функционалом, постепенно довешиваю сверху новый функционал. Все сразу под БСП и с контролем качества кода через АПК или SonarQube. Но встал вопрос именно перевода уже действующих продов, которые постоянно еще и дорабатываются. Есть огромный риск, что к моменту окончания проекта новая конфа будет существенно отличаться от конфы прода и при переводе через КД, часть важного для оперативной работы функционала просто отвалится. Максимум что можно в таком случае предпринять это разбивка на функциональные блоки и перепил по ним, с постепенным переводом в т.ч. архитектуры на приемлемый уровень. Хотя даже по этому подходу оптимизма у меня крайне мало.
Слишком много затыков в выбранном подходе, простой пример, работа с файлами, уже есть механизмы, в каждом конкретном случае реализованы по-разному. Нужно это сделать на БСП. Если с нуля, нет проблем, пара строк кода и готово. Если это боевая база, тут же попадаешь еще на изготовление обработок которые будут перетаскивать с нужной привязкой эти файлы со старых источников хранения данных, в БСПшные. Т.е. трудозатраты на подобную разработку увеличиваются многократно.
В любом случае любой из выбранных подходов увы не исключает этапа тотального рефакторинга существующего кода, иначе это будет просто 4й завал проекта перевода.
(20) где вы тут увидели про "перевести код, да еще автоматом в УФ"?
Весь перенос алгоритмов ручной! С переводом на БСПшный функционал. Управляемая форма как верстка, так и код пишутся заново.
Другое дело, что это все должно быть неразрывно с текущим продуктивом и поэтому необходимо понимать алгоритмы обработчиков каждой кнопочки, каждого поля и переключателя. А для этого читать, читать и еще раз много читать и анализировать код. Если вы мазахист и вам плевать на ваше зрение и банальный перегруз от необходимости читатькаждуюбуквувслове, велкамприсылайтерезюме, с удовольствием отпишу эту задачку на десятки, а то и сотни тысяч строк переписывания такого кода вам, прям как есть, в нижнем регистре и без какого-либо рефакторинга.
Компания "сэкономила". Как? Заплатив за фиговое качество работы специалиста, которое ни один руководитель компании естественно не в состоянии оценить?
Вы завтра наймете строителя, который из г-на и палок вам фундамент и стены сложит. Ну да стена, ну да фундамент, с виду как у всех, пока вы мебель не завезли и обои клеить не начали, а потом выясняется что стены ваши на одних обоях то и держатся. А еще вы на радостях какие чудесные дома, их еще решили продавать. И вот въехал новоиспеченный жилец, а его завалило нафиг со всей семьей насмерть. И в последствии вы попали на несопоставимую затраченной сумму и сроки лишения свободы. Как вы эту работу назовете, мастер золотые руки?
На стандарты разработки обычно кладут те, кто только привык что-то писать и никогда не сталкивался с поддержкой программного кода и с переводом его на новые рельсы и не работал в нормальной команде разработчиков.
Код стиля "итаксойдет" я допускаю на каких-то внешних одноразовых отчетах/обработках используемых разработчиком для технических нужд, в прод будь добр следовать общепринятым правилам оформления кода как минимум.
PS: Если кто-то желает в ветке поделиться своим реальным практическим опытом перевода больших конфигураций на УФ, велкам, пишите, с удовольствием почитаю (фичи, лайфхаки, подводные камни, описание той или иной методологии).