Правила программирования и автоматизации

Программирование - Теория программирования

программирование разработка

70
Изложил свой опыт программирования, больше десяти лет.

1

Вы пишете код для человека, не для программы или компьютера. Делайте код понятным, чтобы человек, который будет разбираться в нём через полгода или год или два, мог легко это сделать. Возможно, этим человеком будете Вы, только через год Вы уже не вспомните, что там где подразумевалось "по умолчанию"

2

Помните, что телепатов нет. Ещё раз. Телепатов нет. Код, а равно и интерфейс пользователя, должны быть понятными и не должны содержать умолчаний, понятных только Вам.

3

Названия переменных "Пер1", "А", "Сп" допустимы только в студенческих работах, отладочных обработках или крайне простых процедурах, но не в промышленных решениях. Название переменной должно отражать её содержимое, в крайнем случае нужно оставлять комментарий при её инициализации.

4

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

// добавление подписантов в файл PDF (последней страницей) из таблицы подписантов в 1С, 
// а также добавление нумерации страниц
Процедура ПолучитьФайлСНумерациейИПодписями(НакопленныеДанные) 
	
	ОпределитьВозможностьСклейкиСПодписями(НакопленныеДанные);
	Если НакопленныеДанные.МожноСклеить = Истина Тогда
		ПолучитьИзначальныйФайл(НакопленныеДанные);
		ПодготовитьСредствоРаботыСPDF(НакопленныеДанные);
		СгенерироватьФайлСлужебнойИнформации(НакопленныеДанные);
		ПолучитьИнтересующиеДанныеИзФайлаСлужебнойИнформации(НакопленныеДанные);
		СоздатьPDFСНумерацией(НакопленныеДанные);
		СоздатьPDFСПодписями(НакопленныеДанные);
		СклеитьФайлы(НакопленныеДанные);
		УдалитьВременныеФайлы(НакопленныеДанные);
	КонецЕсли;
	
КонецПроцедуры

 

5

Процедуры и функции должны быть безопасными, то есть — а) их название должно отражать суть б) они не должны делать то, что от них не ожидается исходя из названия

6

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

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

Хорошее сложное решение отличается от плохого сложного решения количеством уровней абстракции.

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

7

Реализация очень сильно зависит от постановки задачи.

Можно поставить задачу "отправлять бухгалтеру на почту уведомления о поступлении РКО с видом Подотчёт", а можно поставить задачу "Реализовать универсальный механиз рассылки уведомлений по триггерам". А ещё можно поставить задачу "Найти на Инфостарте универсальный механиз рассылки уведомлений по триггерам".

8

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

9

Если схожая задача возникает 3 раза, значит, она возникнет ещё 300 раз, и пора подумать о создании универсального механизма

10

Пользовательский интерфейс должен быть максимально лёгкий. Запрещается перегрузка интерфейса лишними элементами. Любые возможности нужно систематизировать — объединять в группы, выносить на отдельные вкладки и так далее. Если пользовательский интерфейс перегружен реквизитами и полями, назначение которых понятно только избранным или требует отдельной инструкции, значит, интерфейс очень плохой. 

11

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

12

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

12А

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

12Б

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

13

При проектировании следует чётко и ясно определять уровни взаимосвязи объектов — один к одному, один ко многим, много к одному, много ко многим, и исходя из этого сразу планировать правильную логику. Например, если в чеке для видов оплат сразу спроектировать таблицу "оплаты", всё становится на свои места. Можно платить частично наличными, частично картами, частично яндекс.деньгами. Или наоборот — заранее заложить при проектировании, что вид оплаты должен быть один и только один, а если видов оплаты несколько — оформлять несколько чеков. Оба подхода имеют право на жизнь и свои плюсы и минусы.

70

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Degrement 119 21.02.18 16:41 Сейчас в теме
14 Не усложнять. Чем проще алгоритм и структура метаданных, тем проще его поддерживать, дорабатывать + как правило производительность выше.
cleaner_it; vakham; Nelli_A86; w.r.; +4 Ответить
65. w.r. 38 23.02.18 12:45 Сейчас в теме
(1) вот этим грешат многие начинающие программисты. Я для себя сделал вывод: хорошее решение - простое решение. Лучше 7 раз подумать и написать небольшой правильный код, чем начать писать, а потом уйти в неведомые дебри, которые уже не решают задачу. Точка отсчета очень важна
Dmitri93; user657734_YGREEN; vakham; +3 Ответить
96. LexSeIch 197 27.02.18 03:34 Сейчас в теме
(1) Точно: Keep It Simple Stupid - KISS принцип в программировании - хорошая вещь!

В 80-х годах, уже прошлого столетия, мне как-то в руки попал документ (оригинал еще на магнитной ленте, от фирмы Motorola но могу и ошибиться) где были сформулированы правила оптимизации систем под общим заголовком Keep It Simple, Stupid! :

1. It’s easier to get a working system efficient then it is to get an efficient system working. (Легче сделать рабочую систему эффективной, чем эффективную систему рабочей.)

2. Optimaze a system only if it fails a performance test. It is futile to optimaze a system just for the fun of it, if that optimization brings no practical benefit. (Оптимизируйте систему, только если она не проходит теста производительности. Бесполезно оптимизировать системы только для удовольствия, если оптимизация не приносит никакой практической пользы.)

