Антидот
Разработка - Рефакторинг и качество кода
Предисловие
Скажу сразу. Всех авторов Инфостарта я люблю и уважаю. Написать статью - это большой труд. И я обычно "плюсую" прочитанные мною статьи, даже если не согласен с автором. Я решил написать этот материал не для того, чтобы кого-то уязвить. Я забочусь о наших коллегах, только начинающих свою карьеру. Прочитав очередной труд и увидев много звездочек, они могут подумать, что мысли автора это что-то записанное на изумрудных скрижалях, не меньше. Автор, рассказывающий о том, что программы следует писать слева направо и сверху вниз, кажется им настоящим гуру. Они и не догадываются о том, что статьи подобного рода чаше всего написаны почти такими же начинающими, как и они. Потому что человека с опытом вряд ли может удивить и, тем более, возмутить что-либо в чужом коде.
Я как-то не задумывался об этом, пока не попробовал пошутить с одним из авторов, у которого "накипело". Я выразился примерно в следующем смысле:
"Вот вы обличаете нехорошие практики, а какая у вас самого практика в нехороших практиках? Сами-то этим занимались когда-нибудь?"
Вы не представляете - как он обиделся! И я подозреваю, не потому, что у него нет чувства юмора.
Или вот совсем свежий пример от другого автора. Он рассказывает нам, как некие нехорошие люди пишут программы тяп-ляп и абы как. Его благородная ярость все вскипает и вскипает. И наконец достигает чуть ли не высшей своей точки, когда он сообщает нам, что вот, дескать, горе-разработчики знать ничего не знают про ФИФО, просто списывают самую старую партию. И в качестве подтверждения своих слов приводит текст запроса... Вы писали когда-нибудь запрос для ФИФО? Если да, то вы будете смеяться вместе со мной. Это был тот самый запрос. Я этому автору говорю: "вы нам код после запроса покажите, там должно быть самое интересное". Думал, он сам посмотрит и скажет: извините, погорячился... Нет. Взял и поправил свою публикацию. Выложил код. Правда обрезал его посередине. Так и оставил в непонятках. То ли совсем ничего про ФИФО не знает, то ли стесняется.
Не будем, впрочем, затягивать вступление и перейдем к антидоту.
Антидот
Для надежности я решил сделать антидот двухкомпонентным. Я возьму два простых утверждения, которые кажутся очевидными. И продемонстрирую, что получится, если подумать над ними, как следует.
Часть 1. Имена переменных должны быть осмысленными и понятными.
В этом месте я всегда предлагаю подумать на тему, что лучше:
СуммаПервогоИВторого=Первое*Второе;
или
х=Первое*Второе;
Тут обычно начинают задавать вопрос по поводу первого варианта: что это вообще такое и зачем я так написал. Зачем, зачем... Пишу я так. На тысячу строк кода два-три раза нечто подобное и напишу. Но это потому, что я опытный. У других может и все 20 или 30 раз получиться. Мы все делаем ошибки. Нет ничего удивительного в том, чтобы написать "*" вместо "+". Лично я не перестаю удивляться другому. А именно тому, что можно часами сидеть, смотреть на первый вариант и не видеть проблемы. Здесь может спасти только "взгляд со стороны", когда ваш коллега сдвигает вас с мертвой точки. Но вся проблема в том, что вы можете зависнуть не на:
СуммаПервогоИВторого=Первое*Второе;
а на чем-то другом, типа:
Периметр=СуммаПервогоИВторого+СуммаПервогоИВторого;
И тут вам коллега уже ничем не поможет.
Мне как-то привели вот такой пример:
Если ((ПН И ПНП) И (РН И РНП)) ИЛИ
(( ПН = Ложь ) И (РН И РНП)) ИЛИ
((ПН И ПНП) И (РН = Ложь)) Тогда
Док.Обработан = Истина;
Док.ДанныеОбработан = ТекущаяДата();
Док.Записать(РежимЗаписиДокумента.Проведение);
КонецЕсли;
И спросили: "Ну и как? Это хороший код по-твоему?"
Нет. Это - плохой код. Вместо трех строчек условий следует оставить одну с одним "ИЛИ".
(* Внимательные читатели заметили, что здесь я был не прав. Это выражение на самом деле не сокращается)
А насчет имен переменных... Ну, допустим, они будут понятными. Что вам это даст? Если человек путается в условиях, то где гарантия, что он ничего не напутал ранее с установкой значений?
Но самый главный аргумент против моих рассуждений следующий:
"Зачем спецом портить программу? Ведь тогда все станет непонятным."
И вот здесь надо разобраться как следует. Во-первых, непонятным станет не все. У нас с вами есть имена справочников, документов, регистров. Есть имена их реквизитов. А также имена модулей и методов. Переменные - это далеко не все, что есть в нашем коде.
Взгляните на картинку, которую я взял отсюда: https://ru.wikipedia.org/w/index.php?curid=6775969
Представьте себе, что точки - это имена предметных сущностей, а линии - это переменные.
Теперь посмотрите на вторую картинку:
Некоторые полагают, что сам смысл работы программиста заключается в переходе от первого ко второму. Дескать, первое вам кто угодно сделает, а для второго уже нужна квалификация. Для этого есть даже специальный термин: decoupling. Его невозможно хорошо перевести на русский без мата, поэтому я его оставлю, как есть. Если вы присвоили переменной некоторое значение, а потом используете ее через 1000 строк вашего кода - это плохо. Хуже этого могут быть только глобальные переменные. Как говорится: самый лучший префикс для глобальной переменной это //. В идеале, вы объявляете переменную. Используете ее в следующей строке, через строку, через две-три. Но не далее чем вы можете "схватить" за один свой "рабочий такт". После чего, вы можете забыть о ней навсегда. Единственное, о чем вам стоит позаботиться, так это о том, чтобы хорошо различать переменные, если их будет несколько. Идеальный код должен обладать таким свойством, что если взять и заменить в нем все имена переменных на случайно подобранные, то он нисколько не потеряет в читабельности.
Что из всего этого следует. Имена переменных должны быть хорошо различимы в своем локальном контексте. Будут они осмысленными или нет - дело вкуса. Более того, начинающим было бы разумно рекомендовать использовать только абстрактные имена. Это будет естественным образом подталкивать их к созданию более совершенного кода.
Часть 2. Копирование кусков кода - зло.
если зеленый тогда
///////////////////////////////////////////////
новкоординаты=новыекоординаты(текузелрез);
нсрез=текузелрез.строки.добавить();
нсрез.ид=Новый УникальныйИдентификатор;
нсрез.тип="ГРУППА";
нсрез.имя=текузел.имя;
нсрез.РПШирина=19;
нсрез.РПВысота=12;
нсрез.РПВерх=новкоординаты.верх;
нсрез.РПЛево=новкоординаты.лево;
нкорсв=своуз.строки.добавить();
нкорсв.узел=нсрез.ид;
стузелрез=текузелрез;
текузелрез=нсрез;
//////////////////////////////////////////////
связь="";
подключение="";
для каждого св из мсв цикл
если врег(сокрлп(св.свойство))="СКРЫТЬ" тогда
нсрез.тип="СКРЫТАЯГРУППА";
иначеесли врег(сокрлп(св.свойство))="УСЛОВИЕ" тогда
продолжить;
иначеесли врег(сокрлп(св.свойство))="ИСКЛЮЧИТЕЛЬНОЕ_УСЛОВИЕ" тогда
продолжить;
иначеесли врег(сокрлп(св.значение))="ЗАПИСАТЬ" тогда
ВыполнитьКоманду(св.свойство,врег(сокрлп(св.значение)));
иначеесли врег(сокрлп(св.значение))="УДАЛИТЬ" тогда
ВыполнитьКоманду(св.свойство,врег(сокрлп(св.значение)));
иначеесли врег(лев(сокрлп(св.значение),6))="НОВЫЙ " тогда
метаимя=врег(сокрлп(сред(сокрлп(св.значение),6)));
если лев(метаимя,8)="ДОКУМЕНТ" тогда
новзн=документы[сокрлп(сред(метаимя,10))].создатьдокумент();
новзн.дата=текущаядата();
иначеесли лев(метаимя,10)="СПРАВОЧНИК" тогда
новзн=справочники[сокрлп(сред(метаимя,12))].создатьэлемент();
конецесли;
записатьвпамять(св.свойство,новзн);
нсв=нкорсв.строки.добавить();
нсв.свойство=св.свойство;
нсв.значение=новзн.ссылка;
нреф=рефс.добавить();
нреф.имя=св.свойство;
нреф.строкасвойств=нсв;
иначеесли врег(лев(сокрлп(св.значение),5))="НОВАЯ" тогда
стрзнач=сокрлп(стрзаменить(св.значение,"НОВАЯ",""));
стрзнач=сокрлп(стрзаменить(стрзнач,"новая",""));
поз=стрнайти(стрзнач,".");
если поз>0 тогда
имяобъекта=лев(стрзнач,поз-1);
имятаблицы=сред(стрзнач,поз+1);
иначе
имяобъекта=стрзнач;
имятаблицы=неопределено;
конецесли;
нс=память.найти(имяобъекта,"имя");
если нс<>неопределено тогда
новзн=нс.значение[имятаблицы].добавить();
записатьвпамять(св.свойство,новзн);
конецесли;
иначе
новзн=ВычислитьЗначение(св.значение);
записатьвпамять(св.свойство,новзн);
нсв=нкорсв.строки.добавить();
нсв.свойство=св.свойство;
попытка
нсв.значение=новзн.ссылка;
исключение
нсв.значение=новзн;
конецпопытки;
если врег(сокрлп(св.свойство))="СВЯЗЬ" тогда
связь=сокрлп(св.значение);
иначеесли врег(сокрлп(св.свойство))="ПОДКЛЮЧЕНИЕ" тогда
подключение=сокрлп(св.значение);
конецесли;
конецесли;
конеццикла;
если не пустаястрока(связь) тогда
нс=списокбаз.найти(текузел.имя,"имя");
если нс=неопределено тогда
новб=списокбаз.добавить();
новб.имя=текузел.имя;
новб.подключение=подключение;
новб.связь=связь;
новб.база=неопределено;
конецесли;
конецесли;
для каждого уз из текузел.строки цикл
ОбработатьУзел(уз,текузелрез);
конеццикла;
текузелрез=стузелрез;
конецесли;
иначеесли текузел.тип="ЦИКЛ" тогда
//////////////////////////////////////////////////
новкоординаты=новыекоординаты(текузелрез);
нсрез=текузелрез.строки.добавить();
нсрез.ид=Новый УникальныйИдентификатор;
нсрез.тип="ГРУППА";
нсрез.имя=текузел.имя;
нсрез.РПШирина=19;
нсрез.РПВысота=12;
нсрез.РПВерх=новкоординаты.верх;
нсрез.РПЛево=новкоординаты.лево;
нкорсв=своуз.строки.добавить();
нкорсв.узел=нсрез.ид;
стузелрез=текузелрез;
текузелрез=нсрез;
/////////////////////////////////////////////////
Этот типичный пример копирования кода я взял из одной своей работы. Два выделенных мною вверху и внизу фрагмента полностью идентичны. Почему я так поступил? Как говорил Дейкстра, работа программиста сродни искусству жонглера. Только жонглеры крутят в воздухе физические предметы, а мы абстракции в своей голове. Представьте себе артиста в цирке. Вот он крутит три булавы, потом четыре-пять-шесть. Ему подбрасывают еще одну. А ты думаешь: неужели возьмет. Но все равно это когда-нибудь заканчивается. Вот и я не мог в тот раз "взять еще одну булаву". Мне тогда пришлось бы выкинуть что-то другое, более важное. А переделывать после я не стал. С одной стороны - время, а с другой стороны, принцип "работает - не трожь" никто не отменял.
Кто-то скажет, что я тут плохому учу. Ведь есть серьезные проекты. Ты не можешь думать только о себе. Ты должен думать и о тех, кто будет поддерживать твой код.
Хорошо. Давайте подумаем.
Допустим, у нас очень серьезный проект. Сотни тысяч будут пользоваться нашей конфигурацией. Тысячи специалистов будут заниматься ее поддержкой и кастомизацией. Тысячи глаз специалистов будут каждый день смотреть в наш код, и это налагает на нас особую ответственность.
А теперь следите за руками. Предположим, что в нашей конфигурации есть пять-шесть документов, которые формируют расходные записи в каком-нибудь регистре остатков. Соответствующие куски кода в процедурах обработки проведения у всех этих документов полностью идентичны. Я не буду приводить здесь этот фрагмент кода. Вы и сами легко можете представить себе, что там будет что-то типа:
//Получение данных из документа
//Формирование движений по регистру
//Блокировка
//Запись движений по регистру
//Контроль отрицательных остатков
Код, повторяю, полностью идентичен. Но мы не хотим просто копировать его в пять-шесть документов, потому что это "фу!". Мы создаем общий модуль. В общем модуле создаем общую процедуру, какую-нибудь ВыполнитьСписаниеПоРегистру...(). Эта общая процедура вызывает другие общие процедуры: ПолучитьДанные...(), СформироватьДвижения..(), ЗаписатьДвиженияСКонтролем...(). В принципе и эти общие процедуры могли бы вызывать какие-нибудь другие общие процедуры. 1С рекомендует делать не менее 7-8 последовательных вызовов общих процедур, но у меня не хватает на это фантазии.
А теперь на сцене появляется специалист поддержки. Тот самый один из тысячи. Ради которого мы старались сделать свой код лучше. Ему надо внести какое-нибудь плевое изменение в модуль проведения одного из документов. Реквизит регистра заполнить по-своему или контроль подправить. Он знает логику работы платформы. Он знает, что записи регистра формируются в момент проведения. Что в модуле документа есть предопределенная процедура ОбработкаПроведения(). Ему надо, быть может, добавить всего одну строку кода. А может, и того меньше, всего пару символов в определенную строку. И он вправе рассчитывать, что эта работа займет у него если и не одну секунду (1С - это одна секунда, если кто не знает), то буквально считанные минуты. Но не тут-то было. В нашей процедуре обработки проведения некуда вставить эти два символа. Там только одинокий вызов процедуры общего модуля. Специалист теперь должен пройти по нашим общим процедурам, найти нужное место для вставки своих изменений. И двумя символами дело уже никак не обойдется. И, что самое неприятное, при каждом получении от нас обновленной конфигурации, ему придется проделывать эту работу заново.
То есть, мы, выходит, вовсе не подумали об удобстве для тысячи специалистов. А о чем мы тогда думали? Об удобстве для нескольких наших разработчиков в ущерб удобству тысячи специалистов поддержки? Или просто о том, что копировать код это "фу!"?
Делайте со мной что хотите, но будь я руководителем разработки такой ответственной конфигурации, я бы просто заставил... СКОПИРОВАТЬ КОД.
Что из этого следует. Если вы разработчик-одиночка, перечитывайте почаще Маяковского
умри, мой стих,
умри, как рядовой
и старайтесь не преувеличивать значение вашей разработки.
Если же вы отвечаете за разработку массового продукта, то думайте не о каких-то там шаблонах, а о том, что вы хотите получить в результате.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Нейросети Рефакторинг и качество кода Запросы Разработчик 1С 8.3 Абонемент ($m)
Нейросеть написала запрос или процедуру для вашей базы 1С, и непонятно, все ли имена в нём настоящие. Обработка компилирует текст без выполнения, сверяет его с метаданными этой базы и к каждой ошибке пишет настоящее имя, например ВНаличииОстаток вместо выдуманного КоличествоОстаток. Список ошибок с подсказками одной кнопкой копируется обратно в чат с моделью.
10 стартмани
02.11.2026 343 1 nedomolkov.ivan 1
Рефакторинг и качество кода Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Одна проверка в обработчике кнопки может выглядеть достаточной, пока ту же операцию не вызовут из другого места. На примере управляемой формы разберём, почему так происходит, как разместить проверку в общей серверной функции и чем отличается удобная проверка ввода от обязательного условия выполнения операции.
29.10.2026 368 YA_777378709 0
Рефакторинг и качество кода Разработчик Бесплатно (free)
Рассказываем, почему качественный код – это не техническая прихоть, а актив, который помогает бизнесу быстрее адаптироваться к изменениям и запускать новые фичи без бесконечного преодоления техдолга. Показываем, как объяснить бизнесу ценность рефакторинга через понятные признаки: замедление разработки, неточные оценки, страх перед legacy и хрупкость системы. Разбираем, почему неправильный рефакторинг может быть дороже его отсутствия, какие анти-паттерны ломают процесс и как не превратить улучшения в бесконечную переделку ради переделки. Объясняем, как сделать рефакторинг частью культуры команды: договориться с бизнесом, научить разработчиков видеть проблемные места, закрепить правила и поддерживать улучшения на уровне тимлидов, архитекторов и всей команды.
28.10.2026 481 Pavel791 0
Рефакторинг и качество кода HighLoad оптимизация Системный администратор Разработчик Стажер 1С 8.3 Абонемент ($m)
Если к HTTP-сервису 1С обращаются сразу несколько программ, сколько запросов в секунду он успеет обработать? Я опубликовала простой HTTP-сервис на нашей "подопытной" конфигурации «Нано-УТ» (файловая база, Apache, без прав администратора) и нагрузила его скриптом на Python. Ответ: около 15-16 запросов в секунду, сколько бы клиентов ни обращалось одновременно. Запросы ждут своей очереди, и при 32 клиентах ответ приходит через 2 секунды вместо 64 мс. Заодно разобрала скрипт из первого варианта статьи: он «проверял» сервер, который отвечал по одному, и считал ошибки вместе с успешными ответами. В архиве исправленный скрипт, учебный сервер, HTTP-сервис для 1С и инструкция по запуску.
1 стартмани
23.10.2026 514 Ninel_S 3
Рефакторинг и качество кода Разработчик 1С 8.3 Абонемент ($m)
Запустили Analyzer 1C 2.7.65 на промышленной конфигурации (596 модулей, 13 669 функций) и исследовали перегруженные функции (до 1887 строк), циклические зависимости и экран «Циклы» (кольцо из 64 модулей). Разобрали, почему популярные метрики (McCabe, связность) не представлены в продукте вендора, и составили пошаговый план разделения модуля. Привели проверенный платформой 8.3.27 пример до и после рефакторинга и выявили скрытую ловушку загрузки модулей с точкой в имени.
9 стартмани
19.10.2026 451 Ninel_S 2
Рефакторинг и качество кода EDT СКД Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Одиннадцать граблей схем компоновки, которые не видно в конструкторе и не ловит EDT, на реальных отчетах БП КОРП. Формат числа задается в двух местах, и условное оформление варианта перебивает формат поля. Ресурс складывает штуки с часами, и помогает выражение «только когда единица одна». Ресурс пуст в детальных записях, параметр не появляется в шапке без userSettingID, valueListAllowed ломает границы периода, Остатки и СрезПоследних с параметром периода падают с «Несоответствием типов», title без xsi:type дает «Исключение XDTO» при загрузке. В конце код проверки схемы из файла до обновления базы, сводная таблица и чеклист.
16.10.2026 511 Konstmax13 2
Инструментарий разработчика Нейросети Рефакторинг и качество кода EDT Разработчик 1С 8.3 1С 8.5 1С:Бухгалтерия 3.0 Бесплатно (free)
Как ИИ-агент (Claude Code) работает в живом EDT-проекте 1С:Бухгалтерии КОРП 3.0: из чего собрать стенд с MCP-сервером для EDT, как ставить задачи агенту, где он ломает проект и какие проверки это ловят. Реальные случаи: рукописные метаданные, ронявшие конфигуратор; четыре дня зависшего обновления из-за порядка блоков в Rights.rights; ошибки, которые EDT пропускает, а платформа нет; сплошная сверка вместо «вроде работает». В приложении шаблон CLAUDE.md, шаблон правила, чеклист перед обновлением базы и скрипты проверки ролей и схем СКД.
15.10.2026 3451 Konstmax13 11
Рефакторинг и качество кода Тестирование QA Разработчик 1С 8.3 Абонемент ($m)
Инженерный анализ влияния (Impact Analysis) при изменении общего метода в 1С:Предприятии: почему штатный поиск ссылок скрывает 99% зависимостей и как обратный обход графа вызовов выявляет 370 скрытых потребителей на глубине 3 уровней. В статье — верификация сквозной цепочки обмена с маркетплейсом; в архиве-компаньоне — автономный BFS-анализатор на Python, слепки графа и план регрессионного тестирования.
1 стартмани
12.10.2026 320 Ninel_S 0
Про копипаст - я даже не знаю, вы это серьёзно?
действительно, использование одного и того же обработчика из общего модуля для проведения разных документов существенно усложняет изменение без нарушения работы всех механизмов проведения, ссылающихся на общую процедуру. Поэтому разработчик должен хорошо подумать над тем, как должна выглядеть эта глобальная процедура, какой массив параметров передается на входе и выходе. В большинстве случаев проблема не в общей процедуре как таковой, а в логике ее работы. очень часто вижу говнокод от самой 1С, где в общих процедурах массив переменных обрабатывается в контексте данных документа или еще хуже, формы.
Не покидает ощущение, что это троллинг, а не всерьёз, так как примеры из разряда крайностей.
Если это троллинг, то не хватает предложения вообще отказаться от общих модулей. И ссылки на партнёрский форум, где Вы предлагаете это сделать разработчикам типовых конфигураций, а они записывают Ваше пожелание ))
И откуда взялась цифра 99%? Почему не 91%?
Возьмём ваш же пример. В типовых конфигурациях, по крайней мере семейства ERP, контроль остатков построен очень хорошо. Метод ПроведениеСервер.ВыполнитьКонтрольРезультатовПроведения - это ядро. Модификация, как правило, делается в одном месте конфигурации. По каким регистрам выполнять контроль при проведении конкретного документа определяется в методе СформироватьСписокРегистровДляКонтроля() модуля документа.
По поводу наименования переменных есть соглашение и если не включать дурачка, приводя в качестве примера тавтологию, то его следует придерживаться. Тавтология также не рекомендуется в соседнем разделе. Поэтому приводить тавтологию в качестве примера того, к чему может привести разработка по стандартам, также некорректно.
Немного жаль, что это не троллинг. Было бы забавно )) Но своего читателя Вы найдёте конечно )
//Формирование движений по регистру
//Блокировка
//Запись движений по регистру
//Контроль отрицательных остатков
Ну не может эта кость просто так выпасть.
Вот по приведенной ссылке сказано, что имена переменных нужно образовывать от предметной области, чтобы было понятно, на кой черт она нужна.
Это, однозначно, не плохо. Но если предметной области нет? Вот у меня есть запрос, который возвращает кучу интересного. И нет там предметной области - там совокупность предметов, явлений и прочего. Почему бы мне не назвать выборку "Выборка", а выборку второго уровня - "Выборка2"?
Или, например, у меня есть универсальная процедура для работы с деревом. Она рекурсивна, в нее передается произвольное дерево. Почему я не могу итератор назвать "ст"? Для меня это очень хорошо и предметно говорит о строке дерева, но при этом мне не нужно писать длинные слова "СтрокаДерева", т.к. внутри у меня есть много всего интересного с этой строкой.
Притягивать имя переменной за уши к предметной области иногда разумно, особенно начинающим программистам. Но далеко не всегда это оправдано, т.к. в большом и сложном коде мне куда проще разобраться при наличии в итераторах вложенных циклов индекса вложенности (например "ст3"), чем в случае, если итератор будет называться по предметной области (СтрокаДерева -> ПодстрокаСтрокиДереваПервогоУровня -> ПодстрокаПодстрокиДереваВторойУровень - разработчик пока читать эту муть будет - помрет сто раз).
НО! Всегда плохой код можно прикрыть высокими стандартами разработки. К сожалению не нашел примера кода, чтобы посмотреть, на сколько он хорош по существу, а не по стандарту )))
Мне не лень писать слова полностью - слепой десятипальцевый и автодополнения рулят. Мое мнение - что переменные и методы с полными именами (но максимально короткими, исходя из контекста) читаются как раз легче и быстрее, чем с сокращениями. При "тяжелом" контексте "вживаться" в кучу сокращений сложно. Особенно если эти сокращения придумывал не ты :) Мозгу приходится делать маппинг имен переменных на реальные сущности. А я люблю, чтобы код читался как проза и даже комментариев не требовалось. Комментарии в основном для описания работы блоков использую, чтобы навигацию по бизнес-логике можно было делать быстро, даже не вчитываясь в код.
Я вообще считаю, что выбор имен - это своего рода искусство :) Потому что в идеале имя переменной должно быть без сокращений, но при этом не слишком длинное. А для этого нужно изящно учитывать контекст и постоянно контролировать читабельность. С именами методов легче - им можно и подлиннее/пополнее имена давать. Ессно, общепринятые сокращения или принятые в контексте кодируемой бизнес-логики использовать можно. Читабельность - главный критерий. Что такое читабельность? Читабельность - это насколько мало придется морщить мозг вашему коллеге (не вам!), разбирая ваш код.
Да, важное дополнение - все вышесказанное касается кодирования бизнес-логики. На математические и системные алгоритмы это ессно нет смысла натягивать. Но мы же про 1С говорим. А 99,99% кода 1с-программиста - это чистая бизнес-логика.
ЗЫ: да, а еще я не люблю называть результат результатом, а люблю называть рез'ом, то же самое с "ДополнительныеПараметры" - слишком длинно. Достаточно "доп". Если кому-то такие сокращения непонятны, то я просто снимаю шляпу перед интеллектуальной нищетой этих товарищей.
Избегаю и там тоже. Если это временная переменная в текущем скоупе, добавляю впереди слово "Текущий"/"Текущая".
Если это итератор - стараюсь именовать так, чтобы можно было понять, что он итерирует.
ЗЫ. Всегда пишу полностью "Результат" и "ДополнительныеПараметры" :) Я снисходителен к чужим слабостям :)
Вот программист сел, полчаса посидел и избавил десять(сто,тысячу, сто тысяч) человек от необходимости выполнять тупую работу.
Но этот ножик заточен с двух сторон. Программист сел, полчаса посидел и создал для десяти(ста,тысячи, ста тысяч) человек необходимость выполнять тупую работу.
У каждого программиста свое сальдо. Оно может быть как дебетовым, так и кредитовым. Подумайте об этом.
Согласны?
Вы любитель натягивать сову на глобус (сводить все трейдоффы к крайним случаям). Только время потратим и все равно при своем останемся.
НО. Если пользователь заказал и ему сделали изменение типового документа, то в моем случае (когда алгоритмы дублируются) пользователь тоже может легко обновиться без программиста. Он просто снимет галочку с измененного документа и все.
Скажете, что обновление может потребовать внесение изменений в кастомизированный документ?
А вот сядьте и подсчитайте - как часто это происходит. У меня есть на поддержке одна КА. Там РТиУ изменен. Третий год снимаю галочку, и ничего. Работает, как работало.
P.S. 10 000 и 10 - почему именно так и очень часто? Это какие-то сакральное числа?)
А кто такой Максим?
Типа:
Все говорят, что "копипастить" нельзя,
Все говорят, что "копипастить" нельзя,
Все говорят, что "копипастить" нельзя,
А я говорю, что буду.
На мой взгляд, пример не самый подходящий, не говорит о сложности доработки. Поправьте меня, если я ошибаюсь, но задачу в приведенную Вами можно решить подписками на события буквально за минуты.
Про обновление - тут все таки стоит указывать контекст...Например, раз разобравшись в параметрах формирования движений Учета затрат(УПП), потом совершенно не составит труда поддерживать этот функционал. Зато можем надеется, что после изучения механизма, наш специалист поддержки узнает, что есть что-то большее, чем примеры из методички, а далее сможет выработать навык работы со сложным кодом.
В целом, Ваш пример о частной, мелкой задаче. Давайте попробуем рассмотреть что-то покрупнее, что будет касаться не только одного реквизита одного из документов? Боюсь, вывод может оказаться не таким однозначным как сейчас Вы привели))
Насчёт удивить - согласен. А вот по поводу возмутить - скорее, наоборот.
// то он нисколько не потеряет в читабельности.
В читабельности - может быть.
А вот в понимаемости - не думаю (мягко говоря)!
P.S.
Это откуда такая мысль ?
Еще я в комментариях в коду описываю бизнес-логику (что конкретно эта фигня должна делать и зачем это нужно). И не вычищаю рабочие комментарии описывающие поведение этого куска кода. Заглушки и служебные комментарии вычищаю.
И еще я стараюсь делать свой код дружественным к читателю, а не к платформе или железу. Будут проблемы с быстродействием, буду их решать - не вылезут такие проблемы - не буду решать. Хаз, хаз и в продакшен. Ну вы поняли.
Все из-за того, что мне скорее всего и придется свой код модифицировать. Не всегда получается у живого человека с первого раза получить исчерпывающее описание нужного ему рожна.
Меня чужой говнокод не напрягает, и я своего тоже не стесняюсь. Работает - не трогай! Вот и все что могу сказать про эти "coding standards".
Вообще, стандарты, которых стоило бы придерживаться при программировании, достаточно просты и сформулированы уже не менее тысячи лет логиками древности:
1. Оккам - не стоит плодить сущности без необходимости. Если они есть - код, каким бы красивым ни был, - не так хорош, как без них. И чем больше бессмысленных сущностей - тем хуже код.
2. Вместе с тем лучшее - враг хорошего. Да, Шекспиры и Вольтеры жили чуть позднее, но первоисточник подобного подхода сокрыт временем куда более древним. Данный момент может вступать в противоречие с первым пунктом, но золотая середина всегда разумнее бесконечной замороченности на тему поисков лишнего. Сделай хорошо с может быть небольшим количеством лишнего - и это будет куда лучше бесконечного выкидывания лишнего из кода до передачи его в "продакшн".
3. Все гениальное - просто. Этак Геббельс перефразировал (упростил) фразу да Винчи, который тоже, предположу, не сам оное придумал. Отсюда как бы мораль: не усложняй простое, старайся упростить сложное.
4. Глаза боятся - руки делают. Главное - начать. Ну и сотня похожих фраз. Тут мораль проста - лучше начать делать что-то, чем год думать о том, как "упростить". Часто за год все сильно усложняется, т.е. если не делать - не перейдешь к отладке, которая и занимает основное время разработки. Все эти TDD и прочие тесты - это попытка вкорячить отладку в код, автоматизировать ее каким-то образом и потом передть обратно в виде многостраничных инцидентов. Тоже, конечно, вариант.
5... Могу много написать, но может быть потом статью накатаю.
Боюсь!
Одна моя статья средней руки вон как вас покоробила. Боюсь дальше что-то писать, вдруг вы от злости или зависти (так и не понял, чему завидовать, но все симптомы на лицо) ещё что-то непоправимое с собой сделаете или, не дай Бог, ещё пачку статей с вашими недоценёнными для своего времени мыслями напишете! Да и зачем из пустого в порожнее переливать? Для этого у нас есть вы)) "Одну статью заминусовали - я ещё одну напишу, такого же содержания. Эта не вылезет - ещё одну. Буду писать, пока они от страха перед новыми моими статьями не будут старые бешено плюсовать!" А мы ведь будем! Не дай боже ваш код мне ночью приснится - да я для этого сколько скажете вам плюсов поставлю, только бы вы перестали))
Один стартмани - это деньги или не деньги?
Но пикантность в том, что частично постулаты с этой статьей пересекаются, поэтому я про нее и вспомнил :)
не равносильно исходному при
ПН = Истина; ПНП = Истина; РН = Истина; РНП = Ложь;
Шаблон = ((ПН И ПНП) И (РН И РНП)) ИЛИ (( ПН = Ложь ) И (РН И РНП)) ИЛИ ((ПН И ПНП) И (РН = Ложь));
Сообщить("Шаблон = " + Шаблон); // Ложь
Выражение1 = (ПН И ПНП) ИЛИ (РН И РНП);
Сообщить("Выражение1 = " + Выражение1); // Истина
// как и при ПН = Истина; ПНП = Ложь; РН = Истина; РНП = Истина;
Показатьз.ы. не особо силен в БА поэтому лучше чем (aa1bb1)+(!abb1)+(!baa1) => bb1(!a+a1) + !baa1 ничего в голову не пришло
или так (НЕ РН ИЛИ РНП) И (НЕ ПН ИЛИ ПНП) И (РН И РНП ИЛИ ПН И ПНП)
Клавишу "шифт" так и не завезли?
По этому видимо и не светит.... стать руководителем такой ответственной конфигурации... тут бы шифт на клавиатуре освоить и имена переменных.
2)Автор поставляет материал для очередного продолжения "Ректального программирования". Спасибо ему!
3)
А я бы на йух послал немедленно и свалил.
А что по-вашему важнее? Сделать продукт, который будет удобен узкой группе разработчиков продукта или тем, кто его поддерживает?
ТОЛКОВО написанная конфигурация удобна для всех :
1)разработчиков
2)поддержки
3)главное - пользователей.
Ни одной типовой конфигурации, толково написанной, я не видел. Думаю, там задачи другие - не сделать толковое ПО, а срубить бабла.
Иногда бывает конфликт интересов. Я и попытался до вас этот момент донести.
Если разработчики конфигурации пять раз скопируют код, тогда им будет труднее его поддерживать (а кстати, насколько сложнее, в самом деле? есть же автоматический рефакторинг), зато специалистам "последней мили" будет значительно проще. Весь вопрос в том, что имеет смысл экономить. Человеко-часы разработчиков или человеко-часы специалистов поддержки? Что более оправдано экономически и что более экологично?
Вопрос в том, кто ими поступается. Работа по найму предусматривает что вам платят за то, чтобы вы соблюдали интересы других людей.
А то что бывает "иногда" - это те ситуации, когда работник не исполняет свои обязанности.
Проблема в отношениях внедренцы 1С и разработчики 1С - это непонимание кто кого нанял.
Нас наняли как торговых представителей фирмы 1С (обучили, выдали сертификаты и отправили на предприятия) - мы продаем/модифицируем то что наш прямой работодатель разработал. Такое отношение и приводит к процедуре в глобальном модуле "проведение всего - если это накладная тогда так, если это банковская выписка тогда этак". В этом случае можно копипастить в каждый документ одну строчку - глПроведение.ПроведениеВсего(Объект).
Внимание, вопрос! Компания должна стремится к повышению производительности труда или к понижению?
И планируете информировать фирму 1С о том что потратили на доработку типовой конфигурации 1С в соответствии с пожеланиями клиента 10 минут, а на то, чтобы разобраться с кодом типовой 2 года?
И вам удастся убедить фирму 1С в том, что клиент должен заплатить за 10 минут исходя из минимальной месячной оплаты труда (11тыс/158 часов)/60*10, а за 2 года - вы согласны получать стипендию студента техникума?
Можно взять актуальную типовую. Провести рефакторинг. Вернуть бизнес-логику из общих модулей в модули документов. И у вас будет в принципе та же самая конфигурация. Но значительно лучше.
Или значительно хуже. Зависит от того как вы относитесь к бесконечной генерации бессмысленной деятельности.
Но если мы оцениваем только наши собственные 10 человекочасов при наличии готового и работающего продукта, то вы правы.
Глупо заглушать экскаватор под парами и браться за лопаты, только потому что заканчивается бензин.
Если поддержкой занимается квалифицированный специалист - такой разберется в любом коде. А без знаний и опыта даже простейший кусоу кода будет вызывать затруднения.
Теперь про важность )) важна масштабируемость, а не какие то там группы для кого ВЫ пишите. Решение разрабатывается для бизнеса, а не для групп разработчиков. Отсутствие масштабируемости приводит к нехорошим последствиям по более серьезной и глубокой доработки решений.
ПыСы: а вот руки надо за копипаст прям под корень;)
Проблема нашей ситуации в том, что у нас только одна компания. Она может себе позволить вести себя неэкологично. И позволяет.
Представьте себе две компании и два продукта. Одна и та же задача клиента для одного продукта решается ручками пользователя. А другая только тех поддержкой. Как долго будут конкурировать эти два продукта? И что в принципе вторая компания может противопоставить?
Для бизнеса чем быстрее, тем лучше, и это понятно, но ...
Все манипуляции с кодом, которые мы делаем, мы делаем только для себя, а для бизнеса слово "рефакторинг", к примеру, ни говорит ни о чем, за то нам о многом и добавляет только трудности нам, в том числе возрастает вероятность ошибки из разряда "забыл что еще надо поправить похожую логику метода в 10 модулях ..."
А противопоставить есть что - озвучивать реальные сроки выполнения задачи, с учетом всех требований к разработки решений.
Такой способ программирования подходит если внедрили что-то крупное, а оно не взлетело, и надо быстро подправить костылями, чтобы пользователи сейчас начали работать, а ты уже вечерком сделаешь как надо.
Логика работы любого документа - высокую.
У меня его утверждения вызывают отторжение на подсознательном уровне.
Но его хитрый замысел я скорее всего понял, поэтому ставить плюс не буду.
Скорее было бы хуже чем лучше, если бы я такое в увидел типовых конфигурациях.
Кроме того, более глубокая вложенность процедур и функций очень положительно влияет на кастомизацию при помощи расширений.
Кроме того глядя на стремление кодинга в сторону функционального программирования, без осмысленных названий будет вообще никуда. Тогда уже и сам кодинг нужно тоже перекладывать на машину.
В УНФ в заказе есть несколько вариантов заказа.
Есть версионирование БСП и даже может быть появится история в платформе.
Но, когда бухгалтер видит свежеизмененные документы (которые в бух.учете необходимо отразить повторно) он теоретически может узнать по какой версии отражение происходило, и чем эта версия отличается от последней и только в том случае, если это версионирование включено.
Но реальной привязки версии основания к накладной или версии любого бухгалтерского документа к отражению нет. Зато есть куча спотыкалок, например, если у документа есть корректировка, его уже нельзя изменить. Вероятность кастомизации высокая, а 1с этого не поддерживает.
Почему так, как вы думаете?
А как красиво получается, открыл накладную, перешел по ссылке заказ, открывается заказ той версии по которой сделана накладная и в подзаголовке написано (как в консультанте) вы открыли не последнюю версию. Но это уже не 1С.
Если ((ПН И ПНП) И (РН И РНП)) ИЛИ
(( ПН = Ложь ) И (РН И РНП)) ИЛИ
((ПН И ПНП) И (РН = Ложь)) Тогда Нет. Это - плохой код. Вместо трех строчек условий следует оставить одну с одним "ИЛИ".
какую строчку нужно ввести , эквивалентную исходному выражению ?
Вставил комментарий в статью. Спасибо за поправку.
((ПН И ПНП) И (РН И РНП)) ИЛИ (( ПН = Ложь ) И (РН И РНП)) ИЛИ ((ПН И ПНП) И (РН = Ложь))
<=> РН И РНП И (НЕ ПН ИЛИ ПНП) ИЛИ НЕ РН И ПН И ПНП
<=> (НЕ РН ИЛИ РНП) И (НЕ ПН ИЛИ ПНП) И (РН И РНП ИЛИ ПН И ПНП)
последние 2 все таки короче
Это просто жесть! Вспоминается фильм "Зелёный слоник". С такой гордостью вывалить ЭТО прямо в лицо неподготовленному читателю...
врег(сокрлп(св.свойство))
и
врег(сокрлп(св.значение))
Мне интересно, кто-то вообще обратил на это внимание?
Такое чувство, что все к этому привыкли настолько, что не замечают.
Я даже не вчитывался особо, мне показалось там то ли машинный код, то ли обфусцированный. Всё мелкими буквами, ни одного пробела. Странно, что отступы использует.
Автор, перестаньте использовать отступы! Вы ломаете всё погружение в матрицу!
А так, это некий парсер некоей грамматики, я их даже с прищуреным глазиком узнаю.
Кстати, понятно теперь утверждение автора, о сложности изготовления регистронезависимого парсера. При таком подходе действительно сложно.
Насчет нормализации вы абсолютно правы. Я этот момент изначально упустил, потому что был сосредоточен не на тексте.
Скажите: один стартмани - это деньги или не деньги?
Я бы обратил внимание на то, что некоторых разработчиков бросает в крайности и религиозные войны. Адекватного опытного специалиста характеризует его умение менять баланс в зависимости от контекста.
Был у нас один программист.
Написал он отчет.
В этом отчете около 10 колонок и 40 строк.
Каждая строка - это отдельный показатель, который имеет свои особенности в расчете.
Что сделал программист
Написал 40 процедур, в каждой из которых небольшой запрос с двумя временными таблицами и заполнение строки отчета.
Каждая из 40 процедур отличалась от других на чуть чуть. Где-то дополнительное соединение, где-то по-другому рассчитываются поля.
И мне прилетает задача - добавить колонку в этот отчет.
Вопрос к автору: где тут выигрыш в производительности для поддержки?
Но это, ИМХО, какой-то уж очень специфичный пример. Такого в жизни вряд ли много.
С другой стороны, автор, опять же ИМХО, не советует всегда делать сто процедур - по штуке на каждую сущность. С другой стороны, когда у нас происходит контроль ввода пользователя в поле, то для каждого документа каждое поле контролируется индивидуально даже в типовых.
ну если как рекомендует автор, вместо одной процедуры проведения в общем модуле скопировать этот код в модуль каждого документа, который двигает наш регистр, то можно попасть на аналогичную проблему.
Если потребуется, например, добавить ресурс или реквизит в регистр, то придется лезть с исправлениями в N документов.
Так вот, любая дописка, которую изначально оценивали в полдня, выливалась в неделю, потому что надо выцепить все куски кода, где есть копипаст, и поправить их, понять что находится в поле выборки под названием "Поле4", и понять замысел создателя. А потом находишь, что просто так в эту хрупкую экосистему ничего не добавить и встаешь перед выбором - дальше на этот карточный домик пытаться надстроить еще этаж или снести все и построить из кирпичей...
ПС
Неиспользование шифта - это просто жесть. Я обычно такое называю "синдром ленивого мизинца". Порождает такие шедевры, как "типполисапуст" и "задень". А в сочетании с лютыми сокращениями, получаются "предвподнямики"!
Аааааааа! Спасибо за поднятие настроения :)
- никаких ложных абстракций
- никаких проблем с нумерацией
- никаких проблем вообще с придумыванием имен. Нужна новая переменная - сгенерил по месту и все.
Начнешь использовать Ио в качестве счетчика повсеместно, потому что короткий. И все. Хана. Глаз замылится.
То, что организация смогла пережить это поделие - в каком-то смысле заслуга этой мегаконцепции. Ведь первоначальное набрасывание говнокода стоит очень дешево и делается очень быстро. Организация в итоге сэкономила кучу денег, получила конкурентные преимущества, выжила на рынке и смогла нанять новую команду, которая построит новый мир на обломках старого :)
И дальше, что можно добавить в процедуру списания товаров с регистра остатков такого для одного документа, что не будет использоваться при списании с этого же регистра другими документами? Я вобще за то, чтобы функционал работы с регистрами хранить в менеджере этого регистра, и тогда получается красивый и логичный код вроде
РегистрыНакопления.ОстаткиТоваров.СписатьПоФИФО(ссылкаДок)Просто взяв за привычку вместо Н1, Н2, Н3 писать что-то вроде номСклада, номТовара, номПартии, я уже существенно облегчил для себя понимание какой итератор куда ставить. Ведь если я вижу в коде текСклад = спСклады.ПолучитьЗначение(номТовара) - это сразу бросается в глаза, то текСклад = спСклады.ПолучитьЗначение(Н1) - можно пропустить, ничего не заподозрив.
Коллекции называть с префиксами "м, тз(т), дз(д) , стк , ств " . Хоть это и не рекомендуется , но по мне так здорово упрощает чтение текста .
Итераторы - если связаны с коллекцией называть однообразно напр СтрТаб , Элемент , ЭлементМассива , ЭлементСоответствия итп. , если нет - буквы русского языка , которые не перепутаешь - Ц , Й , Ъ и т.п.
Для обхода дерева часто пользуюсь номерами Уровень1 , Уровень2 с комментариями
Для Каждого Уровень2 из Уровень1.Строки Цикл // Документы или так
Для Каждого УровеньДокументы из УровеньНоменклатура.Строки Цикл Имена функций обычно начинаю со слов Получить , Вернуть и т.п. ,
Имена процедур , соответственно , Выполнить , Расчитать .. и т.п
нижний регистр отлично подходит для шаблонов , чем нелепее название , тем лучше
Например у меня есть такие : покаци , дляка , наклинасер , собить и сопля ;)
Да мы помним, бережёте суставы от лишних нажатий.
Но скорее всего машинопись не освоили... потому что читать потом
Вот вам нравится:
КонецЕсли
А мне нет. Строка прыгает, скачет, отвлекает, да и для зрения вредно ))) То ли дело:
конецесли
Ровно, спокойно, солидно.
Скорее его полное отсутствие.
Строка легко читается, почему так можете подумать на досуге, если ничего не придумаете то не стесняйтесь спрашивайте, расскажу.
У него в принципе отсутствует проблема вычленения слов из строки одного регистра.
Потому что имена переменных априори не должны нести смысл (если вы помните этот его постулат), а системные конструкции просто нет смысла читать - они должны выхватываться мозгом программиста целиком, любовно выращенными для этого нейронами. Вот и получается, что шифт топтать - только код портить.
Дело в том, что я и есть тот самый "специалист поддержки", для которого якобы стараются. И это очень вымораживает, когда тупую ошибку нужно исправлять в скопипащенном ИДЕНТИЧНОМ коде в десятке модулей документов, который выкинуть в общий модуль было бы проще простого.
Хуже только когда в половине способов сделали выгрузкой массивов с перекидкой элементов между ними, а во втором сделана тройная вложенность циклов с множественными вызовами запросов на разных уровнях этих циклов (часть результатов которых даже не анализируется) - то ли автор не решил как лучше и решил сделать два параллельных варианта, которые произвольным образом тиражировал в новые документы, то ли решил что придумал более кульный способ, но обломался делать рефакторинг уже написанных документов, то ли работала группа авторов, которые не общались между собой.
И еще хуже, когда авторы кода ставят себя выше типового стандарта (зашитого в шаблонах автодополнений и описанного на ИТС) и пишут все ключевые слова маленькими буквами и делают отступы произвольным образом:
если нс<>неопределено тогда
новзн=нс.значение[имятаблицы].добавить();
записатьвпамять(св.свойство,новзн);
конецесли;
иначе
новзн=ВычислитьЗначение(св.значение);
записатьвпамять(св.свойство,новзн);
нсв=нкорсв.строки.добавить();
нсв.свойство=св.свойство;
попытка
нсв.значение=новзн.ссылка;
исключение
нсв.значение=новзн;
конецпопытки; ПоказатьЕще выбешивает, что авторы подобного кода делают вид, что знают про существование разных типов, только они не слышали ни про ТипЗнч(), ни про Тип(), ни про метод объектов Метаданные(), ни про глобальное свойство конфигурации Метаданные. Когда такие люди пишут только для Российской Федерации возможно ничего страшного, но как только они начинают выпускать релизы для СНГ, то якобы протестированные версии, выпущенные в тираж и установленные покупателям, начинают падать с ошибками. Потому-что в конструкциях типа:
иначеесли лев(метаимя,10)="СПРАВОЧНИК" тогда
новзн=справочники[сокрлп(сред(метаимя,12))].создатьэлемент();
конецесли;
не происходит срабатывание, потому-что внезапно лев(метаимя,10)="ДОВІДНИК.В" (для справочника валют).
Ну и конечно лучи ненависти проверяющим из 1С, которые берут такое говнище на проверку и одобрительно вешают ярлычок "".
Если Строка(запись.ВидДвижения) = "Приход" ТогдаИ конфигурацию при этом не ставили за рубеж. Всего-то навсего обновили платформу и вместо русского языка поставили украинский.
Берешь себе копию базы, тестируешь - нет ошибки. У клиента ошибка. Код идентичен, данные идентичные.
Я бы сразу ушел с такого проекта - он бы никогда не взлетел с таким подходом, а писать мертвый проект нет желания.
И эту статью надо зиминусовать и чтобы следа не осталось.
Понаплодятся сейчас говнокодеры, после прочтения.
Проблема в том, что пользователей интересует совокупная стоимость владения продуктом, в которую входит стоимость сопровождения, доработок и оптимизаций под постоянно изменяющиеся требования (такая уж специфика). Учитывая стоимость работы программистов речь идет об очень крупных суммах и серьезных конкурентных преимуществах. Говнокод дает "ускорение" ровно один раз. При первом его применении. И ложится техническим долгом, который увеличивает стоимость всех последующих изменений и доработок. Злоупотребление говнокодом педалирует наступление ситуации, когда продукт становится фактически непригоден для развития. И это очень неприятный и очень дорогой для компании момент. Фактически говнокодер способен нанести компании громадные финансовые убытки на длительной перспективе.
Если пользователи работают с "замороженным" продуктом при неизменности требований к нему и с устраивающим их результатом - то ессно все равно, какой там говнокод внутри.
Это отчасти пересекается с темой будущей статьи, поэтому приведу тезисы кратко, чтобы не превращать комментарий в отдельную статью
Изложу важные наблюдения, часто упускаемые разработчиками, но верно подмеченные автором. Кроме позитивных моментов также позволю себе критику там, где автор делая верное наблюдение, скатывается к спекулятивным выводам.
1. "Понятные" имена переменных. Это палка о двух концах. Когда вы создаёте подобные переменные, вы фактически привязываете форму кода к его семантике, создавая таким образом, неявную зависимость, нуждающуюся отныне в поддержке. Получается забавный парадокс, когда мы упрощая код с целью облегчения его поддержки, на самом деле его усложняем, за счет взятия обязательств по сопровождению новых зависимостей. Пример с переменной СуммаПервогоИВторого является наглядным примером, когда неявная зависимость не находится на поддержке. Таким образом, поддержание понятных имен переменных сродни задаче по поддержке актуальных комментариев и документации к проекту. В большинстве случаев, это сложно автоматизируется и требует отдельных усилий.
НО! Если осознавать наличие этих зависимостей и брать на себя их поддержку, то сопровождаемость кода однозначно повышается. Использование обезличенных переменных там, где они имеют вполне конкретный смысл, это и есть очевидный ректальный подход к программированию. Таким образом, автор делает неверный вывод из совершенно верного наблюдения.
2. Размышления о копипасте. Я полностью согласен с утверждением, что бездумное использование Code reuse есть очевидное зло. В некоторых случаях, прямое копирование фрагментов кода оправдано. Некоторые проекты сознательно развиваются именно путем копирования. Поясню мысль. В биологии есть термин "конвергентная эволюция". Конвергенция здесь, обозначает общие формы для двух совершенно несвязанных биологических видов развивающихся в сходных внешних условиях. Нужно понимать, что сходство актуально лишь для текущего момента времени. И возможно в будущем, пути развития этих видов разойдутся, а классификация по морфологическим признакам устараеет. То же самое относится и к коду. Если у двух не связанных участков кода существует сходная реализация, то не стоит реализовывать общую реализацию для двух объектов, сблизившихся лишь в текущий момент времени.
НО! Копирование фрагментов кода внутри одной функции или внутри одного модуля/подсистемы, должно предваряться оценкой обоснованности такого действия. Если при изменении бизнес-логики вам придется править все эти десятки копий кода, то такой подход с большой долей вероятности приведет к превращению поддержки проекта в непрерывный кошмар.
3. Излишная абстракция. Согласен, что в отдельных случаях уровень абстрагированности обработчиков данных слишком высок. Не вполне согласен, что эту критику можно применить к типовым конфигурациям, но зачастую видел подобное в полностью самописных конфигурациях никогда не планировавших стать тиражными. Изолированность компонентов есть почти повседневная необходимость для сложных тиражных продуктов, и далеко не всегда применима в нишевых и корпоративных программах.
НО! Если абстракцию применять как способ изоляции различных слоёв логики, то абстракция обоснована и необходимо. Я достаточно подробно описывал механизм работы абстракции в своей статье о парадигмах программирования, поэтому не буду повторяться здесь все выводы.
Таким образом, я снимаю шляпу перед автором, за его наблюдательность и чуткость. Это очень хорошее качество для исследователя и редко встречается. Но однозначно против спекулятивного подхода к выводам из этих наблюдений. Статья выглядит как попытка заработать дешевую славу на громких заголовках. Для исследователя это не вполне этично, если он не планирует делать карьеру в шоу-бизнесе.
В сумме за наблюдения и отличные "лакмусовые" обсуждения статье ставлю плюс.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 979323
Создание 22.01.19 11:34
Обновление 22.01.19 11:34
Просмотры 11051
Загрузки 0
Рейтинг
24
Комментарии 183
Код открыт Да
Рубрики Рефакторинг и качество кода
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
