Ректальное программирование: основы для практикующих 1С-программистов

Задача даётся для того, чтобы её выполнили. Если задача выполнена, значит цель достигнута. Не нужно думать о призрачных перспективах, возможностях развития, доработках или переработках. Мы живём в очень нестабильном мире, а жизнь коротка. Незачем думать об оптимизации, производительности, рефакторинге, стиле, стандартах - вдруг завтра ядерная война?

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

Если не забывать старое - не будет потребности в новом. Учить новым трюкам надо собаку, а не взрослого состоявшегося программиста, который всё уже знает. Всё что было в 8.0 отлично работает и в 8.3, что ещё нужно?

не нужны. Мало кто знает, что слово "комментарий" происходит от слова "закомментировать"! Комментарии придуманы для того, чтобы программист мог закомментировать десяток-другой процедур и функций и продолжать экспериментировать в коде, выражая своё творческое "Я". Но иногда комментирование используют не по назначению - за двумя слэшами пишут какую-то информацию о том, что делает код. Это очень вредная практика. Во-первых, что за странная фантазия - писать комментарии по коду, если ты и так знаешь, что в нём происходит? Во-вторых, что может быть непонятного в модуле с несчастными 15 тысячами строк и тремя сотнями процедур? Или тем более в пакетном запросе из двадцати составляющих? И, в-третьих, кому вообще придёт в голову лезть в твоё бессмертное творение, созданное на века?

Всем известно, что данные в 1С можно получать через точку. Например:

РеализацияТоваровУслуг.Заказ.Контрагент.Партнер.КонтактноеЛицо.Телефон

Когда-то кто-то запустил слух, что, якобы, это плохо, мол, из базы тянется куча ненужных объектов, не учитываются права и прочий бред. Но подумайте сами, для чего тогда Господь создал 1С с возможностью получать данные через точку? Любому умному человеку очевидно, что это бессмысленно! Бесспорным фактом является то, что раз 1С создана с такими возможностями, значит их и нужно использовать, а не слушать еретиков. Более того, как вы себе представляете другие способы получения информации? Программист что, ещё и запрос должен писать для этого?? Конечно же нет! Шах и мат атеисты!

Одно из важнейших умений программиста - пользоваться уже написанным кодом для создания нового. Если уже есть какой-то код, который выполняет нужное действие - зачем изобретать велосипед и писать его ещё раз, если его можно просто скопировать? Более того, его можно копировать ещё и ещё, столько раз, сколько нужно! Это в разы сокращает трудозатраты, ведь не нужно искать закономерности, придумывать новые функции, пытаться абстрагировать какие-то части. Исключив таким образом огромное количество бессмысленных действий, мы получаем повышение производительности труда программиста в разы, даже в десятки раз! Копирование кода - одно из важнеших умений в ректальном программировании!

не нужно. Форматирование кода, как и многие другие ненужные украшательства, призвано ограничить волю самовыражения программиста, отучает мыслить нестандартно, загоняет в рамки, обезличивает работу программиста-творца. Зачастую, среди серости и монотонности "стандартного" программирования очень сложно показать свою избранность, не говоря уже о том, что часто потомки просто не смогут идентифицировать авторство такого кода. Как же обидно будет, создав памятник ректального програмирования, использовать стандартное форматирование, заставив таким образом нобелевский комитет будущего (когда будет учреждена премия в сфере 1С-программирования) сомневаться в авторстве! Не правда ли, ужастная участь? Именно поэтому не нужно стесняться писать такой код:

процедура создатьдокумент(отказ,сс,массив,тч,сообщпользчтнельзсозддок=ложь)
если отказ=истина тогда отказ=ложь; возврат; конецесли;
если типзнч(сс)=тип("документссылка.заказклиенту")тогда

Да и в конце концов, имеет человек право иметь неработающие Enter, Shift и Tab на клавиатуре или нет??

Очень часто можно увидеть, как неопытные, некомпетентные, слабые духом программисты создают целую кучу общих модулей, умудряясь даже делать модули почти для одинаковых целей, но с разными контекстами и возможностями - клиентные, серверные, клиентсерверные, повторные, с вызовом сервера и т.п. Между тем большое количество модулей говорит о душевных метаниях, неуверенности в себе и отсутствия понимания вообще, как устроена работа платформы. А ведь всё очень просто:

сервер не может работать с клиентом, а клиент с сервером - может, если у модуля стоит флажок "Вызов сервера"!

Думаю, специалисты ректального программирования уже поняли, каким должно быть решение. Для остальных же вот правильный ответ: можно просто создать один общий модуль, назвать его ОбщийМодуль1, поставить у него флажки "Сервер" и "Вызов сервера" - и всё!