3. Simplicity is a virtue that bears its own rewards. (Простота это качество, имеющее собственную ценность.)

4. Optimize only the parts of the system worth optimizing. (Оптимизируйте только те части системы, которые действительно требуют оптимизации.)
getnight; klinval; user657734_YGREEN; +3 Ответить
121. Painted 22 16.04.18 09:24 Сейчас в теме
124. LexSeIch 197 10.05.18 08:15 Сейчас в теме
(121) Как ни странно, есть и такой термин - синоним...
Прикрепленные файлы:
125. Painted 22 10.05.18 09:30 Сейчас в теме
(124)
Как ни странно
Действительно, странно. ))
2. viking7 21.02.18 17:52 Сейчас в теме
Статья хорошая. Но об этом всем я узнал еще на 1 курсе своего профильного обучения. От себя добавлю, что хорошие комментарии и пояснения в коде облегчат вам или приемнику жизнь в разы.
9. swimdog 582 21.02.18 23:40 Сейчас в теме
(2) Хороший код не нуждается в комментариях)
Alligator84; Kassyas; ZUL_MTFKA; Dmitri93; nikivr; coollerinc; dedkov; TreeDogNight; ACE$; itriot11; ipoloskov; DarkAn; dj_serega; zarucheisky; ybatiaev; Dr.LektoR; Ликреонский; IvanBoychuk123; tsukanov; bsturtle; FesenkoA; amon_ra; awk; AlexGroovy; rusmil; fancy; ArchLord42; +27 Ответить
105. vakham 3 28.02.18 10:01 Сейчас в теме
(9) Гусару триппер не помеха?
110. VipService 28.02.18 10:15 Сейчас в теме
(9)Полностью согласен. У докладчика нет информации по комментариям. Он пишет о чистом коде, но не упомянул о комментариях совсем. Чистый и понятный код не нуждается в комментариях. Один из программистов, которого встречал буквально год назад, чтобы не забыть, писал комментарии в начале модуля, в начале процедур/функций, в конце модуля (о добавленных/измененных реквизитах на форме). Это тоже одна из болезней начинающих программистов. Названия функций должны быть простыми и не требовать комментариев. Но это не значит что их совсем не должно быть.
cleaner_it; +1 Ответить
3. SandDanGlokta 21.02.18 17:55 Сейчас в теме
Насчёт 12Б. С точки зрения программиста я полностью согласен с данным тезисом. Однако не думаю, что с таким положением дел согласятся собственники предприятий. Для них ведь на первом месте получение прибыли. И именно для этого им нужна автоматизация. Для сокращения издержек, прозрачного учёта и тд. Но если ради автоматизации придётся откладывать условные накладные на миллионы долларов, то какой им толк от неё? Да, в базе всё будет красиво, правильно, чётко и ясно. Но ведь на первом месте для них прибыль, а не отлаженный механизм учёта. И когда условный программист говорит условному владельцу бизнеса "Сейчас мы не можем обработать этот выгодный заказ от клиента, т.к. мы потом не сможем автоматически обработать эту номенклатуру", то вряд ли он встретит одобрение со стороны собственника.
sulfur17; TreeDogNight; creatermc; acanta; EliasShy; bulpi; user774630; klinval; +8 Ответить
4. leosoft 128 21.02.18 18:06 Сейчас в теме
Вот если бы 1С придерживался этих правил. :)
Арчибальд; user748289; e-tixom; vakham; sergathome; ACE$; arakelyan; dj_serega; EliasShy; zqzq; mostvante; Gilev.Vyacheslav; +12 1 Ответить
28. logarifm 1020 22.02.18 12:15 Сейчас в теме
(4)\а в чем 1С не придерживается этих правил?

К примеру у автора процедура так себе. Нет входного описания параметра, а по стандарту он должен быть описан иначе не понятно, что это?Структура, таблица значений, строка дерева значений Ит.д.
ger_kar; sergathome; +2 Ответить
44. leosoft 128 22.02.18 14:50 Сейчас в теме
(28) Не усложнять. Чем проще алгоритм и структура метаданных

1С любит налепить регистров в огромных количествах!

