Как научиться писать код в 1с
Что важно для руководителя IT.
За чем нужно следить ведущему программисту.
Что будет помогать программисту.
Что сэкономит вам массу времени.
Что сделает вашу работу профессиональнее.
Идея - Константин Илларионов, Глеб Дунаев
Краткая предыстория
В 2012 году мне досталась в наследство база с сильно измененной конфигурацией УТ 10.3. Эта база дорабатывалась в течении нескольких лет многими программистами (и штатными, и франчайзи). Документации практически никакой не велось, комментарии в коде были скудны и неинформативны, пользователи внедряющие тот или иной функционал уже давно уволились, спросить было не у кого. В некоторых случаях было совершенно непонятно что и для чего делалось и как это работает. И мы решили это прекратить. Были сделаны первые шаги, которые в дальнейшем привели к созданию небольшой системы оформления разработки. Данная система уже два с лишним года успешно функционирует в нашем холдинге и с лихвой окупает время потраченное на нее.
Из чего состоит эта система?
1. Комментарии в коде
2. Справочная информация
3. Цифровые обозначения отчетов/обработок
4. Добавление/изменение объектов
5. Контроль за исполнением
А теперь детально, по пунктам:
1. Комментарии в коде
О чём пойдёт речь. Комментарии в коде делают практически все программисты. Думаю всем понятно для чего они нужны. Комментарий - это признак произведенного изменения и описание этого изменения.
В чём проблема. Часто по комментарию можно понять только одно, то что было сделано изменение :) При этом искать описание этого изменения крайне проблематично (имеется ввиду описание доработки, техзадание), я думаю многие с этим сталкивались: кто-то его сделал и где-то сохранил. надо знать это место. потом умудриться найти нужную информацию. суметь увязать с тем что фактически есть в конфигурации. а может описание и не сохранилось. плюс исполнители часто забывают обновлять информацию об изменениях и она становится неактуальной. В итоге, все эти факторы мешают быстро понять кто, что, когда делал, и что нужно сделать сейчас (и в каком месте!). А если посмотреть на проблему глобально, то выяснится что подобное ведение дел не позволяет быстро оценить отличия вашей конфигурации от типовой, какие контуры затронуты, насколько серьёзны эти изменения и т.д.
Как обычно решается. Смотрим код, пытаемся понять отличия от типовых механизмов, пытаемся понять зачем они сделаны, а если изменения сложны и непонятны - ищем у кого бы спросить (это обычно проще чем самому заниматься исследованиями!), либо сами разбираемся. В итоге на эти "разбирательства" уходит от нескольких часов до нескольких дней, и появляется очень большая вероятность совершить ошибку!
Наше решение. Сначала прошу сравнить комментарии трех программистов (примеры из рабочей базы):
Пример 1:
Пример 2:
Пример 3 (наше решение):
Проанализируем:
1. В первом примере видно:
- где начинается комментарий и где заканчивается
- кто сделал изменения
- когда сделаны изменения (правда ошибка в дате)
2. Во втором примере видно:
- кто сделал изменения
- когда сделаны изменения
3. В третьем примере (наше решение) видно:
- где начало комментария и где он заканчивается
- кто сделал изменения
- когда сделаны изменения
Очевидно что третий пример содержит более информативный комментарий, который в полной мере выполняет свою функцию. И самое главное, для чего собственно это всё нужно, оформляя внесенные изменения подобным образом, вы сохраняете их в одном месте. В самом надежном и доступном. В базе данных. Не в файликах Word и Excel, не в сторонних программах типа Итилиума, не в головах пользователей и программистов, а ВМЕСТЕ с вашей базой данных. И даже по прошествию нескольких лет, можно легко извлечь все изменения, провести "инвентаризацию" системы и понять как сейчас она работает!
Как реализовать:
1. Все комментарии делаем однотипными и начинаем строго с символов "//начало-" ( //начало-ДГ ). Таким образом можно легко найти комментарии ВСЕХ программистов. Если нужно найти комментарии только ОДНОГО программиста - в поиске задаётся "//начало-ДГ". "ДГ" - это инициалы фамилии и имени программиста.
(Примечание: а теперь представьте ситуацию где один программист пишет "begin-end", другой пишет "начало-конец", а третий вообще рисует символы ">> <. будет очень сложно их найти.)
2. Указываем дату изменения ( 08.04.2014 .) Иногда приходится доказывать пользователям что изменения начали работать с начала апреля, а не середины мая как они думают. Или нужно понять в какой последовательности изменения появлялись.
3. Указываем кто заказывал это изменение ( Заказчик Пономаренков П. ). По прошествии времени, очень часто забывается кто и зачем придумал это, указание заказчика поможет восстановить в памяти эту задачу. А если вы совсем забыли, или не участвовали в её реализации, можно получить дополнительную информацию непосредственно у заказчика :)
4. Даём краткое название задаче ( Запись реквизита ДД_Наименование_для_сайта_прайса ). Нужно для краткого указания того что делалось, какие были изменения (1) и для идентификации задачи (2). В этом примере, по краткому названию, видно что изменения касаются определенного реквизита (а не движений по регистру накопления например). А также краткое название позволяет найти ВСЕ места, где код менялся по этой задаче (используем копирование при вставке комментария).
5. Делаем подробное описание задачи ( //Нужно чтобы при любой записи элемента, в этот реквизит . и далее). Нужно для понимания того, что и для чего делалось. Для каждого изменения делается свой комментарий (но первая строка у всех одинаковая!), если требуется сделать общее описание, то оно делается в одном месте. Например:
2. Справочная информация
О чём пойдёт речь. Польза от справочной информации думаю также для всех очевидна. Есть только две маленькие проблемы: обычно справка либо не информативна, либо ее попросту нет :) В нашей фирме, справочная информация делается всегда, подробно, и чаще всего ей пользуются. программисты :)
В чём проблема. У пользователей очень часто возникают вопросы типа: "откуда берет данные отчет", "как считает эта обработка", "что проверяется в документе" и т.д. А самое интересное то, что они уже не первый раз работают с этим отчетом/ обработкой/документом. они просто забыли. или сделали вид что забыли.
Как обычно решается. Что в таких случаях делает программист? Начинает вспоминать или лезет в конфигуратор. И хорошо если это делалось недавно, или алгоритм расчета какой-то простой. А если делалось давно, например несколько месяцев назад? Сколько времени надо потратить, чтобы полностью вспомнить реализованный функционал? Иногда до нескольких часов.
Наше решение. В каждом добавленном или измененном объекте есть нами добавленная справочная информация, и именно она позволяет быстро и красиво (прям на глазах у пользователя) ответить на все интересующие вопросы!
Как реализовать. В типовые объекты (справочники и документы) мы вставляем справку выше одинэсовской. Во внешних отчетах и обработках справка содержится как в самом объекте, так в специальном txt-файле (нужен для просмотра справки без конфигуратора). См. скриншоты:
Справка в программе
Справка внешней обработки
3. Цифровые обозначения отчетов/обработок
О чём пойдёт речь. Поговорим о удобстве работы с внешними отчетами и обработками.
В чём проблема. В один прекрасный день мы поняли что у нас в базе содержится огромное количество обработок и отчетов непонятно кем и для кого написанных, и главное, непонятно что они делают. И кроме этого, с ними крайне неудобно работать. Например: звонит пользователь и говорит что у него в отчете (далее следует какое-то название, что-то вроде с продажами) не появляются какие-то данные. Ваши действия: 1. найти отчет 2. вникнуть в то как он работает 3. понять что дальше делать (менять настройки, доработать его, ничего не трогать или что-то еще).
Как обычно решается. На первом же пункте возникает ступор, понять какой из отчетов "по продажам. " (вроде это слово прозвучало) использует пользователь, иногда очень проблематично, особенно в понедельник утром :) Вы начинаете его искать, попутно еще раз пять уточняя название, потому что оказывается что подобных отчетов несколько, а еще пользователь прочёл название отчета на форме, а в программе он называется немного по-другому. В итоге вы наконец находите нужный отчет и переходите к пункту 2.
Тут начинается самое интересное, хорошо если отчет типовой или написан вами, вы хоть будете знать что он делает, а если нет? Нужно как то быстро вникнуть в его суть, можно конечно спросить у пользователя, но пользователь вдруг оказался финансовым директором и ему некогда рассказывать вам об этом отчете, и скорее всего придется лезть в конфигуратор. Открыв отчет в конфигураторе вы вдруг понимаете что. ничего не понимаете. а комментариев в коде как правило немного. А иногда чтобы ответить на вопрос пользователя - нужно очень хорошо понять принцип работы отчета, а это значит досконально вникнуть в его содержимое. И тут многим (особенно начинающим программистам) приходит в голову достаточно простое решение - взять и переписать этот отчет. Но это не всегда возможно, а иногда просто невозможно (поэтому то и ценится умение читать чужой код). В общем решение вопроса начинает затягиваться на неопределенный срок. А тут еще пользователь вас торопит. Наконец-то разобрались, но это еще не всё, нужно еще третий пункт отработать. А через месяц. вам опять звонит этот пользователь и снова задает этот же вопрос, и вы снова проходите по этому кругу. Да-да, так к сожалению очень часто бывает.
Наше решение.
1. Чтобы быстро и дентифицировать отчет (или обработку) мы присваиваем ему трехзначный цифровой код, где первая цифра закреплена за программистом, а две последующие - номер по порядку. А также присвается буквенное наименование показывающее назначение отчета. И когда пользователь говорит вам: "Посмотрите пожалуйста 516 отчет". Вы моментально находите его по цифре "516" и при этом знаете что под цифрой "5" у вас разработку ведет программист Иванов, к которому можно при случае обратиться за разъяснением.
2. Для понимания того как работает отчет, существует справочная информация, она записывается в сам отчет, а также в txt-файл. Файл этот нужен для просмотра справки без открытия отчета в 1С. В справке подробно описывается: принцип работы отчета (1), откуда берет данные (2), как их выводит (3), какие настройки нужно сделать (4), обязательные для заполнения поля (5), различные нюансы (6). В 90% случаев справочная информация позволяет дать ответ пользователю не прибегая к открытию отчета в конфигураторе.
Как реализовать:
1. Название (1), синоним (2), имя на форме (3), название каталога (4) и название txt-файл а (5) всегда должны быть одинаковы. Например: DD_UT_741_Установка_доп_прав_у_пользователей. Где: DD – название компании, UT – название конфигурации, 741 – цифровой код отчета/обработки, «Установка_доп_прав_у_пользователей» - что делает данная обработка. Для удобства копирования слова разделены не пробелами, а нижними дефисами (всё название выделяется одним кликом мыши).
2. Цифровой код состоит из двух частей: 7 – цифра закрепленная за определенным программистом, 41 – номер обработки/отчета по порядку. 1С-вские обработки (измененные типовые) начинаются с «0», обработки неизвестных программистов – начинаются с «8».
3. В каждой обработке/отчете должна быть справочная информация, которая должна быть описана в txt-файле. Также создан специальный каталог для разработчиков где хранятся каталоги с отчетами/обработками. См. скриншот:
Каталог с внешними отчетами и обработками
4. Добавление/изменение объектов
1. При разработке стараемся по максимуму использовать типовой функционал, но при этом стараясь не менять его существенно, чтобы избежать ошибок и проблем с обновлением.
2. Все новые объекты (и реквизиты) добавляются с префиксом. Префикс всегда один и тот же и не привязан к программисту, нас это сокращенное название фирмы - "ДД_" . Например: «ДД_Заявка_покупателя». Благодаря префиксу мы сразу понимаем какой функционал задействован, наш или типовой. Измененные и добавленные объекты добавляются в отдельную подсистему.
3. После изменения типовых объектов (или добавления новых) , таких как справочники, документы – в них добавляется справочная информация с описанием произведенных изменений. Желательно вставлять их выше типовой справки, чтобы в первую очередь читались наши изменения.
5. Контроль за исполнением
Контроль осуществляется периодически, раз в два - три месяца. Для этого выборочно открываются объекты (документы, справочники, обработки), смотрится:
- названия отчетов/обработок в каталоге
- запускается глобальный поиск инициалов/ФИО программистов
Но лучший контроль - это конечно совесть исполнителя поэтому желательно работать с людьми ответственными, за которыми не надо следить!
Ну и напоследок, вернемся к началу:
Нужно ли это руководителю IT. Что будет если уйдут программисты (или пользователи) "носители знаний"? Если возникнет разбирательство кто, зачем, когда внедрил функционал? Если нужно быстро провести ревизию конфигурации? Как быстро передать информацию другим специалистам?
Нужно ли это ведущему программисту. Что будет когда пользователи начнут задавать вопросы по тому функционалу который писал не он, а молодые специалисты или франчайзи? Сможет он быстро ответить на эти вопросы? А если это его доработки, то сможет ли он вспомнить то что делал полгода назад?
Нужно ли это программисту. Есть мнение что чем больше информации скрыто, тем больше ценность человека как специалиста. На деле же получается наоборот, чем больше человек скрывает информации, тем меньше с ним хотят работать, ведь быть зависимым никому не хочется, а при случае - постараются избавиться от этой зависимости. Да и профессионализм этого специалиста явно под вопросом.
Нужно ли это пользователю. Как свести к минимуму количество обращений к программистам если у пользователя элементарно нет справочной информации? Как ему максимально быстро получить ответ на свой вопрос если программисту надо много времени на то чтобы найти его?
Мы для себя давно ответили на эти вопросы. Теперь ваша очередь по новой взглянуть на них :)
Первая фишка. Учимся работать с группировкой кода в программном модуле 1С
Платформа 1С позволяет в модуле группировать процедуры, циклы, условия и пр. Понять, что кусок кода сгруппирован можно по характерному знаку минус («-»), который расположен в начале куска сгруппированного кода
В этом случае код сгруппирован и развернут, но он может быть свернут как автоматически платформой при открытии модуля, так и разработчиком во время работы. В этом случае вместо знака минус, будет знак плюс рядом с первой строкой свернутого кода.
Разработчик сможет посмотреть на свернутый код, если наведет курсор на символ «…», который расположен справа от свернутого кода.
Платформа 1С позволяет программисту настраивать, какой код должен группироваться и сворачиваться автоматически, а какой нет. Делается это в параметрах конфигурации 1С (Главное меню – Сервис – Параметры) .
В параметрах конфигурации нам интересна закладка «Модули» и подзакладка «Группировка»
В этой закладке, ставя и убирая флажки, можно установить, какие куски кода будут группироваться, а какие нет. Если необходимо, что бы кусок кода группировался, но при открытии программного модуля 1С всегда был развернут, то нужно установить флаг «Группировать», а флаг «Сворачивать» оставить пустым. Если же установить оба флага, то при открытии модуля, кусок кода данного вида будет всегда свернут.
Вторая фишка. Используем области кода в программном модуле 1С
Очень часто возникает необходимость объединить ряд процедур и функций (или просто кусок какого-то кода) в один общий логический кусок или блок. Это можно сделать при помощи комментариев, как у меня на рисунке ниже
Области можно вкладывать друг в друга
А так же при помощи областей можно объединять код внутри процедур и функций
Но, области не могут пересекаться, и так же не могут заканчиваться внутри процедур и функций.
Настройку того, как должны вести себя области при открытии программного модуля, можно сделать в уже знакомых нам параметрах конфигурации 1С.
Третья фишка. Быстрый переход к нужной процедуре в программном модуле 1С
При программировании в 1С или отладке кода, часто возникает ситуация, что нужно перейти в код какой-то процедуры или функции. Причем искомая процедура может быть расположена в текущем программном модуле 1С, а может и в каком-то общем программном модуле.
Для того, чтобы перейти на нужную процедуру, необходимо поставить курсор на эту процедуру и нажать клавишу F12.
В том случае, когда нужная процедура или функция в этом же модуле, курсор перескочит на ее название
Если же процедура находится в каком-то другом модуле (общем, модуле объекта и т.п.), то будет предложено перейти или в этот модуль, или в нужную процедуру.
Четвертая фишка. Узнаем, где используется нужный метод в программном модуле 1С
При разработке периодически может возникнуть необходимость знать, в каком месте кода используется та или иная процедура (функция). Можно конечно скопировать название этой процедуры и сделать глобальный поиск по всей конфигурации, а можно поступить проще. Достаточно просто установить курсор на названии нужного метода и нажать комбинацию клавиш Alt + F12, после этого откроется окно, в котором будут перечислены строки кода, где встречается искомая процедура. Разработчик может из этого окна перейти в интересующее его место.
С помощью данной комбинации клавиш можно искать использование метода не только в рамках текущего модуля, но и везде по конфигурации.
На этом пока я закончу рассказывать о интересных фишках при работе с кодом в модулях 1С, обязательно следите за событиями, Вас ждет много интересной и полезной информации из мира 1С.
Иногда кажется, что изучить язык программирование в 1С сложно и трудно. В действительности программировать в 1С — легко. Помогут Вам легко и быстро освоить программирование в 1С мои книги: «Программировать в 1С за 9 шагов» и «Основы разработки в 1С: Такси»
Изучите программирование в 1С с помощью моей книги «Программировать в 1С за 9 шагов»
- Без сложных технических терминов.
- Более 500 страниц практического материала.
- Каждое задание сопровождается рисунком (скриншот).
- Сборник задач для домашней проработки.
- Книга написана понятным и простым языком — для новичка.
- Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Промо-код на скидку в 16%: vCph8bW3rE
Эта книга подойдёт тем, кто уже начал программировать и испытывает определенные сложности с этой темой и тем, кто уже давно программирует, но ни разу еще не работал с управляемыми формами 1С
- Без сложных технических терминов;
- Более 600 страниц практического материала;
- Каждый пример сопровождается рисунком (скриншот);
- Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Промо-код на скидку в 15% — 48PVXHeYu
Если Вам помог этот урок решить какую-нибудь проблему, понравился или оказался полезен, то Вы можете поддержать мой проект, перечислив любую сумму:
можно оплатить вручную:
Яндекс.Деньги — 410012882996301
Web Money — R955262494655
Вступайте в мои группы в соцсетях, и будьте в курсе всех новостей
One thought on “ Четыре фишки, как улучшить свою работу с кодом в 1С ”
Очень полезная фишка — после Ф12 вернуться обратно помогает Ctrl+»-» (минус) 🙂
В этой статье я приведу пять рабочих советов для начинающих программистов 1С, которые помогут быстрее въехать в профессию.
Совет № 1. Учимся работать со справочной информацией.
Именно в справочной информации Вы сможете быстро и эффективно узнать о методах, свойствах и событиях всех объектов 1С. В платформе 1С есть два вида справок. Собственно сама справка, путь: Справка – Содержание справки.
А так же синтаксис-помощник конфигуратора 1С
Синтаксис-помощник позволяет получить быстрый доступ к описанию того или иного объекта при помощи закладок «Индекс» и «Поиск». Например, введем в закладке «Индекс» слово «массив», индекс сразу выведет все возможные варианты, где может во встроенном языке использоваться слово «массив»
Если мы кликнем на какое-то одно слово (например, Массив), то в случае множество одноименных объектов, свойств и методов будет предложен список для выбора.
Выбрав то, что Вам нужно Вы получите всю информацию об интересующем объекте. В данном случае мы получили информацию об объекте универсальной коллекции значений — массиве.
Заметьте, в справочной информации, очень часто есть примеры кода, где используется описываемый объект.
Подробнее о работе со справкой: видео-урок
Работа со справкой в конфигураторе 1С
Совет № 2. Привыкаем использовать отладку
Многие начинающие программисты 1С пренебрегают этим механизмом платформы 1С. А зря! Именно работая с отладкой можно понять, как работает то или иной код, и какие значения возвращает та или иная функция.
Для того, что бы отладка сработала достаточно поставить в конфигураторе 1С точку останова и запустить отладчик при помощи кнопки «Начать отладку» (клавиша F5).
Для того что бы программа остановилась в точке останова, нужно в пользовательском режиме в 1С: Предприятия выполнить действия, в результате которых сработает код, где установлена точка останова. На рисунке выше мы поставили точку останова в процедуре ОбработкаПроведения модуля документа «Установка цен». Если мы в пользовательском режиме проведем любой документ «Установка цен», то точка останова сработает.
После этого вы можете или с помощью Табло, или с помощью «Вычислить выражение…» узнать значения той или иной переменной.
Подробнее о работе с отладкой смотрите в моем видео-уроке: Работа с отладкой в конфигураторе 1С
Совет №3. Привыкаем использовать контекстные подсказки
С самого начала привыкайте работать с контекстными подсказками и шаблонами. Тем самым Вы существенно ускорите свое программирование и не будете тратить время на обдумывание правильности написания той или иной функции (процедуры, метода и тп).
Включить контекстные подсказки в конфигураторе 1С можно в параметрах (путь: Сервис – Параметры), на подзакладке «Контекстная подсказка» закладки «Модули»
При помощи контекстной подсказки Вы можете, узнать какие параметры есть у той или иной процедуры или функции.
А так же узнать какие методы и свойства могут быть у того или иного объекта
Контекстная подсказка будет вызвана после того, как вы введете с клавиатуры точку, скобку, равно (в зависимости от настроек параметров), а так же после того как вы нажмете комбинацию клавиш Ctrl + Space (Пробел)
Так же не пренебрегайте шаблонами кода. Подробно от том, как с ними работать, можно почитать в статье: Ускоряем свое программирование при помощи шаблонов
Совет №4. Используем конструкторы
Понятно, что многие гуру от программирования начнутся плеваться ядовитой слюной от этого совета, но для многих начинающих программистов 1С использование стандартных конструкторов поможет на начальном этапе быстро освоить те или иные алгоритмы работы (например, проведение документа, заполнение на основании и т.д).
В платформе 1С есть несколько видов конструкторов.
У документов можно вызвать конструктор движений, ввода на основании и печати.
Для работы с запросами можно использовать конструктор запросов и конструктор запросов с обработкой результатов.
А быстро научиться использовать форматную строку для различных примитивных типов можно при помощи конструктора форматной строки. Более подробно о этом полезном конструкторе можно почитать в статье: Конструктор форматной строки
Совет №5. Учимся искать, как это сделано в чужом коде
И последний не менее важный совет для начинающих программистов 1С – учитесь читать чужой код. Да это сложно, непонятно и трудно, но если Вы с самого начала будете пытаться осмысливать чужой код, то в дальнейшем этот навык Вам очень пригодиться. Так же чтение чужого кода Вам может подсказать, как правильно использовать тот или иной объект, или как работать с какой-либо функцией (процедурой).
Например, Вы хотите посмотреть, как в какой-нибудь имеющейся конфигурации используется метод СоздатьНаборЗаписей регистра сведений. Для этого необходимо осуществить глобальный поиск по конфигурации
В форме глобального поиска Вы вводите искомое название
Если искомое слово есть в конфигурации (в частности в модулях), то путь к этому слову будет выдан в результатах поиска
Из результат поиска Вы сможете перейти в нужный модуль и посмотреть как применяется искомый Вами метод (процедура, функция) или объект.
Тем самым сможете быстро научится использовать некоторые типовые методы работы с теми или иными объектами.
Иногда кажется, что изучить язык программирование в 1С сложно и трудно. В действительности программировать в 1С — легко. Помогут Вам легко и быстро освоить программирование в 1С мои книги: «Программировать в 1С за 11 шагов» и «Основы разработки в 1С: Такси»
Изучите программирование в 1С с помощью моей книги «Программировать в 1С за 11 шагов»
- Без сложных технических терминов.
- Более 700 страниц практического материала.
- Каждое задание сопровождается рисунком (скриншот).
- Сборник задач для домашней проработки.
- Книга написана понятным и простым языком — для новичка.
- Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Эта книга подойдёт тем, кто уже начал программировать и испытывает определенные сложности с этой темой и тем, кто уже давно программирует, но ни разу еще не работал с управляемыми формами 1С
- Без сложных технических терминов;
- Более 600 страниц практического материала;
- Каждый пример сопровождается рисунком (скриншот);
- Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Промо-код на скидку в 15% — 48PVXHeYu
Если Вам помог этот урок решить какую-нибудь проблему, понравился или оказался полезен, то Вы можете поддержать мой проект, перечислив любую сумму:
Набор практик хорошего кода, не зависящих от языка программирования. Примените их, и ваш код будет не только работать, но и читаться.
Программисты в первую очередь работают с языком. Поэтому написание программ похоже на любой другой вид письменной работы. Сначала вы излагаете свои мысли как есть, а затем «причесываете» до тех пор, пока текст не будет легко читаться. Качество кода – результат проявления небезразличного отношения к делу и показатель профессионализма.
Чтение кода происходит чаще, чем написание. Есть большая разница между обучением программированию и реальной работой в компании. Вначале мы и пишем, и читаем собственные программы. Но чем дальше мы продвигаемся, тем чаще нам приходится не писать, а читать код. Чем легче код читается, тем проще с ним работать другим людям.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете
Чем проще читать код, тем проще его сопровождать. Понятный, читаемый код легче тестировать, в нем легче отлавливать ошибки – они не скрываются в его запутанной структуре. Плохо оформленный код неприятно изучать, читать, тестировать, сложно дополнять. Рано или поздно плохой код становится проще переписать.
Эстетическое восприятие кода влияет на удобство работы. Казалось бы, гораздо важнее производительность, возможность модификации, расширения… Но все эти показатели улучшаются, если код соответствует нашему чувству прекрасного. Глядя на качественно написанный код, можно быстро понять алгоритм и то, как работает программа для разных входных данных. Чистый код читается, как хорошо написанная проза: слова превращаются в зрительные образы.
Стиль кода определяет его будущее. Стиль и дисциплина продолжают жить в коде, даже если в нем не осталось ни одной исходной строки.
Все дороги программиста ведут к документации. В каждом языке существует свой стандарт оформления кода. Для Python используется документ PEP-8, для PHP – стандартные рекомендации PSR-1 и PSR-2, для Java – Java Coding Conventions, для JavaScript – Airbnb JavaScript Style Guide или Google JavaScript Style Guide. Документ для вашего языка вы найдете по поисковому запросу Code Style.
Когда вы работаете в группе разработчиков, нужно использовать принятые в команде правила. Стиль должен быть единым, как будто код был написан одним здравомысленным человеком.
В популярных IDE заложена возможность автоматической настройки стиля кода под стандарты – общие или предложенные командой. Разберитесь, как настроить среду под необходимое оформление. Потраченное время сэкономит многие часы рутинной работы.
Применение стандартов – лучший подход для новичка. Читающий не будет отвлекаться на оформление и сразу погрузится в тонкости выбранных подходов, а не расстановок переносов. Изложенные ниже правила понадобятся для того, чтобы понять, как действовать в тех случаях, когда стандарт не дает никаких рекомендаций.
Как Библиотека программиста, мы не могли обойтись без упоминания замечательной книги Роберта Мартина о чистом коде и анализе программ. В книге приводятся примеры для языка Java, но большинство идей справедливы для любых языков.
Если вы видели эту книгу ранее с другим оформлением, не удивляйтесь – это новая версия обложки книги «Чистый код»
Всё что изложено ниже, в значительной мере представляет сжатый конспект этой книги с дополнениями из нашего опыта в проектировании программ. Итак, приступим к практикам.
Содержательность. К выбору названий любых объектов нужно подходить со всей ответственностью. Выразительные имена позволяют писать код, не требующий комментариев.
Полезно не только исходно выбирать ясные имена, но и заменять названия на более удачные, если они нашлись позже. Современные среды программирования позволяют легко заменить название переменной во всём коде, так что это не должно быть проблемой.
В первом примере непонятно, что вообще происходит, хотя в этом коде нет ни сложных выражений, ни каких-либо странностей. В результате правок сам код никак не изменился. Если знать, что это часть игры «Сапер», то теперь из кода понятно: здесь обрабатывается список ячеек игрового поля. Этот код можно улучшать и далее, но уже в результате простого переименования переменных стало понятно, что происходит.
Избегайте любых двусмысленностей и ложных ассоциаций. Если в объекте перечисляется список, но сам объект не является списком, нельзя в составе его названия употреблять слово list – это запутывает читающего.
Остерегайтесь малозаметных различий – имена объектов должны существенно отличаться друг от друга. По этой причине плохи длинные имена с повторяющимся элементами – чтобы сличить их друг с другом, тратятся лишние силы и время. Избегайте использования в именах переменных строчной буквы L и прописных I, O – они часто путаются с единицей и нулем.
Путаница также возникает, если несколько синонимичных слов и выражений используются для обозначениях разных сущностей, например, controller , manager и driver .
Имя должно легко произноситься. Используйте для названий слова. Если названия состоят из сокращений, каждый начинает произносить их по-своему, что затрудняет взаимопонимание. А при чтении кода каждый раз «спотыкаешься» о такое название.
Имя должно быть удобным для поиска. Слишком короткие имена трудно искать в большом объеме текста. Однобуквенные имена можно использовать только для локальных переменных в коротких методах и для счетчиков циклов ( i, j, k ). Обычно называя объект одной буквой, вы всего лишь создаете временный заменитель. Но не бывает ничего более постоянного, чем что-то «временное». Проверяйте грамотность написания выбранных слов.
Правильно выбирайте часть речи. Классы и объекты желательно называть существительными и их комбинациями: Account , WikiPage , HTMLParser . Имена функций и методов лучше представлять глаголами или глагольными словосочетаниями: delete_page , writeField(name) . Для методов чтения/записи и предикатов используйте стандартные префиксы get , set , is .
Заменяйте «магические» числа именованными константами. Одно из самых древних правил разработки. Магическими называют числа, о которых сходу нельзя сказать, что они означают. Например: 100 , 1.1 , 42 , 1000000 . Выделяйте такие числа в соответствующие константы с конкретным названиями. Например, вместо числа 86400 в теле кода приятнее встретить константу SECONDS_PER_DAY .
Не стоит следовать этому правилу, как и любому другому, безоговорочно. В формулах некоторые константы лучше воспринимаются в числовой записи.
Одно слово для каждой концепции. Для одной и той же идеи, реализующей одну механику, используйте одно слово. Например, для добавления элементов одинаковым образом – метод add . Однако, если механика и семантика изменились, потребуется и другое слово (например, insert , append ), описывающее новую концепцию.
Ваш код будут читать программисты. Не стесняйтесь использовать термины из области информатики, общепринятые названия алгоритмов и паттернов. Такие имена сообщают информацию быстрее, чем сам код.
Помещайте имена в соответствующий контекст. Например, имена street , house_number , city понятнее смотрятся внутри класса Address .
Избегайте остроумия и каламбуров в названиях. Шутки имеют свойство быть понятными лишь ограниченное время и для конкретной аудитории, знакомой с первоисточником. Отдавайте предпочтение ясности перед развлекательностью. Шутки можно приберечь для презентации, которая происходит «здесь и сейчас». Хороший код способен выйти далеко за границы вашей культуры.
Среды разработки продолжают развиваться. Уже нет никакой необходимости кодировать типы в именах, создавать префиксы для членов классов. Всю нужную информацию можно получить из цветового выделения или контекстно-зависимых подсказок сред разработки. Добавление префиксов убивает удобство поиска по автодополнению – выпадает слишком много имен, начинающихся с одинаковых символов.
Компактность. Уже в 80-е годы считалось, что функция должна занимать не более одного экрана. Экраны VT100 состояли из 24 строк и 80 столбцов. В наши дни на экране можно разместить гораздо больше инфорфмации, но лучше ограничиться тем же объемом. Самоограничение позволяет видеть точку объявления каждой используемой переменной и держать в уме всю «историю», которую рассказывает функция.
Внешний вид текстового компьютерного терминала VT100
Вполне вероятно, что тот, кто будет сопровождать ваш код, не будет иметь возможности работать на большом мониторе. Например, ему необходимо одновременно разместить на одном рабочем столе экрана ноутбука несколько окон. Среды разработки позволяют установить ограничение, «верхнюю планку» (то есть правую 😉 ).
Блоки if, else, while должны иметь минимальный размер, чтобы информацию о них можно было держать в уме. Старайтесь избегать отрицательных условий – на их восприятие обычно уходит чуть больше времени, чем на положительные. То есть запись if (buffer.shouldCompact()) предпочтительнее записи if (!buffer.shouldNotCompact() .
Правило одной операции. Плохой код пытается сделать слишком много всего, намерения программиста расплываются для читателя. Поэтому стоит ввести важное правило:
Функция должна выполнять только одну операцию, выполнять ее хорошо, и ничего другого она делать не должна.
Каждая функция должна делать то, что вы от нее ожидали из названия. Если функция действует не так, как она названа, читатель кода перестает доверять автору программы, ему приходится самостоятельно разбираться во всех подробностях реализации.
Я люблю, чтобы мой код был элегантным и эффективным. Логика должны быть достаточно прямолинейной, чтобы ошибкам было трудно спрятаться; зависимости — минимальными, чтобы упростить сопровождение; обработка ошибок — полной в соответствии с выработанной стратегией; а производительность — близкой к оптимальной, чтобы не искушать людей загрязнять код беспринципными оптимизациями. Чистый код хорошо решает одну задачу.
Исключения вместо кодов ошибок. Используйте исключения ( try-catch , try-except ) вместо возвращения кодов ошибок. Возвращение кодов приводит к слишком глубокой вложенности.
Соблюдайте уровни абстракции. Одна функция – один уровень абстракции. Смешение уровней абстракции создает путаницу, функция обрастает слишком большим количеством второстепенных подробностей. Старайтесь соблюдать ясную иерархию.
Код читается сверху вниз. По мере чтения уровни абстракции должны меняться равномерно. Каждая функция должна быть окружена функциями единого уровня абстракции.
Ограничивайте число аргументов. Чем больше аргументов у функции, тем сложнее с ней работать. Необходимость функций с количеством аргументов большим двух должна быть подкреплена очень вескими доводами. Каждый новый аргумент критически усложняет процедуру тестирования. Если функция должна получать более двух аргументов, скорее всего, эти аргументы образуют концепцию, заслуживающую собственного имени.
Это непопулярное мнение, но в большинстве случаев комментарии – зло. Код должен быть самодокументированным. Комментарий – всегда признак неудачи: мы не смогли написать код так, что он понятен без комментариев. Проверьте, можно ли выразить свое намерение в самом коде.
В чём проблема? Программисты умеют сопровождать код, но не комментарии. В растущем коде комментарии быстро устаревают, частично или полностью переставая соответствовать ситуации. Только код правдиво сообщает своим содержанием, что он в действительности делает. Лучше потратить время на исправление запутанного кода, чем добавлять к плохому коду комментарии.
Однако есть несколько видов комментариев, которые выглядят достаточно оправданными.
TODO-комментарии. Бывает так: нужно было успеть к дедлайну, пришлось писать код быстро, поэтому в нем остались дыры. То есть всё работает, но реализация ущербная. Укажите все недоработки и создайте под них задачи. Каждый комментарий указывает на недоработку или потенциальную уязвимость.
Юридические комментарии. Корпоративные стандарты могут принуждать вставлять комментарии по юридическим соображениям. Ограничьтесь в таком комментарии описанием лицензии и ссылкой на внешний документ.
Предупреждения о последствиях. Иногда бывает полезно предупредить других программистов о нежелательных последствиях:
Комментарий также может подчеркивать важность обстоятельства, которое на первый взгляд кажется несущественным.
Бывают такие типы комментариев, которые лучше никогда не делать.
Закомментированный программный код. «Когда-нибудь в будущем раскомментирую этот код, приведу всё в порядок. Или вдруг эта идея кому-то поможет». Любой закомментированный код только ухудшает ситуацию. Все изменения хранятся в контроле версий – удаляйте такой код на корню. Это просто мусор: «потом» равносильно «никогда». Если что-то действительно нужно сделать, создайте краткий TODO-комментарий и задачу.
Мертвые функции – идентичные по смыслу предыдущему пункту функции и методы, которые не вызываются в программе. Пользуйтесь системой контроля версий и без зазрений совести удаляйте любой код, который не используется во время выполнения программы.
Избыточные комментарии. Задайте себе вопрос: стал ли код понятнее после прочтения комментария? Часто комментарии просто загромождают код и скрывают его смысл, излагая очевидные вещи. Иногда в комментарии включаются описания не относящихся к делу подробностей. Но профессионал бережет не только свое, но и чужое время, и не отвлекает читающего без повода.
Журнальные комментарии и ссылки на авторов. Некоторые программисты добавляют комментарий в начало файла при редактировании. Или указывают, кто и когда внес исправления. Когда-то это было оправдано, но теперь у нас есть системы контроля версий – это гораздо лучший способ обозначить границы зоны ответственности каждого.
Позиционные маркеры. Иногда любят отмечать определенные группы и позиции в исходных файлах:
Качественно организованный код способен внятно рассказать историю без балластных заголовков.
Минималистичность. Чем меньше кода, тем лучше. Имя файла должно быть простым, но содержательным. Маленькие файлы обычно более понятны, чем большие. Но размер файла, конечно, не должен быть самоцелью.
Код должен быть максимально линейным. Чем больше вложенность кода, тем сложнее его читать. Следите за тем, как двигаются ваши глаза. В хорошем коде вы двигаетесь строка за строкой, лишь изредка возвращаясь к предыдущим строчкам. Вложенность более трех уровней указывает на то, что с кодом нужно поработать: переписать условия проверок и циклов (использовать return и функциональное программирование), разбить код на меньшие методы.
Отдельные «мысли» следует отделять друг от друга пустыми строками. Каждая пустая строка – зрительная подсказка: описание одной концепции закончилось, далее следует новая. При просмотре кода взгляд концентрируется на первых строчках – в них больше всего информации, как в началах абзацев этого текста.
Тесно связанные концепции, должны располагаться вблизи друг друга. Не заставляйте читателя прыгать между файлами или постоянно скроллить файл. По той же причине переменные нужно объявлять как можно ближе к месту использования. Однако переменные экземпляров лучше объявлять в одном месте, обычно в начале класса, так как в хорошо спроектированном классе переменные используются большинством методов класса.
Пробелы для группировки взаимосвязанных элементов. Пробелы улучшают читаемость кода, если они стоят вокруг операторов присваивания, после запятых при перечислении переменных. В формулах пробелы используются для подчеркивания приоритета: не ставятся между множителями, но отбивают знаки сложения и вычитания.
Отступы. Размер отступов должен соответствовать позиции кода в иерархии. Это общая практика, которая позволяет быстро пропускать области видимости, не относящиеся к текущей ситуации. Не поддавайтесь искушению нарушить правила расстановки отступов для коротких команд.
В системе должны выполняться все тесты. Тесты – главный способ, с помощью которого можно понять, что система контролируема. А только контролируемую систему можно проверить.
Три закона тестирования по методологии TDD. Тестовый код не менее важен, чем код продукта. Соблюдение следующих трех правил позволяет организовать работу так, чтобы тесты охватывали все аспекты кода продукта:
- Не пишете код продукта, пока не напишете отказной модульный тест.
- Не пишите модульный тест в объеме большем, чем необходимо для отказа.
- Не пишите код продукта в объеме большем, чем необходимо для прохождения текущего отказного теста.
F.I.R.S.T. Качественные тесты должны обладать пятью характеристиками, первые буквы которых образуют указанный акроним:
- Fast. Тесты должны выполняться быстро.
- Independent. Тесты не должны зависеть друг от друга и выполняться в любом порядке.
- Repeatable. Тесты должны давать воспроизводимые в любой среде результаты.
- Self-validating. Результат выполнения теста – логический признак: тест пройден или нет. Иначе результаты приобретают субъективный характер.
- Timely. Тест должен создаваться своевременно. Тесты нужно писать непосредственно перед написанием кода.
Повышение уровня абстракции и устранение дубликатов. Все программы состоят из очень похожих элементов, а все задачи программирования сводятся к работе с ограниченным набором действий. Многие из этих действий могут быть описаны в одних и тех же терминах, например, извлечение элемента из коллекции. В подобных ситуациях правильно инкапсулировать реализацию в более абстрактном классе. Повышение уровня абстракции позволяет избежать дублирования и многократно применения одного и того же кода, лучше понять, что действительно происходит в программе, уйдя от частностей.
Если что-то в программе делается снова и снова, значит, какая-то важная концепция не нашла своего отражения в коде. Нужно попытаться понять, что это такое, и выразить идею в виде кода. Избегайте дубликатов, это всегда лишняя работа, лишний риск, лишняя сложность.
Несколько языков в одном исходном файле. Современные среды программирования позволяют объединять в одном файле код, написанный на разных языках. Результат получается запутанным, неаккуратным и ненадежным. Чтобы четко разграничить ответственность, в файле должен преобладать один язык. Сведите к минимуму количество и объем кода на дополнительных языках.
Не нужно бездумно следовать догмам. Не переусердствуйте с сокращением кода функций и классов. Всегда руководствуйтесь здравым смыслом.
Чистый код выглядит так, как если его автор над ним тщательно потрудился. Вы не можете найти очевидных возможностей для его улучшения. Попытавшись его улучшить, вы вновь вернетесь к тому же коду.
Чтобы писать чистый код, который бы никого не удивлял, необходимо раз за разом сознательно применять описанные приемы. При чтении чистого кода вы улыбаетесь, как при виде искусно сделанной музыкальной шкатулки. Код можно назвать красивым, если у вас создается впечатление, что язык был создан специально для этой задачи.
Расскажите нам о правилах, которые вы применяете для написания своего программного кода. Какие open source программы, на ваш взгляд, имеют лучшее качество кода?
Больше полезной информации вы найдете на наших телеграм-каналах «Библиотека программиста» и «Книги для программистов».
Книга «1С:Программирование для начинающих. Детям и родителям, менеджерам и руководителям. Разработка в системе «1С:Предприятие 8.3» адресована читателям, которые совсем не знают программирования, но хотят научиться создавать собственные программы в системе «1С:Предприятие 8». Она подойдет и школьникам 12–16 лет, и взрослым, которые хотели бы научиться «программировать в 1С».
В книге рассматривается практический пример создания простого прикладного решения. Он позволяет освоить базовые понятия и базовые приемы программирования, научиться использовать среду разработки (конфигуратор), овладеть встроенным языком и языком запросов, познакомиться с устройством базы данных, приобрести навыки отладки прикладных решений.
Книга содержит большое количество цветных рисунков и примеров кода на встроенном языке, снабженных подробными комментариями. Кроме этого после многих ключевых разделов даются задания для самостоятельной работы. Ответы на эти задания содержатся в конце книги.
Для создания демонстрационных примеров использована учебная версия платформы 8.3.8.1933. Для самостоятельного выполнения примеров требуется доступ к Интернету, чтобы скачать (бесплатно) учебную версию платформы и демонстрационные конфигурации.
Книга выполнена в высоком полиграфическом качестве и удобном формате.
Оглавление
Предисловие
Зачем нужны прикладные решения «1С:Предприятия»
Установка платформы «1С:Предприятие 8»
2. Визуальное конструирование
С чего начинается прикладное решение
Список информационных баз
Конфигурация
Дерево объектов конфигурации
Какие объекты конфигурации можно добавлять
Красота, или какой объект выбрать
Данные
Справочник
Кабинеты
Объект конфигурации описывает, как будут выглядеть его данные
Представления объекта конфигурации в интерфейсе
3. Встроенный язык
Ваша первая программа – заголовок приложения
События
Модули
Встроенный язык
Значение
Тип
Представление
Где писать примеры и чем пользоваться
Простые типы
Почему текст разноцветный
Какие бывают инструкции
Инструкция присваивания
Переменная
Точки останова и просмотр значений
Изменение значений переменных
Контекстная подсказка
Выбор имени для переменной
Выражение
Арифметические операции
Операции со строками
Тип «Дата» и операции с датами
Тип «Булево» и логические операции
Булевы операции
Инструкция «Если»
Красивая программа
Инструкция «Цикл»
Функции
Контекст и область видимости
Процедуры
Чтение и отладка процедур и функций
Обрабатывайте ошибочные ситуации
Используйте инструкцию «Для Каждого … Цикл»
Установка номера для новых документов
4. Автоматическое заполнение расписания
5. Регистры и отчеты
Зачем нужны регистры
Что будет в этой главе
Регистр сведений
Процедура проведения документов
Регистр накопления «ПрошедшиеЗанятия»
Работа с регистрами из встроенного языка
Регистр сведений «ДомашниеЗадания»
Запись в регистр «ДомашниеЗадания»
Работа с регистрами в модуле документа
6. Язык запросов
Чем язык запросов отличается от встроенного языка
Хранение объектных данных
Таблицы запросов
Консоль запросов
Текст запроса
7. Планировщик
Планировщик
Создание формы и размещение в ней планировщика
События формы
Получение данных из базы
Настройка
Перехват событий
Отображение будних дней
Отметки оценок и домашние задания
Обновление данных
8. Доработка интерфейса
Список домашних заданий
Начальная страница
Командный интерфейс основного раздела
Приложение А. Полезные советы
Приложение Б. Список понятий
Приложение В. Список действий
Приложение Г. Решения заданий
Печатное издание:
Свяжитесь с партнером «1С», который обслуживает Вашу организацию, и сделайте заказ, сообщив ему артикул, который присвоен книге (приведен выше, напротив обложки книги). Также вы можете приобрести книгу у других партнеров фирмы «1С».
Читайте также: