Наши принципы разработки используемые при разработке конфигурации ИТ Управление
Четкие принципы в программировании, работе с клиентами, создании пользовательских интерфейсов. Это существенно облегчает работу с программой для пользователей и сопровождающих программистов.
Общие принципы:
- Уважительные отношения с клиентами и пользователями программ, выполнение взятых на себя обязательств качественно и в срок.
- Основа разработки - правильная и четкая структура данных. Если в программе есть правильная структура данных то нарастить на эту структуру удобные интерфейсы, красивый дизайн проще и легче. Сделать плохо структурированную программу удобной и гибкой - сложно или даже невозможно.
- Разработка интуитивно понятных программных продуктов. Пользователи в большинстве своем не любят читать документацию, и часто не имеют на это достаточного количество времени.
- Разработка должна быть дружественной пользователю. Она должна быть для пользователя, а не пользователь для нее. Из этого следует несколько выводов:
- Программа не должна по возможности задавать вопросы пользователю, наоборот она должна отвечать на них.
- Документация нужна любой разработке, но пользователь имеет ПРАВО не пользоваться ей. Документация не должна служить "затычкой" неправильных решений в области структуры данных и пользовательских интерфейсов.
- Разработка должна быть легко конфигурируема под вкусы большинства пользователей с помощью легко настаиваемых параметров. Параметры по умолчанию должны быть настроены максимально удобно и под наибольшую аудиторию пользователей. То есть, средний пользователь программы может продолжительный период пользования программой работать без захода в диалоги настройки программы.
- При разработке учитываются рекомендации ведущих производителей программных продуктов, таких например как 1C, это позволяет пользователям знакомых с продуктами этих производителей быстрее разобраться с нашими разработками.
- Интерфейс программы максимально стандартизуется, то есть формы документов, справочников приближены к друг другу для того чтобы пользователю понимающему интерфейсу одного блока программы, легко работать с другим новым для него блоком.
- Диалоговые формы программ должны быть аккуратны, просты и удобны, кроме того элементы форм должны быть выровнены по сетке. Все интерфейсы должны создаваться в одном стиле, который учитывает основные принципы дизайна.
- Программа пишется для максимально возможного круга пользователей, и поэтому она должна быть как можно полнее подходить максимальному кругу пользователей, без дополнительного конфигурирования ее сторонними программистами (разработчиками).
- Минимизация исключительных ситуаций. Если все же исключительная ситуация появилась, то пользователю должны быть выведено краткие и в тоже время максимально понятные сообщения.
Любую программу, даже самую универсальную и гибкую, возможно понадобится дополнительно конфигурировать и изменять в соответствии с изменившимися потребностями и вкусами пользователей. Исходя из этого мои принципы распространяются не только на видимую часть программы, но и на ее внутренний механизм.
Принципы программирования
- Программа должна быть максимально конфигурируемой без автора программы. Поэтому я по возможности придерживаюсь принципов открытых кодов (Open source).
- Программные коды разработок должны быть понятными для программистов моих партнеров и клиентов. Для этого я придерживаюсь основных принципов программирования принятых в широких кругах, а так же некоторых собственных.
- Построение кода лесенкой, в качестве выравнивания используется Tab. После запятой используется разделитель пробел. Исключительные случаи обрабатываются в начале, для того чтобы вложенность лесенки была минимальной.
- Использование префиксов по нескольким причинам:
- Для того чтобы можно было знать тип переменной, не видя ее инициализацию (в 1с эта проблема особенно острая так как любая переменная может принимать абсолютно любой тип данных).
- Для того чтобы знать где переменная определена (в каком контексте).
- Чтобы избежать ошибок, связанных с пересечением переменных различных контекстов.
Первый префикс обозначает место определения идентификатора:- Для обозначения глобальных переменных и процедур префикс не используется, например"ВыборЭлемента()", "Пользователь". Переменная считается глобальной если при ее определении используется ключевое слово "Экспорт".
- "м" - для переменных, функций и процедур модуля, например "мВыборЭлемента()", "мТзОсновная". Процедура или функция модуля используется без префикса только в одном случае - если она предопределенная.
- "п" - для параметров функций и процедур, например "мВыборЭлемента(пЭлемент, пСписокПараметров)"
- "л" - для локальных переменных в функциях и процедурах, например "лТзДокументы"
- Для переменных форм префикс не используется.
Второй префикс обозначает тип идентификатора (используется как для переменных, так и для функций):- "Тз" - для типа "ТаблицаЗначений". ("лТзКомплектующие")
- "Таб" - для типа "Таблица". ("мТабПечатнаяФорма")
- "Сп" - для типа "СписокЗначений". ("СпПараметры")
- "Мета" - для типа "Метаданные".
- Идентификаторы процедур, функций и переменных, должны как можно более понятно отражать их суть.
- Идентификаторы должны быть синтаксически верными и содержать как можно меньше сокращений. Если сокращения все же использованы, то они общеприняты и понятны.
- Все закомментированные строки кода удаляются после окончания разработки, если их не предвидится использовать в будущем, при доработке или внедрении программы.
- Программный код должен быть разбит на короткие логически понятные части, процедуры и функции по возможности не должны быть длиннее одного экрана.
- Код не дублируется, так как это приводит к потерям времени при сопровождении и ошибкам в будущем при дальнейшем развитии программы.
- Отладочные сообщения должны быть убраны до сдачи работы пользователю.
- Используется как можно меньше глобальных переменных и переменных модуля, по причине того что множество переменных затрудняет читабельность и уменьшает гибкость программы (Следить за изменениями множества глобальных переменных тяжело).
- Все процедуры, функции, блоки должны по необходимости содержать комментарий, обычно это нужно в том случае, если сразу не понятно КАК блок работает, или ЧТО он делает. Но даже в этом случае перед добавлением комментария необходимо задаться вопросом почему не понятно сразу, как работает данный блок, возможно ли переписать его таким образом чтобы возможно было разобраться в нем без комментария. Комментарий не должен использоваться как затычка в сложном и плохо написанном коде.
- Делается все возможное чтобы сопровождающий программист мог не трогать основной код и структуру программы (выделяется неизменяемое ядро программы), а преимущественно дополнять без внесения изменений, которые придется отслеживать в будущем при обновлении на следующие релизы.
Редакция от 08 октября 2015 г.
(с) Пушин Владимир 2003-2015г.