Например, раньше в зарплате обходились одним регистром, а сейчас
под сотню скоро будет! Тоже и в Бухгалтерии
45. Dzenn 273 22.02.18 14:53 Сейчас в теме
(44) 1С как раз не усложняет. Не забывайте, что типовые конфигурации 1С являются универсальными.
46. leosoft 128 22.02.18 15:04 Сейчас в теме
(45) А раньше не было все универсальным? И хватало одного регистра. А сейчас,
особенно с ЗУПе их столько... Информация по сути дублируется, возможны рассогласования и т.п.
58. Brawler 404 23.02.18 10:28 Сейчас в теме
(46) Да, ЗУП сложен, но как по мне для юзеров он стал куда проще, да как и для меня.
Анализ данных в регистрах упростился, главное понять для себя поток данных, что от чего зависит и куда пойдет.
59. acanta 45 23.02.18 10:52 Сейчас в теме
(58) Прикольно кстати. Бухгалтерия сложна, главное понять принцип двойной записи.
(18) +Программист может подменять любого работника на время его отпуска или на время поиска/обучения нового работника.
Если программист может подменять ТОЛЬКО генерального директора - это не программист.
62. Brawler 404 23.02.18 11:53 Сейчас в теме
(59) Бухгалтерия сложна в части налогового учета (где и как правильно учесть затраты по большей части), а принцип двойной записи вообще элементарщина, из одной копилки вынь, в другую положи, в одном месте убыло, в другом прибыло, тут главное запомнить номера копилок и их смысл (Консультант+ в помощь). Ровно такие же проблемы у людей с пониманием копирования файлов на диске и самое сложное с вырезанием в одном месте и вставкой в другом. Меня порой веселит, как в крупных конторах, в бухии сидят отдельные бушки под отдельный вид учета, ну допустим только занимается учетом ОС и НМА, а другая списанием в производство, третья на приходных накладных, четвертая на продажах... и блин вроде бушки и должны шарить во всем дебете с кредетом, а не взаимозаменяемые...

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

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

Все должны заниматься своим делом, однако на долю прогеров 1С свалилась такая ноша, что приходится шарить в своем деле и предметных областях с ним связанных, и случается так, что шаришь лучше юзеров работающих в системе. А, ну и раз ТЫЖ ПРОГРАММИСТ, ты должен шарить во всей админской/сервисной тематике и как два пальца об асфальт заправить любой картрижд, усилить громкость звука в скайпе...
67. acanta 45 23.02.18 16:05 Сейчас в теме
(62)
Генерала прогер тоже не заменит, так как найдутся люди по рангу выше его, но ниже генерала.

Канэчна найдется! Свято место пусто не бывает.
Но ПРОГРАММИСТ стоит ДЕШЕВЛЕ.
В лучшем случае через какое то время фикси деградирует до банального гастарбайтера - штрейхбрекера.
Посему пользы от своевременной перемены мест работы гораздо больше чем неудобства от ошибок в коде, доставшихся от коллег или коллегам по цеху.
61. leosoft 128 23.02.18 11:51 Сейчас в теме
(58) Игорь, речь не о сложности интерфейса, а о перегрузке количества регистров. Вы же прекрасно знаете, что творилось и продолжает твориться с НДФЛ с декабря в 3.1.4 и далее...
64. Brawler 404 23.02.18 12:23 Сейчас в теме
(61) Проблема не столько в типовых конфигурациях 1С, сколько в даунизме наших законотворцев... то ли еще будет...
115. e-tixom 87 28.02.18 15:54 Сейчас в теме
(58)Вы, когда подобные комментарии пишете, пишите от своего имени. В нашей фирме еще ни один юзер не дал положительного отзыва об интерфейсе "Такси". У меня вот тоже в голове не укладывается: как такая фундаментальная опция "Изменить вариант отчета" могла угодить в меню "Прочее". Или, например, как среднестатистическому пользователю объяснить, что две кнопки "еще" на форме документа относятся к разным объектам формы? Я даже после года работы их путаю.
116. Dzenn 273 28.02.18 16:39 Сейчас в теме
(115) Интерфейс "Такси" — самый лучший интерфейс из всех возможных. А придираться по мелочи можно к чему угодно.
Dmitri93; +1 Ответить
120. e-tixom 87 02.03.18 10:17 Сейчас в теме
(116)А я не придираюсь. Но законы человеческого восприятия еще никто не отменял. После дня работы с этим "такси" в глазах строчки прыгают и руки трясутся. Потому что на экране все прыгает. Приходится зрение напрягать и руки, чтоб попасть точно в цель. Ну я лично эту тему закрываю. Какой смысл спорить с теми, кто нам работу дает? Бесполезно это.
102. Nelli_A86 28.02.18 08:28 Сейчас в теме
(46)По крайней мере, информацию из них получать стало гораздо проще. Интереса ради, попробуйте посчитать среднюю ЗП в ЗиУП 2.5 или загляните в процедуру автозаполнения Отражения зарплаты в бух. учете, после этого ЗиУП 3 со своими регистрами просто праздник...
114. leosoft 128 28.02.18 12:28 Сейчас в теме
(102) Особенный "праздник" начинается с разборками 6-НДФЛ. :)
Dmitri93; +1 Ответить
5. ksnik 296 21.02.18 18:53 Сейчас в теме
У меня тоже есть методички о программировании, даже по проектированию программ и разработке, так же в 1С, кое-что выложено здесь на Инфостарте.

Я раньше работал доцентом в институте (впрочем до преподавания был админом, разбирался с 1С, поработал немного во франче но зарабатывал не много). После 5 лет преподавания сейчас уже 6 лет профессиональный 1Сник. Спустя шесть лет данной публикацией навеяло кое-что добавить.

Видел я разных студентов и учителей, программистов и начальников. Сам я постигал азы программирования с детства на коленке, курсов не кончал, а преподавал так - компилировал учебники и статьи из интернета, смотрел, показывал и делал видеокурсы, практическими заданиями правда все больше готовыми пользовался. По роду деятельности программистом после института и в возрасте уже нет особой возможности много учиться, так что я - программист из окопа, занимался по началу все больше оперативной деятельностью, много был на поддержке пользователей в чем не особо пригодилось чему учили и чему учил, так как на первом месте даже не качество а объем и скорость разработки, ну и соответственно умение в 100 процентов случаев достигать положительного результата. Даже если в текучке ошибся - пользователь напишет или сам позвонит и покажет, все такое в рабочем режиме без проблем устраняется. Очень полезная штука в организации труда на поддержке Битрикс, документооборот с заявками на ИТ. Вот если неправильно разработать метождику проекта или не до конца продумать, вот тут уж проблема может быть гораздо серьезнее.

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

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

В проектной деятельности больше всего помогает знание основ моделирования IDEF и чтение SAP ARIS (но рисовать схемы ARIS трудоемко). Всяко и прежде всего надо обязательно начинать проекты с продуманного ТЗ потому что без него понимание и общение с заказчиком проекта очень непросто складывается.

А программирование, что уж тут, 7 операторов да объектная модель... Оно и к месту, что статья такая коротенькая. Больше всего оказалось нужно для использования меня по назначению как 1Сника - выучить используемые на предприятии конфигурации, научиться помогать сотрудникам, помогать бухгалтерам, разбираться в коде, искать ошибки в учете... Ну и конечно на производстве в области программирования даже в оперативной деятельности, особенно как правило систем несколько (учетные, складские, транспортные,...), сложные задачи.
vakham; Adam12345678; AtPups000; +3 Ответить
10. swimdog 582 21.02.18 23:44 Сейчас в теме
(5) Пора статью писать, "Мой путь в 1С"
26. logarifm 1020 22.02.18 12:13 Сейчас в теме
(5)Все круто, я думаю у многих по-разному сложилось в жизни только вот к чему эта исповедь?
42. ksnik 296 22.02.18 14:09 Сейчас в теме
(26) в соответствии с темой обсуждаемой статьи я написал о том что оказалось мне полезным для развития как 1Снику. И дополнительно захотелось привести ссылку на бесплатные методические указания по общим вопросам разработки, в том числе на 1С.
6. uri1978 122 21.02.18 19:07 Сейчас в теме
8. Информация не должна дублироваться. Информация не должна дублироваться. Информация не должна дублироваться. Если Вам нужен какой-то необычный срез данных, лучше использовать временные таблицы или сложные запросы, чем дублировать информацию в новый регистр или справочник.


Не соглашусь. Денормализация БД иногда единственный выход чтобы заметно ускорить работу на огромных базах.
vaskomain; Pervuy; creatermc; корум; lina_00; МихаилМ; boln; Artem-B; acanta; ipoloskov; dj_serega; pbabincev; Ликреонский; baton_pk; bulpi; sovital; gubanoff; wbazil; klinval; Dream_kz; AlX0id; asved.ru; Art1387; Zeskord; neikist; YOr!k; Yashazz; +27 Ответить
7. Dzenn 273 21.02.18 19:09 Сейчас в теме
(6) Ну тогда это не дублирование, а денормализация)
8. Yashazz 2312 21.02.18 19:22 Сейчас в теме
(6) Да. Ничто не догма. Иногда приходится идти на чудовищные с точки зрения теории и "хорошего тона" решения. Они уродливы, ненормализованны, задублированны, как угодно ещё страховидны. Но эти решения дают отличную производительность. Помните, вы не эстетствуете и не пытаетесь "1С-Совместимо" получить (что вообще анекдот, учитывая, как они сами свои стандарты не соблюдают), вы делаете решение. Решение проблемы. И если временные таблицы сжирают оперативку сервера, а наплодить регистров - это выход, то почему бы нет?
sulfur17; acanta; user774630; Art1387; ksnik; +5 Ответить
53. triviumfan 7 22.02.18 18:25 Сейчас в теме
(8)
что вообще анекдот, учитывая, как они сами свои стандарты не соблюдают

О чём конкретно речь? Приведи примеры, пожалуйста.
12. YOr!k 86 22.02.18 02:13 Сейчас в теме
(6) я бы этот совет вообще перевернул с точностью до наоборот:

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

практически всегда под сложный отчёт / механизм лучше предусмотреть отдельные регистры, чем городить сложные, непонятные и медленные запросы и алгоритмы

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


Ещё из спорного:
"7. Реализация очень сильно зависит от постановки задачи" -> "Эффективность реализации очень сильно зависит от того насколько одинаково понимают задачу (её прикладной смысл и область применения) "постановщик задачи" и "исполнитель задачи (программист)"

"12Б Лучше вообще не ввести документ, даже если это приходная накладная на миллион долларов, чем ввести его неправильно" -> "лучше закрыть часть проблемы оперативно, чем ждать когда появится возможность закрыть всю проблему сразу"
wonderboy; sulfur17; creatermc; ipoloskov; klinval; Morkhe; Art1387; Zeskord; +8 Ответить
15. asved.ru 36 22.02.18 08:24 Сейчас в теме
(12) +++
95% населения - идиоты разработчиков не имеют ни представления о механизмах работы СУБД, ни прогноза на объемы обрабатываемой информации. Т.е. не могут сказать, как будет работать тот ли иной запрос на продуктивной базе.
103. vaskomain 28.02.18 08:53 Сейчас в теме
(15) Иногда об этом (объемы обрабатываемой информации) не знают даже конечные пользователи. Жизнь очень переменчива - оптимизация это не "что-то что сделал раз и потом все время хорошо работает". Оптимизация - это постоянный процесс, причем иногда оптимизация заранее даже вредна (об этом писал еще Кнут)
101. Dragonim 89 28.02.18 08:01 Сейчас в теме
(6) Просто человек ни когда не смотрел движение по регистрам в ERP. Там дублирование это основа основ, и что-то мне подсказывает это не с проста.
106. Dzenn 273 28.02.18 10:06 Сейчас в теме
(101)
(6) Просто человек ни когда не смотрел движение по регистрам в ERP. Там дублирование это основа основ, и что-то мне подсказывает это не с проста.
не путайте дублирование с учётом
11. mitia.mackarevich 23 22.02.18 02:00 Сейчас в теме
Все конечно здорово. Но(теперь моя очередь быть кэпом) прошу добавить самое главное - делайте бэкапы. Вернее не так, правильно - делайте и проверяйте бэкапы. Иначе рискуете остаться пандой=)))
ipoloskov; bulpi; +2 Ответить
14. Art1387 4 22.02.18 08:00 Сейчас в теме
(11)Если установлен Microsoft SQL Server то проще через агент регламентное задание настроить, на бэкап и разворачивание бэкапа на тестовую базу. Заодно и тестовая база со свежими данными будет под рукой.
13. HAMMER_59 74 22.02.18 07:19 Сейчас в теме
Уровень абстрактности статьи крайне высок, те кто уж прошел такой же путь как автор - поймут, остальные могут и не принять.
"Код программы должен быть простым" я думаю слово понятным подходит больше. Мысль то правильная и хорошая, можно еще добавить, то что понятно здесь и сейчас, в другое время может стать абсолютно непонятным.

Также программа должна быть без ошибок, а еще должна быть оптимальна с точки зрения производительности и масштабируемости.
16. AlexGroovy 22.02.18 09:10 Сейчас в теме
Жалко,что разработчики типовых конфигураций далеко не всегда следуют этим правилам)))
sergathome; +1 Ответить
17. TODD22 17 22.02.18 09:11 Сейчас в теме
(16)
Жалко,что разработчики типовых конфигураций далеко не всегда следуют этим правилам)))

Так устроился бы в 1С и научил бы их там всех программировать. За одно и качество тиражных решений поднял.
ZUL_MTFKA; dj_serega; tinkerbell; mitia.mackarevich; +4 1 Ответить
48. ybatiaev 44 22.02.18 16:31 Сейчас в теме
(17) Как то писал разработчикам расширения что они рожают очередного монстра. Тем более у меня был опыт сопровождения системы IBSO (Новосибирск) с подобным ПРОСТЫМ механизмом. Кто там будет слушать то? Практически всегда ответ что "САМ ДУРАК и не понимаешь всей тонкости реализации". В системе IBSO в модулях расширениях(хуках) лежали только те модули, в которых меняется код, а не всё подряд(формы, реквизиты, доп. объекты метаданных). Помнится делал одно простое расширение, так у меня в это расширение 10% всей конфигурации перенеслось. "Круть"... Хотя есть и плюсы, более просто сделать изменить форму, не сталкивался правда с тем, что обновление конфигурации потребует обновить форму пока, скоро наверно уже начнётся.
Dmitri93; AlexGroovy; +2 Ответить
23. Dzenn 273 22.02.18 11:13 Сейчас в теме
(16) в основных типовых решениях — следуют в полной мере.
41. AlexGroovy 22.02.18 13:18 Сейчас в теме
(23)О да,особенно в ДО,прям ягодка.Печатные команды добавлены кнопками на форме!!!!
И куча избыточных процедур где сверху в комментариях чётко написано,что нам пока это менять лень,в будущих релизах уберём.
sergathome; uri1978; +2 Ответить
51. uri1978 122 22.02.18 17:19 Сейчас в теме
(41) В WMS тоже "интересный подход" - строки табличной части документа - это отдельные документы. Проводки делают не сами документы, а спец. документы им подчиненные. Изменение статусов документов регламентными заданиями, провел кладовщик и ждет когда статус документа поменяется. Я понимаю, что это такое архитектурное решение, но нельзя же так.
В ДО точно такая же ситуация - задумка хорошая, реализация мрачная. Система прав вообще жесть.
sergathome; AlexGroovy; +2 Ответить
66. genayo 23.02.18 15:55 Сейчас в теме
(51)Почему так сделано в WMS, и что этот подход дает - вы просто не поняли. Про ДО согласен на 100%.
68. uri1978 122 23.02.18 17:57 Сейчас в теме
(66) WMS очень удобен, особенно удобны рабочие места. Кладовщиков от увольнения спасло повышение зарплаты :). Франчайзинг отчитался о еще одном "успешном" внедрении 1С. К отваливаниям ТСД уже привыкли, очищать регистр "Текущее действие пользователя ТСД" кладовщики обучены. В общем "Всё хорошо прекрасная маркиза, всё хорошо, всё хорошо".
98. sergathome 27.02.18 09:32 Сейчас в теме
(41) ДО и ЗУП 3 - два достойных образчика соблюдения стандартов, ага. Больше всего, конечно, раздражает основной код на формах. В ДО, например, весь движок исполнения задач сдублирован - для интерактивного исполнения - всё на формах, для фонового-по почте - правильно, вроде, сделано, в модулях и объектах, но тока с ошибками и функционал не полный. В ЗУПе же, например, весь расчет отпусков на - форме...
18. VZyryanov 22.02.18 09:26 Сейчас в теме
Правила 12 это не про программирование.
Правило 0. Программист не должен подменять собой генерального директора.
vaskomain; acanta; +2 Ответить
19. Somebody1 67 22.02.18 09:33 Сейчас в теме
Хочется поспорить с п. 8 - "Информация не должна дублироваться". Иногда для повышения быстродействия алгоритма приходится хранить информацию с избытком. Например, для формирования какой-то сложной отчётности необходимо заранее готовить данные и хранить их отдельно от исходных данных, чтобы потом быстро собрать в отчёт. Таким образом, мы храним информацию избыточно, но повышаем скорость формирования отчёта.

А вот дублирования программного когда следует, конечно, избегать.
20. uri1978 122 22.02.18 10:22 Сейчас в теме
Пункт 0
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
Стив Макконнелл
Dmitri93; TreeDogNight; AlexGroovy; ipoloskov; dj_serega; bulpi; +6 Ответить
25. Vovan1975 14 22.02.18 12:05 Сейчас в теме
(20) правда непонятно как быть если ты сам склонный к насилию психопат...
29. logarifm 1020 22.02.18 12:16 Сейчас в теме
97. ripreal1 194 27.02.18 09:21 Сейчас в теме
(29)
К этой книге надо добавить постфикс for dummies
21. uri1978 122 22.02.18 10:49 Сейчас в теме
Пусть меня закидают камнями, но я скажу. Основная проблема в том что "программист 1С" собственно программистом не является. Все эти прописные истины, которые привел автор статьи преподаются или еще в школе или на первом курсе института. Изложены в книгах (пример выше приводил - "Совершенный код. Стив Макконнелл"), но увы 1С-ники с этим не знакомы. Начинают не с азов программирования, а сразу с кода. Отсюда и имеем пресловутые "запросы в цикле". Порог вхождения очень низок и это сыграло злую шутку.
sergathome; МихаилМ; Yashazz; neikist; acanta; Infactum; dj_serega; ybatiaev; AlexCherdakov; +9 Ответить
22. Dzenn 273 22.02.18 11:11 Сейчас в теме
(21) Вы правы, мистер д'Артаньян
pbabincev; user774630; +2 Ответить
36. tinkerbell 22.02.18 12:48 Сейчас в теме
(21) Да, я только через несколько лет работы узнала, что запрос в цикле - это не хорошо. Но самое ужасное - когда такое пишут программисты с 15-летним стажем и при этом ругают платформу 1с...
104. vaskomain 28.02.18 08:55 Сейчас в теме
(21) Порог вхождения низок теперь везде, не только в 1С, но и во всяких frontend / backend системах веб
108. Dzenn 273 28.02.18 10:08 Сейчас в теме
(104)
(21) Порог вхождения низок теперь везде, не только в 1С, но и во всяких frontend / backend системах веб
низок, высок — это всё оценочные характеристики. Хорошие специалисты всегда будут цениться, вне зависимости от наших представлений о пороге.
24. uri1978 122 22.02.18 11:22 Сейчас в теме
27. Vovan1975 14 22.02.18 12:14 Сейчас в теме
все гораздо проще.
Основной принцип - "делай это проще".
И пофик на запросы в цикле и прочих макконеллов.
30. logarifm 1020 22.02.18 12:18 Сейчас в теме
(27)Относится к Макконнеллу в таком тоне может только бездарность которая ленится даже синтаксис читать.
TreeDogNight; +1 Ответить
32. Vovan1975 14 22.02.18 12:20 Сейчас в теме
(30) бгг... Взрослый вроде дядя, а такой наивный...
31. Dzenn 273 22.02.18 12:19 Сейчас в теме
(27) принцип "keep it simple, stupid" работает, но до определённого предела
38. Vovan1975 14 22.02.18 12:51 Сейчас в теме
33. bulpi 137 22.02.18 12:22 Сейчас в теме
" Если пользовательский интерфейс перегружен реквизитами и полями, назначение которых понятно только избранным или требует отдельной инструкции, значит, интерфейс очень плохой. "

