webdonsk.ruКак в 1с сделать код красивым
Добавил пользователь Владимир З. Обновлено: 06.09.2024
Компания, в которой я работаю, разрабатывает (в том числе и я) свою собственную отраслевую конфигурацию (автоматизация швейного и ткацкого производства). На сегодняшний день конфигурация находится в стадии бурного развития — внедрили пяти клиентам, еще три на подходе. У клиентов масса пожеланий и мы их, по мере возможностей, реализовываем, и вообще готовим нашу конфигурацию к официальному представлению и размещению на сайте 1С.
И с недавних пор, появилась необходимость защищать нашу конфигурацию от воровства (различных швейных предприятий в Ивановской области немерено), мы провели небольшое исследование о методах защиты кода в 1С и результатами я спешу поделиться.
Штатные средства
Начнем со штатных средств защиты своего кода от копирования. Это можно сделать двумя способами.
Установить пароль на текст модуля.
Исключить текст модуля из поставки конфигурации.
При использовании этих методов код модуля превращается в байт-код, который можно декомпилировать (если захотеть) и некоторые инструменты в помощь начинающим есть в свободном доступе (правда они, насколько я знаю, предоставляют только базовые возможности).
Кроме этого, штатными средствами не удастся спрятать код модуля формы (хотя код модуля объекта спрятать можно).
Обфускация кода 1С
Обфускация — приведение кода в нечитаемый вид. Это можно сделать как при помощи специальных обработок (в недавнем обзоре интересного есть подобный пример), так и при помощи специальных сервисов (Нетленка 1С, например).
Также этот обфускацию можно использовать совместно со штатными средствами — обфускации подвергается байт-код скомпилированных модулей 1С.
Плюсами данного способа является простота (вставил код — получил абракадабру) и возможно зашифровать любой код.
А к минусам относится низка степень защиты — на любой обфускатор можно создать деобфускатор.
Использование внешних компонент
Неплохой метод для случаев, когда ценность представляет сам код (какой-либо уникальный алгоритм, например), а не вся конфигурация. Так как вынесение проверки легальности запуска конфигурации во внешнюю компоненту поможет не более чем установка пароля на модуль.
К плюсам данного метода следует отнести высокую надежность скрытия кода: восстановить 1С код из скомпилированной DLL-ки написанной на C++, например, — это та еще задача.
К минусам же, относиться необходимость переписать код 1С на другом языке (что тоже, зачастую, задача нетривиальная) и большие трудности с отладкой.
Решения сторонних разработчиков
Есть компании которые профессионально занимаются вопросом защиты интелектуальной собственности разработчиков на 1С. Примером можно привести компанию WiseAdvice.
Суть их метода сводится к вынесению части кода в отдельную обработку, которая храниться в каком-либо зашифрованном хранилище. Доступ к это части кода осуществляется при помощи специальной внешней компоненты, которая и определяет доступ к зашифрованной обработке.
К плюсам такого подхода относится высока надежность защиты кода (во многих подобных решениях код в расшифрованном виде появляется только в оперативной памяти и только в момент исполнения этого самого кода) и отсутствие необходимости переводить код 1С в код какого-либо другого языка программирования.
А к минусам стоит отнести саму необходимость выносить код во внешние обработки и некоторые другие сложности связанные с использованием подобных систем.
Делая вывод, можно сказать, что нет абсолютно надежного способа защитить свою конфигурацию от нежелательного запуска (поправьте, если не так). В то же время для защиты частей кода от копирования есть немало надежных решений.
Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
(оценок: 4, средняя оценка: 4,75 из 5)
Автор курса по С++ в Яндекс.Практикуме Маша Гутовская рассказала, что такое красивый код, и объяснила, почему начинающим разработчикам важно сразу учиться писать код красиво. В конце текста вас ждет чеклист с советами и полезными материалами.
Зачем писать красивый код
Если красивый код станет привычкой, принципом работы, с которым вы входите в профессию, то вам будет гораздо проще в дальнейшем. Попав в компанию, которая работает по общепринятым стандартам, вам не придётся переучиваться и менять собственные подходы к разработке.
Это также может сослужить добрую службу на собеседовании. С большей вероятностью рекрутеры отдадут предпочтение тому разработчику, который умеет писать красивый код.
Три уровня красоты кода
Я занимаюсь проектами для интернета вещей, умного дома и медицинского оборудования. Обсуждать красоту кода я буду на примере С++, так как работаю на нём. Но думаю, что мой подход актуален для любого языка. Я бы выделила три уровня красоты кода.
Уровень восприятия
Код должен быть красиво организован. Важны названия переменных, размеры классов, функций и методов, а также частота использования условных выражений. Обилие if, else и switch case создаёт нагромождение условий и частных случаев. И это не только визуальная проблема: такой код сложнее понимать, дорабатывать и поддерживать.
Представьте, что новому разработчику в команде нужно найти баг в программе. Для этого он должен суметь быстро и без посторонней помощи понять, как устроен ваш код: все элементы должны стоять на привычных местах и не должно быть неявных зависимостей.
Code smells и рефакторинг
Допустим, вы написали код. Прошло полгода, вы успели поучаствовать в разных проектах и написать не одну сотню строк. Стоит ли возвращаться к нему и делать рефакторинг? Обязательно. Во-первых, это повысит качество самого кода, а вы научитесь замечать детали, которые надо исправлять и которых стоит избегать в будущем. Во-вторых, вероятно, вам будет нужно время от времени рефакторить и чужой код — сможете набить руку на своём же старом. В блоке полезных ссылок в конце статьи вы найдете ссылку на отличный ресурс о том, как делать правильный рефакторинг.
Разберём код, в котором можно найти много проблем:
Этот код вполне соответствует правилам оформления. Но что мешает понять его легко и быстро?
Запутанные наименования, которые только усложняют понимание
Визуальный мусор
- Мёртвый код (закомментированный вызов ProcceedElementsCheck). Довольно сложно, на мой взгляд, понять, какой логики придерживался автор на этом участке. Причина — закомментированный код.
Проблемы с документированием
- Комментарий над функцией явно устарел и сбивает с толку.
Как написать красивый код
1. Следуйте правилам оформления кода (или coding conventions). Даже если вы фрилансите или учитесь, приобретите привычку всегда писать красиво.
2. Используйте специальные инструменты. Для корректировки кода под конкретный стайлгайд существует множество различных плагинов, скриптов и шаблонов для разных сред программирования. IDE (Integrated Development Environment) успешно автоматизирует этот процесс, а вы сможете и время сэкономить, и новый навык освоить.
Вот несколько полезных инструментов для автоматизации.
Plug-in Beautifier для вашей IDE — плагин, который сделает код единообразным, отформатирует, уберёт всё лишнее.
Clang-format — инструмент для автоматического форматирования кода без запуска IDE.
Google C++ Style Guide — руководство по стилю Google, которое можно взять за основу и использовать для создания собственного стайлгайда.
3. Сделайте код понятным. Код должен быть написан так, чтобы без ваших комментариев всё было ясно. Используйте простые названия переменных, классов и методов.
4. Освойте принципы SOLID. Нужно, чтобы ваш код не рассыпался при попытках коллег внести в него изменения.
5. Не забывайте про ревью. Код-ревью — это процесс, во время которого ваш код просматривают и комментируют члены команды. Хороший ревьюер укажет не только на баги в коде, но и на архитектурные недочёты и плохой стиль написания. Кроме этого, он объяснит, как можно было бы сделать работу быстрее и проще. Чтобы писать красивый и правильный код, внимательно относитесь к комментариям ревьюера, и тогда с каждой итерацией недочётов будет всё меньше.
6. Оставляйте время для рефакторинга. После рефакторинга ещё раз протестируйте код. Будет лучше, если ошибки заметите вы, а не ребята из вашей команды или пользователи.
7. Изучайте код новых проектов в open source. Это поможет вам быть в курсе новых практик и подходов. Следите за проектами, которые вам нравятся, смотрите, как и на чём они написаны, задавайте вопросы разработчикам.
Как можно проверить тип значения переменной на равенство нужному?
Как очистить реквизит формы, имеющий ссылочный тип?
Как очистить значение, имеющее тип "Хранилище значения"?
Как проверить тип значения, помещенного в реквизит имеющий тип "Хранилище значения"?
Как сжать данные, помещаемые в хранилище значения?
Как предоставить пользователю возможность выбора значения составного типа?
Как применить округление при работе с вычисляемыми числовыми полями в запросе?
Как вывести многострочное предупреждение?
Как при выполнении обработки сообщить пользователю текущее время?
Как вывести число прописью по-русски, но без дробной части?
Как вывести число прописью по-русски, с указанием сотых в дробной части?
Как вывести прописью число килограммов с указанием дробной части в граммах?
Как долларовую сумму вывести прописью по-английски?
Как загрузить внешнюю компоненту?
Как выполнить команду операционной системы?
Как реализовать код процедуры в зависимости от режима выполнения (на клиенте, на сервере, во внешнем соединении) ?
Как при групповой обработке объектов реализовать стратегию "либо все, либо ничего"?
Об этом прекрасно сказал Роберт Мартин:
Я немного поясню.
Когда бы я ни просматривал код, мой мозг синтезирует эмоции трех разных видов.
- Какого хрена (раздраженно) – Этот код не нужен.
- Какого хрена (восхищенно) – Этот чувак умен.
- Какого хрена (озлобленно) – Не могу понять эту тарабарщину.
Итак, что прежде всего производит на нас впечатление, когда мы видим какой-нибудь код?
Это чистота и красота его написания.
А написание чистого и красивого кода – признак ОТЛИЧНОГО спеца по программному обеспечению.
В изучении этого искусства есть две важные составляющие: Знание и Работа. Знание дает вам шаблоны, принципы, практики и эвристику, необходимые для совершенствования в профессии. Но это знание должно проникнуть в ваши пальцы, глаза и внутренности путем постоянной практики и тяжелой работы.
Короче говоря, учиться писать чистый код это тяжелая работа. Вам придется над этим попотеть. Вы должны практиковаться, ошибаться, терпеть неудачи, преодолевать трудности и повторять эти шаги снова и снова, пока не получится правильно. Более простого пути нет.
А вот несколько способов, с помощью которых можно достичь вершин мастерства в написании чистого и красивого кода.
Хорошо выразился об этом Кендрик Ламар:
Имена в программном обеспечении вы найдете повсюду. Мы даем имена функциям, классам, аргументам, пакетам и чему угодно. Мы именуем исходные файлы, папки и все внутри них. Мы постоянно даем, даем и даем имена, и таким образом именно это больше всего засоряет наш двигатель чистого кода.
Ваше имя должно раскрывать цель. Выбор хороших имен занимает время, но сохраняет его гораздо больше, когда дело принимает крутой оборот. Поэтому уделяйте внимание вашим именам и меняйте их, когда находите лучший вариант. Каждый, кому доведется читать ваш код, будет вам за это весьма признателен.
Всегда помните, что имя переменной, функции или класса должно отвечать на три главных вопроса: почему оно существует, что оно делает и для чего используется.
Это требует не только хороших навыков описания, но и общего культурного бэкграунда, выходящего за эти пределы, а научить вас этому лучше всего сможете только вы сами.
На эту тему отлично высказался Луис Салливан:
Каждая система строится на основе конкретного языка, созданного программистами c возможностью подходящих описаний. Функции этоглаголы этого языка, а классы — существительные. Функции обычно являются первой линией организации в любом языке программирования и хорошее их написание – суть написания хорошего кода.
Есть всего два золотых правила написания чистых функций:
- Они должны быть маленькими
- Они должны выполнять одно действие, но выполнять его хорошо.
Это означает, что ваша функция не должна быть слишком большой для удержания вложенных структур. Поэтому уровень отступов функции не должен превышать один или два. Эта техника позволяет облегчить чтение, понимание и систематизацию. Кроме того нам нужно убедиться, что утверждения внутри нашей функции находятся на одном уровне абстракции.
Смешение уровней абстракции внутри функции всегда сбивает с толку и приводит к тому, что с течением времени код становится неуправляемым. Для программистов-мастеров функции это скорее истории, которые они рассказывают, а не код, который они пишут.
Они используют возможности выбранного языка программирования для создания более богатых, выразительных и чистых блоков кода, которые могут выступать в качестве прекрасных рассказчиков.
Винус Уильямс попала в точку, сказав:
Комментарии это палка о двух концах. Ничто не может быть более полезным, чем уместный комментарий. С другой стороны, ничто не может внести большую сумятицу, чем произвольные бесполезные комментарии, пожирающие пространство. И ничто не может быть более разрушительным, чем комментарии, содержащие дезинформацию и ложь.
Короче говоря, комментарии в лучшем случае являются необходимым злом. Почему? Не всегда, но в большинстве случаев. Чем старше комментарий, тем сложнее его поддерживать, а большинство программистов известны тем, что не поддерживают комментарии на одном уровне со своим кодом.
Код движется и развивается. Куски кода перемещаются туда-сюда, а комментарии – нет, и это становится проблемой!
Помните, что понятный и выразительный код с малым количеством комментариев гораздо предпочтительнее беспорядочного и сложного кода со множеством комментариев. Не тратьте время на объяснение созданного вами беспорядка, лучше посвятите время расчистке этого бардака.
Роберт С. Мартин сказал чистую правду:
Это утверждение нельзя недооценивать, это одна из главных характеристик действительно ОТЛИЧНОГО разработчика.
Форматированный код это окно в ваше мышление. Мы хотим, чтобы люди впечатлились нашей упорядоченностью, вниманием к деталям и ясностью мысли. Но если, глядя на код, они видят зашифрованный ералаш без понятного начала и конца, это, без сомнения, пускает нашу репутацию под откос!
Стиль написания кода и его читабельность продолжат влиять на поддержку кода до тех пор, пока оригинальный код не будет изменен до неузнавания.
Зарубите себе на носу, что в будущем вас скорее всего будут помнить благодаря вашему стилю и дисциплине, а не собственно коду. Поэтому вы должны позаботиться о том, чтобы ваш код был красиво отформатирован и подчинялся простым правилам, понятным всем членам команды.
Пишите ваши try-catch-finally сразу
Жорж Кангильем верно заметил:
Обработка ошибок это нечто, чем занимаются все программисты. Инпуты могут быть неверными, а устройства могут отказывать. От нас как разработчиков ждут, что мы обеспечим работу кода в ожидаемом виде. Однако, сложность не в исправлении ошибок, а в том, как это сделать чистым, читабельным способом.
Многие коды завершаются преобладанием обработки ошибок. И все становится настолько разбросанным, что полностью уничтожает цель и логику основного кода. Когда такое происходит, это неправильно, совершенно неправильно. Код должен быть чистым и ясным, а ошибки должны обрабатываться изящно и стильно. Это признак мастерства разработчика.
А один из способов делать это – правильные вложения и захват всех ошибок в try-catch блоках. Эти блоки являются способом определения границ вашего кода. Когда вы исполняете код из части try вашего try-catch-finally предложения, вы заявляете, что выполнение может быть прервано в любой момент времени, а затем возобновлено в catch.
Поэтому начинать с предложения try-catch-finally является хорошей практикой при написании кода. Это помогает вам определить, чего может ожидать пользователь кода, независимо от того, что пошло не так при исполнении кода из try.
Обобщаем все вышесказанное
Итак, что является главным во всем, описанном здесь?
Это чувство кода – программистский эквивалент здравого смысла.
Некоторые из нас с этим рождаются, а некоторые должны мучительно приобретать это чувство путем практики и настойчивости. Это чувство кода не только помогает нам отличать хороший код от плохого, но также помогает в формировании стратегий преобразования плохого кода в хороший.
Грубо выражаясь, это показывает нам, что бессмысленно печь прекрасный пирог, если для глазури вы собираетесь использовать собачье дерьмо.
Это чувство кода помогает программисту выбирать лучший вариант и лучший инструмент из возможных для создания чистого и красивого кода.
Короче, программист с чувством кода это художник, который может преобразить чистый лист в элегантное произведение искусства, остающееся в памяти на долгие годы.
Как верно подытожил Гарольд Абельсон,
При написании статьи использованы книги: “A handbook of Agile Software Craftsmanship” Роберта Мартина и “A handbook of Agile estimation” Майка Кона.
Читайте также: