Наверное, мало кто будет спорить с тем, что программа должна быть понятной не только компьютеру, но и человеку. С увеличением сложности и времени жизни проектов легкость понимания кода становится все более критичной. Действительно, программа, которая пишется множеством людей и может неоднократно изменяться, должна быть легко читаемой, иначе изменения и исправления ошибок могут привести к потере контроля над кодом и краху проекта. Возникает проблема менеджмента кода, т.е. поддержания кода в работоспособном и понятном состоянии. Каковы основные принципы такого менеджмента? Пойдем «от печки». Что такое язык программирования? Это прежде всего язык, т.е. система, когда совокупность символов (слово, предложение) отображает какой-то, пусть и виртуальный, но объект или действие над ним.

Нам повезло, мы программируем под 1С, где объекты и действия обозначаются словами русского языка. Это облегчает выполнения главного требования для понятной программы – самодокументируемости, т.е. названия должны соответствовать тому, что за ними стоит.

Основной принцип здесь таков – глядя на идентификатор процедуры или функции должно быть возможно сообразить, что она делает. Внимание! Главное не только и не столько «как она устроена» а «что делает»! Так же и с объектами – главное отразить их смысл в контексте решаемой программой задачи, а внутренние отношения и устройство уже вторичны. (не «МассивСтрок» а «СтруктураШапкиДокумента») Ведь придумывая имена-идентификаторы, мы «конструируем» язык, на котором нам потом описывать предметную область, описывать алгоритм решения задачи. И, когда идентификаторы подобраны правильно, решение задачи будет написано «почти по-русски» и не будет требовать каких-то дополнительных пояснений. Подробнее о стандартах именования 1С можно прочитать здесь, они вполне логичны.

Другое очень важное требование нормального языка – однозначность. Т.е. одним и тем же словом не должны называться разные сущности, и одинаковые сущности должны называться одинаково. Опускаясь с языковедческих высот на программистскую «землю» получим простейшие принципы:

·  При изменении действия процедуры или функции нужно менять и ее название. То же относится и к переменным с объектами. Да, это может быть затратным – но один раз аккуратно сделать поиск/замену проще, чем много-много раз обращаться к описанию, чтобы понять, почему, блин, делается совсем не то, что заявлено!

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

·  Прежде чем завести новую переменную, новый объект или процедуру нужно всегда проверять, есть ли уже что-то похожее. Возможно, работать не придется и уже все сделано. Также возможно, что потребуется лишь незначительное изменение существующего кода.

Другое, очень важное требование языка – обозримость. Предложения в русском языке очень редко бывают длиной в страницу текста. Почему? Возможности человеческого внимания ограничены обычно магическими цифрами 7 и 3. Человек с нормальным вниманием (а мы совсем не сверхлюди, хоть и программисты с сертификатами) легко воспринимает 7 объектов или 3 их сочетания. Откуда такие цифры? Как вы понимаете, в двоичной системе сочетания 3 объектов как раз дадут 8 комбинаций, так что это, в общем-то, одна и та же цифра. «Оперативная память» человека имеет объем примерно равный 8 ячейкам памяти. Хочешь не хочешь, от этого приходится плясать. Программистский же вывод таков:

·  Блок кода длиннее 7-10 строчек должен оформляться в отдельную процедуру или функцию, с названием, которое описывает, что, собственно, этот блок делает.

·  Передавать в процедуру или функцию более трех параметров очень не рекомендуется. Даже три простейших булевских параметра это восемь их сочетаний, обработку которых необходимо предусмотреть! Возможно, стоит объединить несколько однотипных параметров в структуру или просто передать параметром объект, из которого они взяты. Также возможно стоит вовремя остановиться и перестать городить что-то большое и универсальное. Может быть, лучше разбить процедуру на две-три более мелких?

·  Если в операторе сравнения (Если … Тогда) используется больше трех условий или же они сложные, нужно сделать на их основе функцию или даже две-три (как положено, с «говорящими» именами) и использовать при сравнении результат их работы. Понятно, что перечисленные рекомендации не догма, а лишь повод к размышлению. Можно нагородить и однострочный код так, что его невозможно будет понять. Главный принцип здесь таков – если код нельзя понять с первого взгляда, а особенно если захотелось написать комментарий, поясняющий его работу, значит, этот код требует изменения.

Третье, менее формализуемое, но не менее важное свойство кода – стильность. Прежде чем изменять или дописывать чужой код, нужно в него вжиться. Понять, как он обычно манипулирует данными и объектами, как принято в нем делать определенные действия. И делать так же, в том же стиле. Понятно, что не стоит копировать ужасно написанный код, но с таким вообще сделать что-то хорошее трудно. Но если программа имеет хотя бы среднее качество, стоит перенять перед изменением даже ее стиль написания, наименований. Это позволит не отвлекаться потом на мешанину стилей тому, кто придет править код дальше (а возможно и самому через полгода).

Когда же чаще всего вносятся все эти косметические правки в код? В самый светлый момент – когда все заработало! Тут, обычно, радостный программист бросает все «как есть» и убегает дальше. Но стоит потратить 5-15 минут на «уборку рабочего места», структурирование и причесывание получившегося результата, чтобы под результатом не стыдно было подписаться. Нужно еще обязательно отметить, что если код большой или при «причесывании» требуется изменять чужие и не до конца понятные строки, нужно действовать очень аккуратно. Маленькое изменение – тестирование – следующее маленькое изменение. Никогда не надо стирать и переписывать страницы кода, ни к чему хорошему это не приведет! Но при должном внимании и аккуратности задача поддержания изменяемого кода в рабочем состоянии вполне разрешима и даже не требует каких-то значительных затрат.
Главное не давать себе лениться!

Основные методы рефакторинга.

Теперь можно поговорить более строго. Большинство из того, о чем говорилось выше, относится к недавно появившейся технологии программирования – рефакторингу. Рефакторингом кода называется его изменение с целью повышения логичности или понятности без изменения внешнего поведения программы. В модели программирования 1С возможны далеко не все его известные методы, но и оставшихся вполне хватит для того, чтобы сделать код ясным и четким.
Итак, что у нас в арсенале?

·  Переименование. Думаю, здесь можно обойтись без примеров? Переименование просто устраняет несоответствие между названием и содержанием (действием).

·  Выделение процедуры/функции. Выделение блока кода с неявным смыслом в процедуру или функцию
Было

НомерКолонкиБазовый = СоответствиеТиповЦен.Получить(БазовыйТипЦен);

Если НЕ НомерКолонки = Неопределенно

 И НЕ ЭлементыФормы.ТаблицаЦен.Колонки.Найти(\"Цена\" + НомерКолонки) = Неопределено Тогда

{*******************************************}

Стало

Функция ЕстьКолонка(НомерКолонки)

 Возврат НЕ НомерКолонки = Неопределено

 И НЕ ЭлементыФормы.ТаблицаЦен.Колонки.Найти(\"Цена\" + НомерКолонки)=Неопределено;

КонецФункции

{*******************************************}

НомерКолонкиБазовый = СоответствиеТиповЦен.Получить(БазовыйТипЦен);

Если ЕстьКолонка(НомерКолонкиБазовый) Тогда

{*******************************************}

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

Было

Процедура ОчиститьТаблицуОплат()

 ТаблицаОплат.Очистить();

КонецПроцедуры

{*******************************}

ОчиститьТаблицуОплат()

{*******************************}

Стало

{*******************************}

 ТаблицаОплат.Очистить();

{*******************************}

·  Выделение структуры параметров процедуры Если в параметрах нескольких процедур используется один и тот же длинный набор параметров, очень полезно объединить параметры в структуры. Помимо компактности и логичности это даст возможность простого добавления еще одного параметра без переписывания заголовков множества процедур.

Было

Процедура ДвиженияПоРегистрамУпр(РежимПроведения, СтруктураШапкиДокумента, ТаблицаПоТоварам, ТаблицаПоСкидкам,ТаблицаПоТоварамБезУслуг, Отказ, Заголовок)

{***************}

Стало (помечтаем о нормальной процедуре проведения документа….)

СтруктураДанныхДокумента = Новый Структура;

СтруктураДанныхДокумента.Добавить(“СтруктураШапки”,СтруктураШапкиДокумента);

СтруктураДанныхДокумента.Добавить(“ТаблицаПоТоварам”,ТаблицаПоТоварам);

СтруктураДанныхДокумента.Добавить(“ТаблицаПоСкидкам”,ТаблицаПоСкидкам);

СтруктураДанныхДокумента.Добавить(“ТаблицаПоТоварамБезУслуг”,ТаблицаПоТоварамБезУслуг);

СтруктураПараметровПроведения = Новый Структура;

СтруктураПараметровПроведения.Добавить(“Режим”,РежимПроведения);

СтруктураПараметровПроведения.Добавить(“Отказ”,Отказ);

СтруктураПараметровПроведения.Добавить(“ЗаголовокПриОшибке”,Заголовок);

Процедура ДвиженияПоРегистрамУпр(СтруктураПараметровПроведения, СтруктураДанныхДокумента);