Так в загнивающей капиталистической литературе называют объект в системе, который хранит все данные и/или весь функционал. Не правда ли - гениальная в своей простоте идея? Ведь действительно, как удобно иметь в системе объект, где хранится всё! Представьте, как упрощается разработка! Все запросы в системе пишутся по одному объекту, а программист больше никогда не задаётся вопросом - а откуда брать данные? Вот они, все здесь. Таким объектом может быть, например, регистр сведений (обязательно периодический), или ещё лучше регистр накопления. А все реквизиты всех хозяйственных операций в деятельности можно сделать как измерения такого регистра. В дальнейшем, при последующей разработке, можно просто добавлять измерения. Пользоваться таким регистром очень просто - заполняются только нужные реквизиты, а остальные остаются пустыми. Вот и всё! Мы добавили один объект, создали в нём 2-3 сотни измерений для всех случаев жизни, а насколько просто стало работать с базой! Только теперь становится ясен истинный смысл выражения "целостность данных". Если же поместить вообще всю деятельность в один объект не получается, можно хотя бы стремиться к этому, создать два-три объекта. Например, один справочник, один объект и один регистр, который двигается этим документом.

Иногда в работе кода могут происходить ошибки, к сожалению, это неизбежно. Но цель программирования - выполнение задачи без ошибок. Как же быть? А что, если я скажу вам, что ваш код может работать всегда! Вообще всегда!! Без ошибок!!! Магия? Шарлатанство? Нелегальные способы? Нет, нет и нет! Всего лишь "Попытка"! Да, это такая конструкция, которая позволяет как бы попробовать выполнить кусочек кода, а если случилась какая-то ошибка, то можно просто аккуратненько её обойти. А если заключить весь код в попытку, а в исключении ничего не писать, то ваш код всегда будет работать без ошибок. Представьте - так просто и всё всегда работает, пользователь никогда не получит какую-нибудь страшную ошибку в работе. Всё что нужно - это писать все функции-процедуры вот так:

Процедура ВыполнитьОбмен() Экспорт
    Попытка
    
// сюда помещаете всё тело процедуры
...

Исключение
// здесь ни в коем случае ничего не писать, иначе можно напугать пользователя!!!
КонецПопытки;

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

Вот и всё. И забудьте об ошибках. Кстати, это чудо возможно только в ректальном программировании, никакая другая методика не даёт таких впечатляющих результатов, поэтому она и ценится как среди программистов, так и среди их работодателей.

В 1С есть множество волшебных методов, которые магически выполняют свою работу без нагрузки на железо и при этом очень упрощают работу программиста. Например, методы "Выгрузить" у результата запроса и "Загрузить" у таблицы.

Представим, что у вас есть запрос, который получает миллиард строк из вашего богобъекта из п.6 и вам нужно их поместить в ТЧ объекта. Слабые духом скорее всего сделают выборку и будут построчно загонять в ТЧ. Но для чего, если можно просто написать:

ТЧ.Загрузить(Запрос.Выполнить().Выгрузить());

И всё сделается само за одно действие! Никаких циклов, никаких обходов, никакой вообще нагрузки на аппаратную часть. Строки просто волшебным способом оказываются внутри ТЧ.

И таких волшебных методов в 1С много. Ещё один пример: <...>.Найти(). Очень удобно использовать в цикле вместо, например, получения данных в запросе, ведь запросы писать сложно.

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

Ведь кто ещё смог бы научить его определять по звуку вентилятора охлаждения процессора, что операция, которая висела в 1С 40 минут, уже завершилась? Страшны ли пользователю какие-то излучения, если он годами смотрел на форму цвета фуксии с зелёно-красными кнопками? Убьёт ли такой человек в порыве гнева свою жену, если он каждый день заполнял форму с сотней полей, в которой если перевыбрать одно значение, форма сбрасывается в ноль, но при этом выжил и сохранил рассудок? Болью и страданиями от использования доработанных ректальным способом интерфейсов выложена пользователю дорога в нирвану.

не нужен. Ещё один из небольших трюков увеличения производительности труда программиста - не обращать внимание на мелочи, следуя широкими шагами к завершению задачи. Например, как вы думаете, что можно улучшить в коде:

Если ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Справочники"
    ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Документы"
    ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы видов характеристик"
    ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы счетов"
    ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Задачи"
    ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Бизнес-процессы"
    ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы обмена"
    Тогда
    ПлчЭлмнт = ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПолучитьЭлементы();
КонецЕсли;

или

Для Каждого а ИЗ МассивНаСтоТысячСтрок Цикл
    а.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию(
СтрЗаменить(Справочники.Организации.НайтиПоНаименованию("ООО Лютик").Наименование, "ООО", ""));
КонецЦикла;

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

Ещё одно иностранное слово, которое означает, что внутри кода зашиты какие-то значения. Например:

Если Имя = "Вася" Тогда
Сообщить(Имя);
КонецЕсли;

Здесь хардкодинг - это "Вася". Непонятно, зачем они там заграницей придумали для этого отдельное слово, ведь если тебе нужно проверить "Васю", то как ещё это можно сделать?