gifts2017

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

Опубликовал Игорь Сухоруков (ig1082) в раздел Программирование - Практика программирования

Пиши с верой в то, что твой читатель - это маньяк с дробовиком, знающий твой домашний адрес.
Размышления на тему внутреннего качества кода при разработке/доработках конфигураций 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 статейки на данную тематику.  

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Тимур Багаутдинов (Timur_Bagautdinov) 21.06.13 08:57
Мда, смешение уровней абстракций встречается сплошь и рядом. В одном методе порой умудряются и в базу данных слазить, и бизнес логику осуществить, да еще и на форму вывести.

Да и с тестированием в 1С довольно все грустно. Как такого его там нет. Отсюда и страшно дорабатывать... черт его знает, сломал ли чего-нибудь.
2. Sergei Disev (viramen) 21.06.13 09:15
То, о чем вы написали, прекрасно описано в куче книг типа "Совершенный код" еще и с примерами.
Irwin; simargle; +2 Ответить 4
3. Андрей Окипний (DMSDeveloper) 21.06.13 09:52
(2)
Следующие тезисы ни в коей мере не претендуют на новизну, но начинающие (и не очень) разработчики их постоянно нарушают.


Я полагаю, эту строку в тексте вы пропустили.
shalimski; hulio; +2 Ответить
4. Алексей Рябцев (okref) 21.06.13 10:20
Мне было полезно. Спасибо.
Жду следующих "правил хорошего тона".

(2) можно пример пары книг "типа Совершенный код"?
5. Евгений Сосна (pumbaE) 21.06.13 10:21
Постоянно нарушаем. Даже есть статьи "как дорабатывать типовые, что бы потом проще было обновлять". Как делать неочевидные замены в запросах, как изменять программно форму и менять поведение формы отличающееся от того что видишь.

p.s.: и будем нарушать.
talych; CratosX; Антон Ширяев; +3 Ответить 1
6. Андрей Окипний (DMSDeveloper) 21.06.13 10:22
Хотелось бы еще добавить о "правильном" разделении и размещении кода.

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

Моё мнение - это в корне не верно. Для размещения подобного кода лучше использовать модуль объекта или модуль менеджера. Наилучшим размещением будет расположение в общих модулях.
Такое размещение кода позволит практически все обращения к базе выполнить на стороне сервера, что значительно увеличит скорость работы системы. Да и интерфейс пользователя будет работать более плавно.
7. _smile_ 21.06.13 10:26
(2) viramen, Можете привести примеры (ссылки) таких книг?
Я сам не раз сталкивался и продолжаю сталкиваться со многими из описанных с статье аспектов.
Статья скорее полезна как напоминание. Автору за труды +
8. Дмитрий Перминов (l_men) 21.06.13 10:26
(4) okref, Стив Макконел "Совершенный код" - так и называется. В ней много полезной информации. Написана простым и доступным языком, с минимум кода. Я вообще считаю, что данная книга должна быть у каждого уважающего себя программиста.
9. Андрей Окипний (DMSDeveloper) 21.06.13 10:28
(4) Я не viramen. Но могу посоветовать посмотреть информацию в WIKI. Там очень хороший список литературы.

И немного информации тут http://www.nastroy-ka.ru/mgeneral/19--1.html
10. Андрей Окипний (DMSDeveloper) 21.06.13 10:31
(8)Немного поправлю вас, вы ошиблись в фамилии. Автор Стив Макконнелл

Инфа об авторе с Хабра http://habrahabr.ru/post/77471/
и Wiki
11. Дмитрий Перминов (l_men) 21.06.13 10:35
(10) DMSDeveloper, писал по памяти) А ссылку посмотрю, автору + за то что вновь поднял тему качественного кода.
12. Sergei Disev (viramen) 21.06.13 10:40
(7) Коллеги, если вы настолько ленивы, то пожалуйста http://www.ozon.ru/context/detail/id/3159814/ в разделе рекомендуем также. Здесь походу надо описывать не приемы разработки а приемы использования гугла.
13. Тимур Багаутдинов (Timur_Bagautdinov) 21.06.13 12:59
14. Антон Ширяев (Антон Ширяев) 21.06.13 16:13
Вынужден согласиться с (5) pumbaE. Если хочешь быстро обновлять исправленную типовую, то приходится ухищряться и не заботиться о красоте и легкочитаемости кода.
В ситуации когда есть возможность сделать по правильному, конечно лучше сделать так, но зачастую это ухудшит обновляемость.

