Важность и метод именования в программной инженерии
technology software-development

Важность и метод именования в программной инженерии

23 ноября 2022 г.

* Шекспир написал "Что в имени? То, что мы называем розой. Любое другое имя пахло бы так же сладко." Это, очевидно, верно, но в программной инженерии (и, возможно, в других областях также ), в Имени на самом деле много, и это делает важным процесс Именования вещей. Это то, что мы рассмотрим в этом посте.

* В случае разработки программного обеспечения имя (или термин) обычно представляет собой концепцию, описание или вещь. Пример:

* "У класса есть частный конструктор и общедоступный статический метод для получения экземпляра класса. Класс создает свой собственный экземпляр и сохраняет его как частный статический член класса.".

  • Приведенное выше описание широко известно как Singleton Pattern. Когда кто-то читает или слышит Singleton Pattern, становится ясно, что имеется в виду. Нет необходимости повторять приведенное выше описание концепции.

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

* Названия/термины в Программном обеспечении можно разделить на две части.

  1. Внешний вид: имена, доступные конечным пользователям.

    2. Внутреннее представление: имена, относящиеся только к команде разработчиков программного обеспечения.

Names in External and Internal View

  • Имена в Внешнем представлении присваиваются функциями управления продуктами и маркетинга на основе различных факторов. Мы не будем заострять на этом внимание.

* В внутреннем представлении имена, используемые для релизов, проектов, инициатив, команд и т. д., являются временными и актуальными только до тех пор, пока они не используются, например, каждый выпуск Android имел какое-то имя, например Marshmallow. (6.0), Oreo (8.0) и т. д. Это имена, используемые внутри во время разработки. Он не используется после завершения работы, поэтому имена в этой категории не так важны с точки зрения разработки программного обеспечения.

* Мы сосредоточимся на других именах в внутреннем представлении. Их можно разделить на две группы:

  1. Материалы: названия вещей, которые вы можете видеть.

    2. Аннотации: названия логических понятий, определений и т. д.

Attributes of Tangibles and Abstracts

  • Имена в обеих этих категориях актуальны на протяжении всего срока службы Программного обеспечения, но имеют ограниченный срок службы памяти. Таким образом, эти названия должны быть как можно более понятными, то есть они должны легко передавать смысл того, что они представляют, когда кто-то их читает.

* Как сделать имена понятными? Эти методы именования могут помочь:

* Использование самостоятельных названий может значительно улучшить обслуживаемость Программного обеспечения. Это облегчит любому новому человеку, присоединяющемуся к команде, понимание кодовой базы, развертывания, дизайна и т. д.

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

Дизайн, ориентированный на домен

  • Дизайн, ориентированный на предметную область (DDD), – это подход, при котором разработка программного обеспечения должна соответствовать модели бизнес-домена.

* Один из важных принципов DDD называется Повсеместный язык: общая терминология между бизнес-сферой и Программным обеспечением. Чтобы объяснить это в текущем контексте, DDD говорит, что один и тот же термин (имя) должен использоваться на всем протяжении от бизнес-домена до уровня исходного кода. Давайте посмотрим на пример:

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


* All Design and other documentation should use the term *file* or *filing*.

  
* Database table should be like `income_tax_return_filing`

  
* Classes should be like `IncomeTaxReturnFilingController`, `IncomeTaxReturnFilingRepository`

  
* Method name should use *file* or *filing*.

Как мы видим, в названии много смысла! Поделитесь своим мнением в комментариях.

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE