Внутреннее качество разработки конфигураций 1С

Любой, кто вносил доработки в код, оставленный по наследству, не раз нарушал свое душевное равновесие в попытках разобраться, как он работает. Причем степень раздражения (плевания, мата - каждый сам расширит список) возрастала по мере роста числа "поколений" разработчиков конфигурации.
Достоверный факт: при разборе своего же "творчества" спустя полгода частенько появляется удивление собственным ошибкам.
Отсюда возникает желание все переписать, ибо внесение внесение изменений превращается в головную боль.

Следующие тезисы ни в коей мере не претендуют на новизну, но начинающие (и не очень) разработчики их постоянно нарушают.

1. Ошибки в требованиях и архитектуре на порядок(ки) хуже ошибок в коде.

Написание кода "на коленке" приводит  к непредсказуемым доработкам в самом ближайшем будущем.

Пример 1:  Решили вести учет трудозатрат в компании по проектам. Предположили, что нужно ограничить виды работ сотрудника согласно состоянию проекта. Добавили реквизит СостояниеПроекта в справочник ВидыРабот, скорректировали поведение документа ЕжедневныйОтчет и ввод трудозатрат непосредственно из формы проекта, наваяли инструкцию для пользователей, соорудили отчет, тестировщики это дело проверили и выпустили релиз.
И тут выясняется, что ограничивать нужно по нескольким статусам проекта, а не по 1-му.

Пример 2: Ограничили по нескольким статусам (как и нужно), но допустили ошибку в форме ввода трудозатрат из проекта. Ошибку выявили только пользователи.

Чувствуете разницу?

Способ следования тезису:
Тщательное продумывание требований и архитектуры.

2. Код должен читаться как книга.

Немного теории: исследования гласят, что при внесении изменений в чужой код тратится 60% на чтение и только 40% на собственно изменения.

Пример:
Представим метод ЗаполнитьТовары(ДокументОбъект, Параметр1, параметр2, ...Параметр10) с общей целью: заполнить ТЧ Товары документа.
Доработка: Нужно сделать так, чтобы при определенном условии добавлялось 2 строки товаров, а не одна.
Вроде как нет проблемы, метод найден, цель понятна. Кодер, радостно разминая пальцы, с возгласами "Ща за 15 минут сделаю и на обед :))" приступает к работе.

Через полчаса бормотаний, на 700-ой строчке единственного метода маячит долгожданный текст
ДокументОбъект.Товары.Добавить()
с расплывчатым пониманием алгоритма метода:
- анализ условий добавления строк;
- формирование дополнительных данных для заполнения строк;
- собственно добавление строк.
Шаги алгоритма настолько перепутаны, что нужно вносить дополнительные условия через каждые 50 строк "размазанного" кода.
Далее следует полчаса доработки, затем еще час на тестирование и видимое избавление от неизбежных ошибок из-за нарушенной логики.

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

Собственно, рассеяный взгляд и невнятное бормотание программиста как раз указывают на пребывание в состоянии жонглирования и боязнь потерять "кегли"...

А кто не слышал или сам не восклицал с чувством гордости:
"Я такой хитрый код сегодня наваял!".
Гордость должна быть за простоту и понятность кода. Хитрость часто является следствием ошибок логики.

Готовы проявить такую же хитрость в расширении этого же кода спустя полгода :) ??

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

Способы решения задач управления сложностью известны уже лет 40. Многие их читали, но немногие используют/не хотят использовать. Перечислю только наиболее базовые:

1) Каждый метод приводит к достижению одной конкретной цели
2) Количество параметров метода не должно превышать 5-7. Превышение - не преступление, но "звоночек" для того, чтобы задуматься о правильности логики метода.
3) Метод содержит дейстия одного уровня абстракции.
Пример из реальности:
Строительство дома - это:
- подготовка фундамента
- подвод коммуникаций
- возведение стен
- настил крыши.
На таком уровне проектирования нас не интересует требуемый материал и цвет ручки двери.
Мы скрыли (выполнили инкапсуляцию) данного требования на уровне ручки, ручку на уровне двери, дверь на уровне стены.
В коде же такое сплошь и рядом, например, куча запросов в одном методе.
4) Понятные имена методов, переменных, объектов метаданных.
5) 1 метод - не более 1-го экрана текста. Рекомендация относительная, но полезная.
6) Целевые комментарии к шагам алгоритма.
Список рекомендаций можно продолжать дальше.

3. Не жалейте свой код.

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

Способы следования тезису:
- рассматривать код обработки как черновик, который неизбежно станет мусором
- удалять код, который не используется, а не комментировать его на будущее.

4. Тестирование выявляет только явные ошибки.

Многие разработчики свято верят в то, что завершение тестирования (в идеале тестировщиками) является подтверждением работоспособности. Но это не так. Всегда есть скрытые ошибки, выявить, которые может только сам разработчик или компетентный читатель кода (аудитор). А иногда и пытливый заказчик.

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

Общие соображения

Еще раз повторяюсь, что все вышесказанное весьма очевидно и приходит с опытом. Но не выполняется. Многие спустя 10 лет практики программирования наступают на одни и те же грабли.
Усугубляет ситуацию представление 1С как среды быстрой разработки со стремлением максимально ускорить написание кода в ущерб качеству. Да, в 1С много замечательных вещей упрощающих труд программиста, но базовые принципы объектно-ориентированного программирования никто не отменял.

Справедливости ради, отмечу, что качество многих исходных конфигураций от 1С (например, БСП) довольно высокое. Можно возмущаться насчет огромного уровня вложенности методов, неявной их связности, но при последующем разборе логика становится прозрачной.

Следствие: дефицит опытных специалистов 1С, при, казалось бы, избыточном общем предложении.
Опытному РП достаточно 5 минут, что оценить качество кода при приеме на работу.
Так что стремитесь к совершенству!

P.S. В статье только часть "правил хорошего тона". При наличии времени хочу написать еще 1-2 статейки на данную тематику.