К сожалению эстетическое качество кода не всегда приводит к хорошему быстродействию, да и заказчикам трудно объяснить, что нужно платить больше за качество кода, а не за конечный функционал добавленный разработкой.
Tavalik; ineshyk; +2 Ответить
16. Игорь Сухоруков (ig1082) 21.06.13 18:20
(2) viramen,
Да, вы правы. Большая часть содержимого статьи - по мотивам книги "Совершенный код". Плюс личный опыт. Могу добавить, что следование вышеописанным правилам намного упрощает работу (проверено на паре проектов). Следовал им и раньше, но после прочтения сложилась целостное представление :)
Антон Ширяев,
Да, таким советам не всегда удается следовать, особенно сидя у заказчика.
Но при добавлении, например, целой новой подсистемы во внутреннем проекте весьма полезно.
17. Яков Коган (Yashazz) 21.06.13 19:39
К сожалению, хороший одинэсник не тот, кто хороший программист-кодер-архитектор в любом понимании любой чистой теории, а тот, кто быстро и недорого удовлетворил нужды заказчика. Даже если потом трава не расти, а заказчик огребёт проблемы. Многажды видел, как неопытный кодер лепил одно на другое, лишь бы успевать, и все были счастливы, и з/п у него была повыше, чем у того эстета, что всё грамотно проектировал и строил, но делал это заумно, медленно, постоянно упоминая страшные буквы "ТЗ". А когда однажды у первого всё начинало тормозить и сыпаться, он либо сливался на другую работу, либо делал крайним второго. Образно говоря, заказчику не нужна хорошая программа, ему нужна работающая щас и так, как он хочет щас. Шашечки или ехать. А это, в свою очередь, от постоянного диктата среды, когда заказчик и рад бы подумать о будущем, но сиюминутное довлеет; и от низкой культуры потребления, когда лишь бы хоть бы как работало. Тот же механизм, который заставляет садиться в ржавое шахид-такси, вместо чтоб ехать на нормальном таксисте; а вы тут методики "как сделать своё такси ещё лучше" выкладываете...
p.s. все ассоциации с новым интерфейсом 8.3 случайны
Irwin; xa1ter; andrew87; kinazarov; AndrewVVS; Tavalik; adhocprog; Bassgood; +8 Ответить 1
18. Галина Ивлева (galinka1c8) 21.06.13 21:42
А мне статья понравилась. Вроде все общеизвестно, но постоянно об этом забываешь, и приходит понимание "Чистого кода" только с опытом. Вспоминая свою первую обработку еще на 7.7 могу сказать, что сейчас мне в нем будет если что тяжеловато разобраться)) А по поводу предудущего автора не совсем согласна. Надо во-первых писать по принципу "уважай труд не только себя, но и тех, кто придет после тебя", чтоб не поминали лихом)). А перейти на другую работу, когда все начнет отваливаться из-за ошибок, можно и не успеть, и все шишки повалятся от заказчика на тебя, за уже уплаченное и будешь дорабатывать бесплатно.
19. Иван Китаев (Zord) 24.06.13 10:03
Статья хорошая. Полезно прочитать и вспомнить общеизвестные правила =)
20. Андрей Окипний (DMSDeveloper) 24.06.13 10:13
(17) Yashazz, т.е вы предлагаете не искать некие компромиссы в скорости разработки и её качестве. Не нужно пытаться улучшить культуру взаимодействия заказчика и исполнителя. Нужно просто косить бабло! Лепить говнокод - лишь бы работало в момент принятия работ заказчиком, а дальше трава не расти?
21. Яков Коган (Yashazz) 24.06.13 16:07
(20) Я это НЕ предлагаю. Я этот подход искренне НЕ терплю и никому не советую. Но это суровая реальность... Пока мы эстетствуем и профессиональничаем, вчерашние студенты именно лепят говнокод и косят бабло, сие факт, который просто констатирую.
22. Андрей Окипний (DMSDeveloper) 24.06.13 16:19
(21) Yashazz. Не совсем с вами согласен. Серьезные компании уже начали приходить к пониманию, что качество кода в разработке так же играет огромную роль. И с каждым днем таких компаний становится все больше. По крайней мере в автомобильной индустрии, за другие отрасли говорить не буду.
23. ZLENKO.PRO (ZLENKO) 26.06.13 10:39
К сожалению серьезных компаний не так уж и много, а всех остальных интересует не совершенный код, а решение их проблем и желательно побыстрее и подешевле. Делать качественным нетиражируемый код - очень дорого. Но элементарная культура написания кода должна присутствовать, а то многие даже ленятся автоматически выровнять код (всего то надо кнопочку нажать):-(
24. Андрей Окипний (DMSDeveloper) 26.06.13 12:15
(23) В чем-то вы правы, но с нас, высококвалифицированных программистов, не убудет, если мы напишем код под маленькую задачку правильно. По моему это не только показатель нашей квалификации или простое проявление уважения к следующему программисту, но и повод студиозам стремиться к более высокому качеству.

По поводу не тиражируемого кода, на моей практике такого кода было не так уж и много.
25. Игорь Дайнеко (Dnki) 26.06.13 23:40
Во всей статье мне особенно приятен один факт: есть люди, которые неравнодушно относятся к своему труду.
Мысль 1) К сожалению (в этом месте я делаю вздох), существует 2 противоречивых интереса: у программиста "сделать это по-быстрому". У владельца - сделать красивый код. Под владельцем я имею ввиду того, кто будет дальше эксплуатировать, тиражировать, исправлять ошибки, и менять функционал. Т.е., читай по-русски, платить другим программистам. Я директор небольшой франчайзи и для меня изложенные тезисы не удовлетворение моего тонкого эстетического вкуса а реальные ресурсы. Ибо только я верю своему опыту: за 10 лет модифицируется 80% исходного кода.

Мысль 2) А посему писать иначе, кроме как по-правилам, просто не могу. Фраза от программиста "так эту красоту наводить долго" мне не понятна. За оговорку "комменты я потом нарисую" я сразу ложу на плаху. И вот почему - сам я ничего не делаю "потом". Я сразу пишу как надо. Пока пишу описание к процедуре, мысленно ревизирую ее параметры. А придумывание название переменной/реквизиту является поводом для ананлиза ее применяемости.

Мысль 3)О решении проблемы. Пока молодое поколение дозревает до понимания важности стиля, способ только один - тотальный контроль на приемке (второй вздох). Порой читаешь код и понимаешь: как исполнитель строки разбросал, так и мозги у него разбросаны. Жаль, рамки сообщения не позволяют привести примеры.
Fominro; Bassgood; +2 Ответить
26. Игорь Дайнеко (Dnki) 26.06.13 23:59
Извините, забыл поставить галочку "Подписаться на ответы этой темы", поэтому вынужден написать еще одно сообщение. Добавлю о причинах моей горечи.
* О качестве кода самой 1С могу сказать одно: бывшие тетки-бухгалтерши писали. Маниакальное стремление достичь 10-кратной вложенности процедур, перенести функционал из объектов в глобальные модули (так мол "библиотечнее") напрочь лишает типовые версии звания "программный продукт".
* По моим наблюдениям из 10-15 программистов только один задумывается над оформлением и логической структуре кода. (Присутствующих прошу не дуться, я же не только об 1С-никах :) .
27. Александр (alex_sear) 27.06.13 06:10
ИМХО: все зависит от соотношения цена/качество.

Когда есть 100500 задач, которые нужно решить здесь и сейчас, как-то трудно писать код для диссертации когда требуется все сделать быстро и дешево. Да, стремится делать все на 105% нужно, но для этого должна быть соответствующая мотивация.

Профи делают «по правильному» для будущего, тем самым возможно недополучая сейчас, они набрав нужный опыт уйдут на более оплачиваемую работу. «Шалапаи» делают все быстро на коленке, чтоб срубить деньжат здесь и сейчас, «а завтра посмотрим что будет». Обычные прогеры делают как получится – из-за лени, неправильной мотивации и т.п.

Бизнес покупает услугу по той цене, которою считает справедливой - за 100 рублей он купит соответствующее решение, за 500 другое (сферический идеал в вакууме). Грубо говоря, есть ли смысл писать код за 500, если платят 100 или другое дело, писать, когда платят 500, а он стоит 100?
Irwin; andrew87; talych; TreeDogNight; Tavalik; Bassgood; +6 Ответить
28. Евгений Фамилия (internetname) 27.06.13 18:12
Хотелось бы поддерживать читаемый код.
29. Сергей Аблаев (serg1974) 27.06.13 21:59
Постоянно нарушаем. Даже есть статьи "как дорабатывать типовые, что бы потом проще было обновлять". Как делать неочевидные замены в запросах, как изменять программно форму и менять поведение формы отличающееся от того что видишь.

p.s.: и будем нарушать.


Не совсем понял что имел ввиду pumbaE но - согласен: Часто код намеренно делается нечитаемым, чтобы сохранить свою незаменимость ;)
30. Сергей (Che) Коцюра (CheBurator) 29.06.13 16:58
> Гордость должна быть за простоту и понятность кода.
- когда 1Снику больше нечем гордится - тогда вытасивается в качестве предмета гордости простота и понятность кода.
Гордиться надо работающими процессами, сделанной автоматизацией и nyv? что все идет как по часам...
Арчибальд; +1 Ответить 1
31. Zigfridish (Bassgood) 01.07.13 18:08
(6) DMSDeveloper, сторона исполнения модуля объекта (клиент или сервер) зависит от вида формы, на которой отображаются данные объекта, т.е. если вопрос касается обычной формы, то модуль объекта будет исполняться на стороне клиента, а если форма управляемая так в ней имеется возможность разграничения исполнения ее модуля как на стороне клиента, так и сервера, поэтому смысла выносить алгоритмы формы (запросы к БД) в отдельные модули зачастую нет. Смысл появляется только если этого требует логика применимости переносимых из формы во внешние модули методов (например, зачем переносить из модуля формы какую-либо процедуру, если она больше нигде в программе не используется, кроме как в контексте конкретной формы).
32. Андрей Окипний (DMSDeveloper) 01.07.13 18:31
(31) Zigfridish, Вы никогда не обращали внимание в замере производительности на колонку "обработано сервером"?
Если запрос написан в модуле формы - его выполняет клиент, а если запрос написан в модуле объекта - его выполнение перехватывает на себя сервер.

... если форма управляемая так в ней имеется возможность разграничения исполнения ее модуля как на стороне клиента, так и сервера, поэтому смысла выносить алгоритмы формы (запросы к БД) в отдельные модули зачастую нет ...


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

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

А зачем в модуле формы выполнять запросы, порой, в несколько скроллов длинной? Не проще ли перенести запрос модуль объекта (который так же контекст данной формы) а в форме оставить только вызов функции интуитивно понятный, одной строкой?

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

Если ошибка связана с отображением - смотрим форму.
Если ошибка связана с обработкой данных - модуль объекта ил модуль менеджера.

Я уже года три пишу в таком стиле - гораздо легче стало сопровождать. Меньше ошибок допускается, гораздо проще вносить изменения.
33. Zigfridish (Bassgood) 01.07.13 23:59
(32) DMSDeveloper,
Если запрос написан в модуле формы - его выполняет клиент, а если запрос написан в модуле объекта - его выполнение перехватывает на себя сервер.

Если обычный режим запуска системы - и модуль формы и модуль объекта исполняются на стороне клиента, поэтому собственно никакой разницы куда помещен запрос (в модуль формы или объекта) нету, обращение к БД будет выполняться всегда со стороны клиента.
Если управляемый режим запуска - в любом случае, если необходимо выполнить запрос к БД из формы, то запрос нужно будет помещать в серверную процедуру формы (с соответствующей директивой компиляции) или модуль объекта, что в первом, что во втором случае - это вызов сервера и обращение с него к БД.
Вы считаете запросы к базе алгоритмами формы? Я - нет. Для меня любой запрос является либо общим для всей конфигурации, и находится в общем модуле, либо алгоритмом объекта и находится в модуле объекта.

Фирма "1С" считает иначе, я лишь придерживаюсь ее стандартов и рекомендаций, на сколько я помню, Радченко в одной из своих книг писал, что при выборе места размещения процедуры (в модуле формы или объекта) следует исходить из логики ее использования и применения. На самом деле, если мне необходимо программно заполнить на форме для поля ввода список его значений - зачем мне обращаться для этого к объекту, если это чисто локальная задача для конкретного поля ввода конкретной формы (поместив ее в модуль объекта, тем самым мы замусорим его модуль, т.к. эта процедура не используется отдельно в контексте модуля объекта, а только в контексте одной из его форм)?
Еще одной из причин не размещения всех процедур, связанных с запросами к БД, в модуле объекта - при обращении к объекту для вызова только лишь одной из его процедур вместе с ним на клиент тянутся все его табличные части, и если они большие по объему, то их получение возможно будет занимать больше времени, чем исполнение самой вызываемой процедуры.
Если ошибка связана с отображением - смотрим форму. Если ошибка связана с обработкой данных - модуль объекта ил модуль менеджера.

В этом соглашусь, если смотреть с этой точки зрения, то конечно подобное разделение исполнение кода облегчает его отладку.
34. Дмитрий Макаров (pro-rok) 02.07.13 08:42
+ полезная вещь. Я думаю каждый программист сам для себя понимает эти простые истины, но по каким то причинам не все им следуют. Спасибо за статью.
35. Андрей Окипний (DMSDeveloper) 02.07.13 10:08
(33) Zigfridish,
Если обычный режим запуска системы - и модуль формы и модуль объекта исполняются на стороне клиента, поэтому собственно никакой разницы куда помещен запрос (в модуль формы или объекта) нету, обращение к БД будет выполняться всегда со стороны клиента.

Тут вы не правы. Посмотрите на замер производительности. Все запросы, размещенные в модуле объекта - автоматически передаются на сторону сервера. Если запросы размещены в форме - выполнение на стороне клиента.

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

Если вы работаете с формой некоего объекта - у вас уже существует вся его структура, на стороне клиента, для классических форм всегда, для УФ только в толстом клиенте, на стороне сервера при тонком и web клиентах.
36. Александр Рытов (Арчибальд) 02.07.13 10:34
(30) CheBurator, согласен. Программа должна работать. Причем заработать она должна в срок.
При этом программист сам для себя должен решить: нужно ли ему, чтобы код был читабельным. На ИС, к примеру, публиковались инструменты для получения нечитабельного кода.
37. Александр Рытов (Арчибальд) 02.07.13 10:37
(0)
Пиши с верой в то, что твой читатель - это маньяк с дробовиком

Домашний адрес любого из разработчиков типовых конфигураций 1С тайны не составляет. И что?
38. Zigfridish (Bassgood) 02.07.13 12:13
(35) DMSDeveloper,
Тут вы не правы. Посмотрите на замер производительности. Все запросы, размещенные в модуле объекта - автоматически передаются на сторону сервера. Если запросы размещены в форме - выполнение на стороне клиента

Если включить замер производительности в режиме обычного приложения то в таблице замера отсутствуют такие графы как "Клиент"/"Сервер"/"Обработано сервером", т.к. в этом режиме модули объектов и форм компилируются и исполняются на стороне клиента, а при выполнении запросов к БД происходит обращение к серверу, поэтому где бы мы не разместили процедуру с запросом (модуль объекта или формы) - всегда будет выполнено обращение к серверу столько раз, сколько производится запросов к БД (допустим, столько раз сколько в процедуре прописано "Запрос.Выполнить()").
В управляемом приложении в формах можно уже играться с обращениями к серверу и выполнением кода на его стороне при помощи директив компиляции, в любом случае, если Вы захотите выполнить какую-либо процедуру модуля объекта из модуля одной его форм, Вам необходимо будет сначала получить сам объект на стороне сервера (при помощи метода "РеквизитФормыВЗначение()", т.к. на стороне клиента он отсутствует), т.е. произвести вызов сервера. Тоже самое будет если Вам понадобится выполнить какой-то запрос, размещенный непосредственно в одной из процедур модуля формы - необходимо будет обратиться к серверной процедуре формы (т.к. работа с запросами на стороне клиента невозможна), т.е. тот же самый вызов сервера.
Если вы работаете с формой некоего объекта - у вас уже существует вся его структура, на стороне клиента, для классических форм всегда

При получении объекта на стороне клиента (в случае обычного приложения) компилируется весь его модуль, так зачем нам лишний раз перегружать клиента компиляцией тех процедур, которые используются только в формах (это как один из доводов)?
p.s. Наше обсуждение уже явно выходит за рамки этой публикации, если хотите, то можно продолжить обсуждение этой темы через ЛС.
39. Владимир Гусев (adhocprog) 02.07.13 18:23
Спасибо! Ждем новых статей :)
40. Stamper (Stamper) 12.07.13 12:04
"Тестирование выявляет только явные ошибки"
тестирование выявляет те ошибки, на которые написаны тесты =)
41. muha muhaha (fr.myha) 16.07.13 12:04
Спасибо за идеи. Похожие мысли прослеживаются в книге Фредрика Брукса "Мифический человеко-месяц или как создаются программные системы". Эта книга мировой бесцеллер и имеет 2-е доработанное автором издание, подводящее итоги по основным положениям выдвинутым в первом. Интересная книга для разработчика =)
42. Виталий Трач (vitalya24) 04.08.13 12:10
(29) serg1974, это прям какое-то членовредительство:)
43. Алексей (alexqc) 20.08.13 19:53
(38) Zigfridish При получении объекта на стороне клиента (в случае обычного приложения) компилируется весь его модуль, так зачем нам лишний раз перегружать клиента компиляцией тех процедур, которые используются только в формах (это как один из доводов)?

Раз на стороне клиента компилируется весь его модуль, то какая разница где лежит процедура - в форме ли, в модуле - все равно скомпилится. Вот для сервера - как раз таки значение есть: формы на сервере не компилятся, соотв чем меньше модуль - тем серверу легче. Однако, во-первых, никто не отменял директив "#Если Клиент", а во-вторых, все это дело компилится один раз, и затраты на компиляцию по сравнению со всей остальной работой пренебрежительно малы.

Вот чего в неуправляемых формах не хватает - это сделать выполнение на сервере (даже без передачи объекта), единственный вариант - общий модуль с вызовом сервера, что не всегда удобно.
44. Анатолий (ABudnikov) 11.09.13 20:15
+ Спасибо за концентрацию истин описанных в книжках. Ждём новых статей.
Интересно было бы почитать о том какие мероприятия повышают качество кодирования.
45. red 80 (rеd80) 18.09.13 11:44
исследования гласят, что при внесении изменений в чужой код тратится 60% на чтение и только 40% на собственно изменения
90/10%. У меня у одного так?
Menno; i.kovtun; +2 Ответить 1
46. Михаил Ражиков (tango) 18.09.13 12:18
(45) rеd80, может быть, даже 98/02
чаще всего там одну, много - две, строчки впихнуть
47. Игорь Чайкин (ЧИА) 21.09.13 14:52
В коде же такое сплошь и рядом, например, куча запросов в одном методе.

Напрягает обратная ситуация.
Вместо написания серии выборок во временные таблицы и финальной выборки "особо одаренные" пишут дикий запрос с подзапросами, мало того, что трудно читаемый, так еще и тормознутый.
Прикрепленные файлы:
48. Елена Ситникова (lesenoklenok) 03.03.14 11:36
Спасибо за пост, но тут тоже есть вариант того, что ты можешь считать, что описываешь подробно и понятно, но пришедший новый программист вообще не поймет что ты хотел сказать. Бывали уже подобные случаи.
TreeDogNight; +1 Ответить