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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НомерКолонкиБазовый = СоответствиеТиповЦен.Получить(БазовыйТипЦен);
Если НЕ НомерКолонки = Неопределенно И НЕ ЭлементыФормы.ТаблицаЦен.Колонки.Найти(\“Цена\” + НомерКолонки) = Неопределено Тогда {*******************************************}

Стало

Функция ЕстьКолонка(НомерКолонки)
Возврат НЕ НомерКолонки = Неопределено И НЕ ЭлементыФормы.ТаблицаЦен.Колонки.Найти(\“Цена\” + НомерКолонки)=Неопределено;
КонецФункции
{*******************************************}
НомерКолонкиБазовый = СоответствиеТиповЦен.Получить(БазовыйТипЦен);
Если ЕстьКолонка(НомерКолонкиБазовый) Тогда {*******************************************}

Было

Процедура ОчиститьТаблицуОплат()
ТаблицаОплат.Очистить();
КонецПроцедуры
{*******************************}
ОчиститьТаблицуОплат()
{*******************************}

Стало

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

Было

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

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

СтруктураДанныхДокумента = Новый Структура; СтруктураДанныхДокумента.Добавить(“СтруктураШапки”,СтруктураШапкиДокумента);
СтруктураДанныхДокумента.Добавить(“ТаблицаПоТоварам”,ТаблицаПоТоварам); СтруктураДанныхДокумента.Добавить(“ТаблицаПоСкидкам”,ТаблицаПоСкидкам); СтруктураДанныхДокумента.Добавить(“ТаблицаПоТоварамБезУслуг”,ТаблицаПоТоварамБезУслуг); СтруктураПараметровПроведения = Новый Структура; СтруктураПараметровПроведения.Добавить(“Режим”,РежимПроведения);
СтруктураПараметровПроведения.Добавить(“Отказ”,Отказ);
СтруктураПараметровПроведения.Добавить(“ЗаголовокПриОшибке”,Заголовок); Процедура ДвиженияПоРегистрамУпр(СтруктураПараметровПроведения, СтруктураДанныхДокумента);

Известен такой анекдот. Вызывает профессор-лингвист студента к доске и говорит: «Пиши: Глокая куздра штеко будланула бокра и курдячит бокренка». «Чего-чего?» было спросил студент, но с авторитетом профессора спорить не стал и честно записал эту абракадабру. А теперь, – сказал профессор, объясни – о чем говорится в этом предложении? На студента стало жалко смотреть и лектор сжалился.

- Ну, кто здесь главное действующее лицо?
- Ку… куздра, – промямлил студент
- А какая она, эта куздра?
- Глокая! – уже уверенней произнес студент
- А на кого направлено действие?
- На бокра!
- И что эта куздра сделала?
- Она его будланула! – выкрикнули из аудитории со смехом.
- И штеко, причем, будланула, добавил, улыбнувшись, профессор.
- А вот бокр – он живой?
Студент задумался…
- А! Да! У него бокренок есть!
- У бочки тоже есть бочонок, но это не значит, что она живая. Если бы бокр был неживой, мы бы сказали «будланула бокр», это винительный падеж «кого, что».
Итак, не зная смысла ни одного существительного, прилагательного или глагола мы уже можем достаточно много рассказать о происшедшем. Информацию об этом мы извлекли из вроде бы незначащих вещей – падежей, союзов, окончаний, определяющих отношения между словами в предложении.

Теперь вернемся от языковедения к программированию. При чем здесь Глокая куздра? Много говорилось о том, что названия процедур, функций и переменных должны быть «говорящими» должны соответствовать логике их использования. Но не менее говорящими должны быть и связи между идентификаторами! Даже не зная конкретного смысла программы, можно с первого взгляда увидеть, как она устроена.

Как этого достичь?
Возьмем Глокую куздру.
Но что это? Известно, что Глокая куздра может выполнять несколько действий. Она умеет будлануть, а умеет и курдячить т.е. представляет собой несколько связанных действий. Также известно, что эта куздра именно глокая, т.е. есть изменяемый параметр, явно в природе существуют и другие куздры – неглокие. В 1С логичнее всего оформить нашу куздру как обработку. Ведь бокров она именно «обрабатывает». Теперь, если ввести в тексте программы
Куздра. (с точкой), то система покажет все, что эта куздра умеет делать. Глокая пусть будет реквизитом обработки. Сегодня Куздра будет Глокая, т.е.

Куздра.Глокая = Истина

Дальше возьмемся за бокра. Документ или справочник наш герой, не так важно, т.к. сам он ничего не делает, кроме одного: как мы помним, куздра его будланула. Т.е. явно состояние бокра изменилось, произошло действие! Что у нас отвечает за действие, что в 1С заменяет глаголы? Процедуры и функции. Теперь нужно выбрать, что будем применять. Можно написать

Куздра.Будланула(бокра);

и это будет почти по-русски. Но из этой записи совершенно не понятно, изменился бокр или нет. Опять же, куздра булданула его штеко т.е. с параметром. Получится

Куздра.Булданула(Бокра, Штеко)

Здесь непонятно, кого куздра булданула – бокра или штеко, что является результатом действия, а что – его параметром. Самый правильный выход – написать

Бокр = Куздра.Будланула(Бокр, Штеко)

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

Пока Не Бокренок.Конец() Цикл
  Бокренок = Куздра.Курдячит(Бокренок)
КонецЦикла

Здесь мы выразили непрерывное, повторяющееся действие через цикл (допустив, что прекращение действия зависит от Бокренка. Если оно зависит, например, от Бокра или состояния самой ГлокойКуздры, это тоже можно было выразить). Дальше еще можно добавить связь между Бокром и Бокренком. Оба они бокры! Значит, это можно выразить, объединив их в структуру, что может понадобиться, например, если нужно будет передать куда-то всех бокров скопом, а не поодиночке.

Итого у нас получилось

Куздра.Глокая = Истина;
Бокры.Бокр = Куздра.Будланула(Бокры.Бокр, Штеко);
Пока Не Бокры.Бокренок.Конец() Цикл
  Бокры.Бокренок = Куздра.Курдячит(Бокры.Бокренок);
КонецЦикла;

Конечно, по сравнению с богатством русского языка, в пересказе на макроязыке 1С некоторые нюансы шедевра потерялись, но главная нить по-прежнему вполне улавливается. А значит и в языке программирования операторы отношения и присваивания имеют выразительный смысл, который можно и нужно использовать!

Формализуем правила

ГлокаяКуздра(Бокра, Бокренка, Будланула, Курдячит)

Продолжение