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

21.06.13

Разработка - Рефакторинг и качество кода

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

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

вчера в 08:00    623    ZhokhovM    2    

2

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

вчера в 07:00    1486    ZhokhovM    2    

4

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1866    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

27.09.2023    6865    Lemmonbri    136    

35

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

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

19.09.2023    4255    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    9508    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2182    magic1s    32    

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

Да и с тестированием в 1С довольно все грустно. Как такого его там нет. Отсюда и страшно дорабатывать... черт его знает, сломал ли чего-нибудь.
neikist; kote; +2 Ответить
49. kote 536 05.02.17 11:09 Сейчас в теме
(1) В языках без ООП - распределение кода по разным уровням абстракции очень трудоёмко.. в 1с можно попытаться для этого использовать модули - но организация интерфейса у конфигуратора таково, что поиск нужного модуля в последующем - тоже становится неудобным и приводит к размножению модулей с похожей функциональностью..

Способ организации "расширяемости" принятый в 1С - видели же "[ИмяМодуля][Сервер|Клиент]Переопределяемый" - уже в 4 раза увеличил количество модулей.. это еще до УправляемыхФорм.. а сейчас - вообще хочется застрелиться при отладке - на Зарплате 3.0 - пока доберёшься до работающего кода нужно иногда 8 таких "точек расширения" пройти.. а ведь всё это - по сути - имитация свойств ООП..

В общем, нужно фирму 1С просить язык развивать, а не новые "блоки" и "функции" в платформу фигачить..
Vladimir Litvinenko; neikist; +2 Ответить
50. DMSDeveloper 146 06.02.17 12:17 Сейчас в теме
(49) Ваша правда! Иногда хочется руки отбить тому, кто придумал эту БСП
2. viramen 26 21.06.13 09:15 Сейчас в теме
То, о чем вы написали, прекрасно описано в куче книг типа "Совершенный код" еще и с примерами.
SunShinne; Irwin; simargle; +3 Ответить
3. DMSDeveloper 146 21.06.13 09:52 Сейчас в теме
(2)
Следующие тезисы ни в коей мере не претендуют на новизну, но начинающие (и не очень) разработчики их постоянно нарушают.


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

(2) можно пример пары книг "типа Совершенный код"?
8. l_men 15 21.06.13 10:26 Сейчас в теме
(4) okref, Стив Макконел "Совершенный код" - так и называется. В ней много полезной информации. Написана простым и доступным языком, с минимум кода. Я вообще считаю, что данная книга должна быть у каждого уважающего себя программиста.
10. DMSDeveloper 146 21.06.13 10:31 Сейчас в теме
(8)Немного поправлю вас, вы ошиблись в фамилии. Автор Стив Макконнелл

Инфа об авторе с Хабра http://habrahabr.ru/post/77471/
и Wiki
11. l_men 15 21.06.13 10:35 Сейчас в теме
(10) DMSDeveloper, писал по памяти) А ссылку посмотрю, автору + за то что вновь поднял тему качественного кода.
9. DMSDeveloper 146 21.06.13 10:28 Сейчас в теме
(4) Я не viramen. Но могу посоветовать посмотреть информацию в WIKI. Там очень хороший список литературы.

И немного информации тут http://www.nastroy-ka.ru/mgeneral/19--1.html
13. Timur_Bagautdinov 21.06.13 12:59 Сейчас в теме
(4) Р. Мартин "Чистый код"
7. _smile_ 21.06.13 10:26 Сейчас в теме
(2) viramen, Можете привести примеры (ссылки) таких книг?
Я сам не раз сталкивался и продолжаю сталкиваться со многими из описанных с статье аспектов.
Статья скорее полезна как напоминание. Автору за труды +
12. viramen 26 21.06.13 10:40 Сейчас в теме
(7) Коллеги, если вы настолько ленивы, то пожалуйста http://www.ozon.ru/context/detail/id/3159814/ в разделе рекомендуем также. Здесь походу надо описывать не приемы разработки а приемы использования гугла.
16. ig1082 279 21.06.13 18:20 Сейчас в теме
(2) viramen,
Да, вы правы. Большая часть содержимого статьи - по мотивам книги "Совершенный код". Плюс личный опыт. Могу добавить, что следование вышеописанным правилам намного упрощает работу (проверено на паре проектов). Следовал им и раньше, но после прочтения сложилась целостное представление :)
Антон Ширяев,
Да, таким советам не всегда удается следовать, особенно сидя у заказчика.
Но при добавлении, например, целой новой подсистемы во внутреннем проекте весьма полезно.
5. pumbaE 21.06.13 10:21 Сейчас в теме
Постоянно нарушаем. Даже есть статьи "как дорабатывать типовые, что бы потом проще было обновлять". Как делать неочевидные замены в запросах, как изменять программно форму и менять поведение формы отличающееся от того что видишь.

p.s.: и будем нарушать.
talych; CratosX; Антон Ширяев; +3 Ответить
14. Антон Ширяев 527 21.06.13 16:13 Сейчас в теме
Вынужден согласиться с (5) pumbaE. Если хочешь быстро обновлять исправленную типовую, то приходится ухищряться и не заботиться о красоте и легкочитаемости кода.
В ситуации когда есть возможность сделать по правильному, конечно лучше сделать так, но зачастую это ухудшит обновляемость.

К сожалению эстетическое качество кода не всегда приводит к хорошему быстродействию, да и заказчикам трудно объяснить, что нужно платить больше за качество кода, а не за конечный функционал добавленный разработкой.
Tavalik; ineshyk; +2 Ответить
6. DMSDeveloper 146 21.06.13 10:22 Сейчас в теме
Хотелось бы еще добавить о "правильном" разделении и размещении кода.

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

Моё мнение - это в корне не верно. Для размещения подобного кода лучше использовать модуль объекта или модуль менеджера. Наилучшим размещением будет расположение в общих модулях.
Такое размещение кода позволит практически все обращения к базе выполнить на стороне сервера, что значительно увеличит скорость работы системы. Да и интерфейс пользователя будет работать более плавно.
adhocprog; +1 Ответить
31. Bassgood 1424 01.07.13 18:08 Сейчас в теме
(6) DMSDeveloper, сторона исполнения модуля объекта (клиент или сервер) зависит от вида формы, на которой отображаются данные объекта, т.е. если вопрос касается обычной формы, то модуль объекта будет исполняться на стороне клиента, а если форма управляемая так в ней имеется возможность разграничения исполнения ее модуля как на стороне клиента, так и сервера, поэтому смысла выносить алгоритмы формы (запросы к БД) в отдельные модули зачастую нет. Смысл появляется только если этого требует логика применимости переносимых из формы во внешние модули методов (например, зачем переносить из модуля формы какую-либо процедуру, если она больше нигде в программе не используется, кроме как в контексте конкретной формы).
32. DMSDeveloper 146 01.07.13 18:31 Сейчас в теме
(31) Zigfridish, Вы никогда не обращали внимание в замере производительности на колонку "обработано сервером"?
Если запрос написан в модуле формы - его выполняет клиент, а если запрос написан в модуле объекта - его выполнение перехватывает на себя сервер.

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


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

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

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

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

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

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

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

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

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

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

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

Если вы работаете с формой некоего объекта - у вас уже существует вся его структура, на стороне клиента, для классических форм всегда, для УФ только в толстом клиенте, на стороне сервера при тонком и web клиентах.
38. Bassgood 1424 02.07.13 12:13 Сейчас в теме
(35) DMSDeveloper,
Тут вы не правы. Посмотрите на замер производительности. Все запросы, размещенные в модуле объекта - автоматически передаются на сторону сервера. Если запросы размещены в форме - выполнение на стороне клиента

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

При получении объекта на стороне клиента (в случае обычного приложения) компилируется весь его модуль, так зачем нам лишний раз перегружать клиента компиляцией тех процедур, которые используются только в формах (это как один из доводов)?
p.s. Наше обсуждение уже явно выходит за рамки этой публикации, если хотите, то можно продолжить обсуждение этой темы через ЛС.
43. alexqc 150 20.08.13 19:53 Сейчас в теме
(38) Zigfridish При получении объекта на стороне клиента (в случае обычного приложения) компилируется весь его модуль, так зачем нам лишний раз перегружать клиента компиляцией тех процедур, которые используются только в формах (это как один из доводов)?

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

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

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

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

Мысль 3)О решении проблемы. Пока молодое поколение дозревает до понимания важности стиля, способ только один - тотальный контроль на приемке (второй вздох). Порой читаешь код и понимаешь: как исполнитель строки разбросал, так и мозги у него разбросаны. Жаль, рамки сообщения не позволяют привести примеры.
Vladimir Litvinenko; Krio2; Fominro; Bassgood; +4 Ответить
26. Dnki 4 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?
KSy; Irwin; andrew87; talych; TreeDogNight; Tavalik; Bassgood; +7 Ответить
28. internetname 27.06.13 18:12 Сейчас в теме
Хотелось бы поддерживать читаемый код.
29. serg1974 27.06.13 21:59 Сейчас в теме
Постоянно нарушаем. Даже есть статьи "как дорабатывать типовые, что бы потом проще было обновлять". Как делать неочевидные замены в запросах, как изменять программно форму и менять поведение формы отличающееся от того что видишь.

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


Не совсем понял что имел ввиду pumbaE но - согласен: Часто код намеренно делается нечитаемым, чтобы сохранить свою незаменимость ;)
42. vitalya24 233 04.08.13 12:10 Сейчас в теме
(29) serg1974, это прям какое-то членовредительство:)
30. CheBurator 3119 29.06.13 16:58 Сейчас в теме
> Гордость должна быть за простоту и понятность кода.
- когда 1Снику больше нечем гордится - тогда вытасивается в качестве предмета гордости простота и понятность кода.
Гордиться надо работающими процессами, сделанной автоматизацией и nyv? что все идет как по часам...
segatron; KSy; Арчибальд; +3 Ответить
36. Арчибальд 2706 02.07.13 10:34 Сейчас в теме
(30) CheBurator, согласен. Программа должна работать. Причем заработать она должна в срок.
При этом программист сам для себя должен решить: нужно ли ему, чтобы код был читабельным. На ИС, к примеру, публиковались инструменты для получения нечитабельного кода.
34. pro-rok 295 02.07.13 08:42 Сейчас в теме
+ полезная вещь. Я думаю каждый программист сам для себя понимает эти простые истины, но по каким то причинам не все им следуют. Спасибо за статью.
37. Арчибальд 2706 02.07.13 10:37 Сейчас в теме
(0)
Пиши с верой в то, что твой читатель - это маньяк с дробовиком

Домашний адрес любого из разработчиков типовых конфигураций 1С тайны не составляет. И что?
39. adhocprog 1138 02.07.13 18:23 Сейчас в теме
Спасибо! Ждем новых статей :)
40. Stamper 43 12.07.13 12:04 Сейчас в теме
"Тестирование выявляет только явные ошибки"
тестирование выявляет те ошибки, на которые написаны тесты =)
41. fr.myha 16.07.13 12:04 Сейчас в теме
Спасибо за идеи. Похожие мысли прослеживаются в книге Фредрика Брукса "Мифический человеко-месяц или как создаются программные системы". Эта книга мировой бесцеллер и имеет 2-е доработанное автором издание, подводящее итоги по основным положениям выдвинутым в первом. Интересная книга для разработчика =)
44. ABudnikov 3 11.09.13 20:15 Сейчас в теме
+ Спасибо за концентрацию истин описанных в книжках. Ждём новых статей.
Интересно было бы почитать о том какие мероприятия повышают качество кодирования.
45. rеd80 18.09.13 11:44 Сейчас в теме
исследования гласят, что при внесении изменений в чужой код тратится 60% на чтение и только 40% на собственно изменения
90/10%. У меня у одного так?
Menno; i.kovtun; +2 Ответить
46. tango 506 18.09.13 12:18 Сейчас в теме
(45) rеd80, может быть, даже 98/02
чаще всего там одну, много - две, строчки впихнуть
47. ЧИА 169 21.09.13 14:52 Сейчас в теме
В коде же такое сплошь и рядом, например, куча запросов в одном методе.

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