Это аксиома. Следствие : все типовые конфигурации очень плохие :)
sergathome; zqzq; +2 Ответить
34. c1nil 22.02.18 12:22 Сейчас в теме
Может быть стоит начать с изучения документа "Система стандартов и методик разработки конфигураций для платформы 1С"? У меня нет подписки на ИТС, но получить его не составило большого труда.
37. logarifm 1020 22.02.18 12:49 Сейчас в теме
https://its.1c.ru/db/v8std
Тут все это прекрасно описано.
puzakov; nytlenc; +2 Ответить
39. herfis 270 22.02.18 13:00 Сейчас в теме
С прописными истинами есть одна смешная проблема.
Либо ты уже их выстрадал сам и для тебя это банальности, не стоящие упоминания в приличном обществе, либо ты еще в начале пути и для тебя они - брюзжание пердунов, неправильно расставляющих приоритеты и талдычащих одну и ту же неважную фигню (тут хоть как-то работающий код написать бы).
fvadim; zarucheisky; user774630; +3 Ответить
40. Vovan1975 14 22.02.18 13:07 Сейчас в теме
(39) есть еще один момент - когда ты их применяешь на практике и вдруг выясняешь что стало еще хуже.
ipoloskov; +1 Ответить
43. nytlenc 268 22.02.18 14:10 Сейчас в теме
Блин ну зачем всякую ерундистику писать? Есть давно разработанная система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8. Ссылка дана была выше https://its.1c.ru/db/v8std
47. pbazeliuk 1502 22.02.18 15:25 Сейчас в теме
А вот эти ребята автоматизировали проверки по стандартам https://sonar.silverbulleters.org
Код и решения получаются более качественными.
49. zarucheisky 22.02.18 16:55 Сейчас в теме
52. nixel 536 22.02.18 18:10 Сейчас в теме
(49) угу. Пётр один из наших клиентов (надеюсь, что благодарных)
54. pbazeliuk 1502 22.02.18 20:50 Сейчас в теме
(52) когда не делал code review 2 месяца под ряд и решил посмотреть на качество, очень приятно удивился, что программисты хорошо так выросли.
55. pbazeliuk 1502 22.02.18 20:51 Сейчас в теме
56. ksnik 296 23.02.18 07:35 Сейчас в теме
(55) Вы проводите непрерывный анализ и измерение качества задачи размером 8 тысяч строк кода. Я создавая и поддерживая на едине с пользователями программы большего размера (к примеру розничный автозаказ товаров) не вижу смысла использования системы непрерывного анализа и измерения качества. В попыхах несколько раз делались и всплывали очень досадные ошибки (при желании по быстрому реализовать новую частную функцию и связанные с не предупреждением отказов отдельных компонентов системы). К примеру в резутьтате "блокировки" не записан и не проведен документ из цепочки автоматически выполняемых действий или не изменено значение константы. Данные узкие места, и например то, что один из регистров сведений тяжелый для чтения/записи, по опыту знаю только я, кто кроме меня может это обнаружить? Эффективно ли привлекать особых специалистов проверять не большую программу? Не возрастут ли затраты собственных программистов на мониторинг качества кода в ущерб функциональности? Как в Вашей системе непрерывного анализа и измерения качества реализована проверка конечного результата работы задачи при каждом варианте настройки тестируемой системы и проверка на отказоустойчивость?
57. pbazeliuk 1502 23.02.18 09:27 Сейчас в теме
(56) 8 тысяч это ядро, на то оно и открытое. В целом проект имеет плагинов еще на 20 тыс. строк кода.
Для плагинов есть тесты, которые хранятся в отдельном каталоге и на количество строк кода они не влияют.

(56)
К примеру в резутьтате "блокировки" не записан и не проведен документ из цепочки автоматически выполняемых действий или не изменено значение константы.

Не понимаю проблем с блокировками, если есть проблемы нужно повышать свой уровень знаний и четко понимать, что будет происходить в СУБД при том или ином действии. Например, в среднем у меня 1 deadlock за месяц на 200-300 сеансов онлайн в режиме 22/7/363. Необходимо собирать журналы и мониторить состояние системы, определить ключевые показатели которые важны для функционирования бизнеса.

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

Не понимаю, что значит тяжелый, если возникают проблемы с записью, параллельностью - есть рекомендации от фирмы 1С и курсы экспертов 1С.
Все что вы написали возникает от недостатка знаний. Инструментов есть множество бери и используй.

(56)
Эффективно ли привлекать особых специалистов проверять не большую программу?

Если возникают проблемы производительности - да. Если это автоматизированные проверки почему бы и нет?

(56)
Не возрастут ли затраты собственных программистов на мониторинг качества кода в ущерб функциональности?

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

(56)
Как в Вашей системе непрерывного анализа и измерения качества реализована проверка конечного результата работы задачи при каждом варианте настройки тестируемой системы и проверка на отказоустойчивость?

Конечный результат только тестирование (ручное, автоматическое, нагрузочное), постоянное измерение внутренних показателей работы системы и анализ данных в будущем.
Нанимать правильных программистов, которые знают и умеют это делать с помощью инструментов:
https://infostart.ru/public/569431/
https://infostart.ru/public/597500/
zeegin; Yashazz; nixel; acanta; +4 Ответить
50. tailer2 22.02.18 17:00 Сейчас в теме
Если Вы не можете описать простыми словами, как работает Ваш алгоритм, значит, Вы неправильно выполнили задачу, или недостаточно хорошо умеете повышать уровни абстракции.


это частный случай, в общем виде это так:

Если вы не можете объяснить что-то на пальцах добросовестному дураку, вы сами не понимаете этого.
60. acanta 45 23.02.18 11:03 Сейчас в теме
(50) класс.. умный в любом случае разберется, даже если вы сами этого не понимаете.
63. Nikola23 406 23.02.18 12:20 Сейчас в теме
1
Вы пишете код для человека, не для программы или компьютера. Делайте код понятным, чтобы человек, который будет разбираться в нём через полгода или год или два, мог легко это сделать

В целом с утверждением согласен. Программы для программистов? За 10ть лет следовало бы понять, что программы - для пользователей.

8

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



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

9
Если схожая задача возникает 3 раза, значит, она возникнет ещё 300 раз, и пора подумать о создании универсального механизма

Код необходимо сразу писать с расчетом на многократное использование.
69. genayo 23.02.18 18:50 Сейчас в теме
Какая система у вас? По описанию вроде не акселот, или всеже?
70. puzakov 25.02.18 18:26 Сейчас в теме
Если НакопленныеДанные.МожноСклеить = Истина Тогда

Вай-вай...
herfis; acanta; +2 Ответить
71. Dzenn 273 25.02.18 20:42 Сейчас в теме
(70) Смущает явное сравнение? Явные сравнения легче читаются. В типовых конфигурациях они сейчас используются намного чаще, чем раньше.
vaskomain; +1 Ответить
73. acanta 45 25.02.18 23:38 Сейчас в теме
(71)
Явные сравнения легче читаются.

Истина в том, что склеить накопленные данные нельзя. Даже если они читаются.
74. Dzenn 273 25.02.18 23:48 Сейчас в теме
(73)
Истина в том, что склеить накопленные данные нельзя. Даже если они читаются.
это ключ структуры
75. TODD22 17 26.02.18 07:12 Сейчас в теме
(71)
В типовых конфигурациях они сейчас используются намного чаще, чем раньше.

Например в Рознице 1000+ раз встречается явное сравнение в условии.

И есть ещё функции платформы у которых возвращаемый результат может быть как булево, так и ссылочное значение.
76. herfis 270 26.02.18 10:26 Сейчас в теме
(71)(75) Фигня какая-то. Если название переменной/свойства уже соответствует булеву, то явное сравнение с литералом только затрудняет чтение.
Вот сравните два предложения, только читайте не как код (а то я смотрю, у вас уже глаз замылился), а как произведение:
"если можно склеить тогда"
"если можно склеить равно истина тогда"
77. TODD22 17 26.02.18 10:34 Сейчас в теме
(76)Я никому вроде не советую писать явное сравнение и сам его не пишу. Я только написал что в типовых это встречается и часто.

Явное сравнение может быть тогда когда не известно возвращает функция результат в виде булево или она может возвращать что то отличное от булево.
Например функция "БезопасныйРежим()" и тд.
у вас уже глаз замылился

Вы слишком буквально понимаете правила.
80. herfis 270 26.02.18 10:40 Сейчас в теме
(77)
Явное сравнение может быть тогда когда не известно возвращает функция результат в виде булево или она может возвращать что то отличное от булево.

Так тогда и вариантов других нет :) Но в этом случае и давать переменной/свойству название, однозначно подразумевающее булево - в корне неверно.
То есть назвать функцию ЭтоБезопасныйРежим() и позволять ей возвращать что-то отличное от булево - грубая стилистическая ошибка.
А если функция ЭтоБезопасныйРежим() будет возвращать, как ей и положено, только булево, то стилистической ошибкой будет уже использовать ее явное сравнение с литералом.
Это мои личные правила, которые я понимаю да - буквально :)
Артано; sergathome; +2 Ответить
82. TODD22 17 26.02.18 10:44 Сейчас в теме
(80)
То есть назвать функцию ЭтоБезопасныйРежим() и позволять ей возвращать что-то отличное от булево - грубая стилистическая ошибка.

Однако с этими ошибками приходится работать.
Например функция платформы "БезопасныйРежим()"
90. herfis 270 26.02.18 11:03 Сейчас в теме
(82) Я не зря привел в пример название "ЭтоБезопасныйРежим" - это название не оставляет неоднозначности в части возвращаемого значения. Ответом может быть только да или нет. "БезопасныйРежим" такой однозначности не дает.
Но я соглашусь, что функция БезопасныйРежим() - пример плохого дизайна. Зачем ориентироваться на плохие примеры? :)
Ежу понятно, что если какая-то функция может возвращать не только булево, то остается либо явное сравнение, либо предварительная проверка типа.
92. TODD22 17 26.02.18 11:10 Сейчас в теме
(90)
Зачем ориентироваться на плохие примеры? :)

Так я на них не ориентируюсь. Но с этим приходится работать.
Ежу понятно, что если какая-то функция может возвращать не только булево, то остается либо явное сравнение, либо предварительная проверка типа.

Так об этом и речь. Проблема то в том что приходится работать с чужим кодом. И не всегда кто то другой взял и сделал правильно.
Я просто уже несколько раз так попадал.
93. herfis 270 26.02.18 11:16 Сейчас в теме
(92)
Так об этом и речь. Проблема то в том что приходится работать с чужим кодом. И не всегда кто то другой взял и сделал правильно.
Я просто уже несколько раз так попадал.

Очевидно, я просто неправильно понял ваш изначальный комментарий. Что вы мол, поддерживаете, а не возражаете. Перечитал и понял, что ошибся.
Оставьте свое сообщение