Текст исходной статьи вы может найти здесь //infostart.ru/public/966234/
Чтобы не было недоразумений, скажу сразу. Программирование действительно может быть плохим и хорошим. Плохое программирование использует худшее из всех возможных представлений программы, а именно - текст. Этот подход достался нам в наследство от Алана Тьюринга с его бесконечной лентой. С тех пор, несмотря на неоднократные попытки, никому пока так и не удалось избавиться от него. Нам приходится писать наши программы на более или менее улучшенных разновидностях брейнфака. Хорошее программирование использует такое представление программы, которое учитывает особенности человеческого мозга. За ним, безусловно, будущее но оно пока еще не получило широкого распространения и нам всем, так или иначе, еще долго придется заниматься плохим. В этих нелегких условиях, ректальное программирование действительно является одной из лучших практик.
Разберемся по порядку. Сначала автор выдвигает три постулата. С первым из них я полностью согласен.
Главное - чтобы работало
Время и деньги - два остродефицитных ресурса. Никто не станет этого отрицать. Когда я выставляю заказчику счет на 20 часов работы, он, допустим, платит. Когда я выставляю за то же самое счет на 120 часов, заказчик начинает задавать вопросы. Он может даже понимающе покивает на ваши "перспективы, развития, доработки, переработки", но...
Так что, перспективы развития - это хорошо, когда вы договорились об этом "на берегу" и заказчик согласился это оплачивать. В реальной жизни такое, конечно, случается, но не часто.
Код - это искусство
А вот этого нет. Ректальные программисты не могут придерживаться этого постулата. Автор похоже забыл - какое у нас программирование. Оно ректальное. Ни один человек с минимальным вкусом не поставит рядом два эти слова: искусство и ректальное (ну разве что, это будет ну очень современное искусство). Чересчур трепетное отношение к тому, что из них выходит скорее свойственно обычным программистам. А ректальные слишком хорошо понимают, чем они занимаются. В этот же постулате автор зачем-то упоминает комментарии, имена переменных, сложность и простоту. Но, так как, он все равно рассматривает их ниже, то и мы поговорим об этом там же.
Все новое - хорошо забытое старое
Тоже нет. Пока обычный программист разминает пальцы, которые затекли, от того что он цеплялся за свои best practices, ректальный успевает освоить одну-две новомодные штуки. Ректальные программисты любят и ценят новое гораздо больше обычных. Откуда автору прилетел этот постулат - не понятно.
Перейдем к базовым приемам, о которых говорит автор.
Комментарии в коде
Эта тема на самом деле огромна. Но постараюсь ужаться. Автор правильно замечает, что ректальный программист использует комментарии только в процессе работы. Финальный релиз у ректального программиста полностью свободен от комментариев. Программирование - непростое дело. Если вы будете двигаться от начала к концу, вы никогда не закончите. А если вы будете двигаться от конца к началу, вы никогда не начнете. Приходится двигаться в двух направлениях сразу, порой откладывая что-то на потом. В таких местах и ставится комментарий с указанием, что ты собираешься сделать. Само собой, когда ты полностью закончишь, комментариев у тебя не будет. Очень удобно. Глянул в свой код. Зеленого нет? Работа сделана.
Обычные программисты считают, что комментарии помогают читать код. Это - иллюзия и самообман. Мозг человека обладает крайне малой оперативной памятью. Две-три ячейки и все. Пытаясь компенсировать этот недостаток, наш мозг постоянно перепрыгивает с одного на другое. Это происходит с бешенной скоростью и помимо нашей воли. Когда мы читаем текст на человеческом языке, наш мозг успокаивается и начинает скользить от слова к слову. Если это к тому же еще хорошее литературное произведение, то процесс становится не только легким, но и приятным. Но текст программы - не литературное произведение. Его чтение - настоящая мука для мозга. Неподготовленные люди очень устают. И это, кстати, главная, если не единственная причина, почему программирование до сих пор не пошло в массы. Когда мозг неподготовленного человека встречает островок привычного ему человеческого текста, он просто отдыхает. При этом содержимое комментария вовсе не важно. В принципе, это могло бы быть что-то типа:
//мы понимаем, как тебе трудно
//не паникуй, успокойся, отдышись
//рабочее время скоро закончиться
А еще лучше раскидать по всему тексту через равные промежутки отрывки из любимого литературного произведения. Но, поскольку любимое произведение у каждого свое, то нет никакого смысла вставлять комментарии в текст программы заранее. Это мог бы делать и сам неподготовленный программист, прежде чем читать текст программы. Запустил обработку, задал произведение и получил читабельный для себя текст. Впрочем, все это к ректальным программистам никак не относится. Ректальные программисты чужие комментарии не читают. Совсем. Вы не думайте, что я над вами шучу. Просто поверьте. В вашей практике обязательно настанет момент, когда вам резко станет неинтересно, что думал разработчик о своем коде. Зачем вам тратить время на эту ерунду? Вы будете сразу читать только код. Не могу сказать точно, когда это происходит. Лично у меня это было где-то между 20 и 30 годами практики. Но не исключено, что можно достичь этого и быстрее.
Выше автор что-то сказал про "понятные" переменные. Ректальный программист не понимает, что значит "понятная" переменная. Вот здесь понятная переменная?
СуммаПервогоИВторого=Первое*Второе;
А здесь?
х=Первое*Второе;
А что лучше? (Спойлер. Первое может быть причиной труднообнаруживаемой ошибки.)
Ректальный программист считает, что переменная должна быть различима в своем контексте (а контекст должен быть, по возможности, не сильно растянут). Т.е. мы должны с легкостью отличать одну переменную от другой. Давать при этом переменным "осмысленные" имена, растягивая их в длину или давать короткие абстрактные - по большому счету, дело вкуса. В любом случае, смысл переменной будет заключаться не в ее имени, а в тех значениях, которые она будет принимать.
Через точку
Тут веет уже каким-то совсем забытым холиваром. Когда-то давно также убедительно доказывали что никогда Алгол не будет применяться. Потому что он, конечно, понятнее, но ведь это полный разврат и пустая трата драгоценных машинных ресурсов. Настоящий программист должен сам определить что у него возьмется из регистра AX, а что из памяти.
start:
mov ah,01h
int 16h
jz start
xor ax,ax
int 16h
cmp al,1bh
je exit
cmp al,30h
jl start
cmp al,39h
jg start
push cs
pop ds
mov bx,offset coded
and al,0fh
xlatb
mov ah,0ah
xor bh,bh
mov cx,1
int 10h
jmp start
exit:
Когда-то это считалось прекрасным, однако опыт показывает, что в сражении между простотой и производительностью выигрывает простота. Ректальный программист спокойно напишет столько точек, сколько потребуется. И также спокойно ректальный программист напишет запрос в цикле. Я прекрасно знаю, что меня назовут рукожопом. Может так оно и есть. Я рукожоп, а разработчик платформы, который поленился на этапе предварительной трансляции вынести запросы к БД из циклов, он - молодец. Думайте, как хотите.
Форматирование
Этот прием ректальными программистами не используется. Сейчас любой редактор кода форматирует его на лету. И надо еще постараться его "расформатировать". А ректальные программисты бессмысленной активностью не занимаются.
Копирование кода и общие модули
Да, ректальный программист копирует код. Предварительно оценив всю боль от возможной будущей правки и умножив ее на вероятность, он хладнокровно делает это. Обычные так, конечно, не поступают. Например, разработчики типовых конфигураций не копируют код. Они создают много-много общих модулей. Потому что понимают - рано или поздно придется что-то менять. И тогда они устанут. Они - молодцы, что заранее позаботились о своей эффективности. Проблема только в том, что есть дебет, а есть кредит. 1С - это одна секунда. Вот эта одна секунда у меня и есть на то, чтобы поменять один символ в проведении документа. Я знаю где найти документ, его модуль, процедуру обработки проведения. И что толку? В типовой конфигурации я не сделаю это и за час. Потому что обычные программисты не копируют код. Они позаботились о своей эффективности, но не о моей. Просто подумайте об этом. Что целесообразнее? Съэкономить рабочее время небольшой группы разработчиков или миллионы человеко-часов всех остальных?
God object
Интересный подход. Но не для ректального программиста. Возможно, когда-нибудь он станет God-программистом. Вот тогда...
Попытки
Автор утверждает, что ректальные программисты везде вставляют попытки и ничего не пишут в исключениях, потому что боятся пользователей. Это не так. Ректальные программисты пользователей любят и совсем не боятся. Такие конструкции они ставят вовсе не везде, а только там, где по куску кода пройдет робот. В этом случае просто некому сообщать что-либо об ошибке. Конечно, тут следовало бы поставить запись в лог. Но ректальный программист всегда видит на несколько шагов вперед. И понимает: лог-то он сделает, но кто будет тот несчастный, которого заставят этот лог читать?
Юзерфрендли
Не знаю, где автор нашел форму с зелено-красными кнопками. Чтобы такую сделать, надо приложить усилия. Ректальный программист, повторюсь, не занимается бессмысленной активностью. Но в чем-то автор прав. Ректальный программист действительно не верит в юзерфрендли. Посмотрев много раз на такое:
ректальный программист наконец принимает для себя философское правило. Не "лечи" клиента, если он об этом не просит.
Кэш
Можно ли улучшить этот код? Ну, конечно, можно.
Если ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Справочники"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Документы"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы видов характеристик"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы счетов"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Задачи"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Бизнес-процессы"
ИЛИ ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПредставлениеОбъекта = "Планы обмена"
Тогда
ПлчЭлмнт = ЭтаФорма["ДеревоМетаданных"].НайтиПоИдентификатору(ТекСтрока).ПолучитьЭлементы();
КонецЕсли;
Так будет выглядеть гораздо эстетичнее, не правда ли? Мне кажется, тут автор уже начинает придираться к мелочам.
В заключение, хочется еще раз поблагодарить автора статьи за то, что он поднял такую важную тему. Надеюсь, с моими замечаниями и дополнениями, каждый сможет следовать прекрасной практике РП.
