1
Вы пишете код для человека, не для программы или компьютера. Делайте код понятным, чтобы человек, который будет разбираться в нём через полгода или год или два, мог легко это сделать. Возможно, этим человеком будете Вы, только через год Вы уже не вспомните, что там где подразумевалось "по умолчанию"
2
Помните, что телепатов нет. Ещё раз. Телепатов нет. Код, а равно и интерфейс пользователя, должны быть понятными и не должны содержать умолчаний, понятных только Вам.
3
Названия переменных "Пер1", "А", "Сп" допустимы только в студенческих работах, отладочных обработках или крайне простых процедурах, но не в промышленных решениях. Название переменной должно отражать её содержимое, в крайнем случае нужно оставлять комментарий при её инициализации.
4
Процедуры и функции должны быть как пуля — небольшими и быстропонимаемыми. Вернее, процедуры и функции могут быть большими, а иногда и очень большими, но только в том случае, если они остаются безопасными (пункт 5), то есть название процедуры отражает суть её действия, не больше и не меньше.
// добавление подписантов в файл PDF (последней страницей) из таблицы подписантов в 1С,
// а также добавление нумерации страниц
Процедура ПолучитьФайлСНумерациейИПодписями(НакопленныеДанные)
ОпределитьВозможностьСклейкиСПодписями(НакопленныеДанные);
Если НакопленныеДанные.МожноСклеить = Истина Тогда
ПолучитьИзначальныйФайл(НакопленныеДанные);
ПодготовитьСредствоРаботыСPDF(НакопленныеДанные);
СгенерироватьФайлСлужебнойИнформации(НакопленныеДанные);
ПолучитьИнтересующиеДанныеИзФайлаСлужебнойИнформации(НакопленныеДанные);
СоздатьPDFСНумерацией(НакопленныеДанные);
СоздатьPDFСПодписями(НакопленныеДанные);
СклеитьФайлы(НакопленныеДанные);
УдалитьВременныеФайлы(НакопленныеДанные);
КонецЕсли;
КонецПроцедуры
5
Процедуры и функции должны быть безопасными, то есть — а) их название должно отражать суть б) они не должны делать то, что от них не ожидается исходя из названия
6
Если Вы не можете описать простыми словами, как работает Ваш алгоритм, значит, Вы неправильно выполнили задачу, или недостаточно хорошо умеете повышать уровни абстракции.
6А
Если Ваше решение сложное и запутанное, значит, количество уровней абстракции, которое Вы использовали, является недостаточным.
6Б
Хорошее сложное решение отличается от плохого сложного решения количеством уровней абстракции.
6В
Единственный способ создать что-то сложное хорошо — увеличивать уровни абстракции. Когда Вы смотрите на руку — Вы думаете о руке, а не о миллиардах клеток, из которых она состоит. Когда Вы смотрите на вену на руке — Вы думаете о вене, а не о лимфоцитах.
7
Реализация очень сильно зависит от постановки задачи.
Можно поставить задачу "отправлять бухгалтеру на почту уведомления о поступлении РКО с видом Подотчёт", а можно поставить задачу "Реализовать универсальный механиз рассылки уведомлений по триггерам". А ещё можно поставить задачу "Найти на Инфостарте универсальный механиз рассылки уведомлений по триггерам".
8
Информация не должна дублироваться. Информация не должна дублироваться. Информация не должна дублироваться. Если Вам нужен какой-то необычный срез данных, лучше использовать временные таблицы или сложные запросы, чем дублировать информацию в новый регистр или справочник.
9
Если схожая задача возникает 3 раза, значит, она возникнет ещё 300 раз, и пора подумать о создании универсального механизма
10
Пользовательский интерфейс должен быть максимально лёгкий. Запрещается перегрузка интерфейса лишними элементами. Любые возможности нужно систематизировать — объединять в группы, выносить на отдельные вкладки и так далее. Если пользовательский интерфейс перегружен реквизитами и полями, назначение которых понятно только избранным или требует отдельной инструкции, значит, интерфейс очень плохой.
11
При разработке пользовательского интерфейса не надо мельчить. Вам доступны полные страницы! Если одновременно показываемых пользователю элементов слишком много, значит, разработка идёт неправильно.
12
Автоматизация повышает эффективность учёта, но при одном условии, которое очень важно выполнять — при условии правильности вводимых данных. Например, если Вы неправильно заполните информацию о номенклатуре, любые автоматизированные обработки номенклатуры станут бесполезны.
12А
Хорошая автоматизированная система — это очень жёсткая диктатура. Эта диктатура может быть просвещённой, и её правила могут быть очень гибкими, но они должны быть абсолютно обязательными к исполнению, если мы конечно хотим получить от АС ту пользу масштабируемости, ради которой всё и затевается. Наказания за нарушения правил диктатуры ведения данных в АС должны быть суровы, иначе человеческий фактор дискредитирует все благие намерения.
12Б
Любой неправильный ввод документа или справочника с откладыванием данных "в мозгу" (типа "потом поправлю") недопустим. Лучше вообще не ввести документ, даже если это приходная накладная на миллион долларов, чем ввести его неправильно. Любой неправильный ввод данных в систему повышает её энтропию и уменьшает доверие к системе, лишая верхних уровней возможностей, для которых АС и предназначена.
13
При проектировании следует чётко и ясно определять уровни взаимосвязи объектов — один к одному, один ко многим, много к одному, много ко многим, и исходя из этого сразу планировать правильную логику. Например, если в чеке для видов оплат сразу спроектировать таблицу "оплаты", всё становится на свои места. Можно платить частично наличными, частично картами, частично яндекс.деньгами. Или наоборот — заранее заложить при проектировании, что вид оплаты должен быть один и только один, а если видов оплаты несколько — оформлять несколько чеков. Оба подхода имеют право на жизнь и свои плюсы и минусы.
