✖


Jump to content

Лучшие практики кодирования

(Перенаправлено из «Лучшие практики кодирования »)

Лучшие практики кодирования или лучшие практики программирования — это набор неформальных, иногда личных, правил ( лучших практик многие разработчики программного обеспечения в области компьютерного программирования ), которым следуют для улучшения качества программного обеспечения . [1] Многие компьютерные программы требуют устойчивости и надежности в течение длительных периодов времени. [2] поэтому любые правила должны облегчать как первоначальную разработку, так и последующую поддержку исходного кода людьми, не являющимися первоначальными авторами.

В правиле девяносто-девяноста Том Каргилл объясняет, почему проекты по программированию часто задерживаются: «Первые 90% кода занимают первые 90% времени разработки. Последние 10% занимают еще 90% времени». [3] Любые рекомендации, которые могут исправить эту недальновидность, заслуживают рассмотрения.

Размер проекта или программы оказывает существенное влияние на частоту ошибок, производительность программистов и объем необходимого управления. [4]

Качество программного обеспечения [ править ]

Основная статья: Качество программного обеспечения

связано с множеством атрибутов Как указано ниже, хорошее программное обеспечение . Некоторые из них могут быть взаимопротиворечивыми (например, очень высокая скорость или тщательная проверка ошибок), а разные клиенты и участники могут иметь разные приоритеты. Вайнберг приводит пример того, как разные цели могут существенно повлиять как на требуемые усилия, так и на эффективность. [5] Более того, он отмечает, что программисты обычно стремятся достичь любых явных целей, которые могут быть поставлены, возможно, за счет любых других атрибутов качества.

Соммервилль выделил четыре обобщенных атрибута, которые касаются не того, что делает программа, а того, насколько хорошо она это делает: ремонтопригодность , надежность , эффективность и удобство использования . [6]

Вайнберг определил четыре цели, которым должна соответствовать хорошая программа: [7]

  • Соответствует ли программа своей спецификации («правильный вывод для каждого возможного ввода»)?
  • Выпускается ли программа по графику (и в рамках бюджета)?
  • Насколько адаптируема программа к изменяющимся требованиям?
  • Достаточно ли эффективна программа для среды, в которой она используется?

Хоар определил семнадцать целей, связанных с качеством программного обеспечения, в том числе: [8]

Предварительные условия [ править ]

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

От Meek & Heath: «То, что происходит до того, как человек переходит к этапу кодирования, часто имеет решающее значение для успеха проекта». [9]

Предварительные условия, изложенные ниже, охватывают такие вопросы, как:

  • Как построена разработка? (жизненный цикл)
  • Для чего предназначено программное обеспечение? (требования)
  • Какова общая структура программной системы? (архитектура)
  • Какова детальная проработка отдельных компонентов? (дизайн)
  • Каков выбор языка(ов) программирования?

Для небольших простых проектов может оказаться целесообразным объединить архитектуру с дизайном и принять очень простой жизненный цикл.

Жизненный цикл [ править ]

Основная статья: Методология разработки программного обеспечения

Методология разработки программного обеспечения — это структура, которая используется для структурирования, планирования и контроля жизненного цикла программного продукта. Общие методологии включают водопад , прототипирование , итеративную и инкрементную разработку , спиральную разработку , гибкую разработку программного обеспечения , быструю разработку приложений и экстремальное программирование .

Водопадная модель представляет собой последовательный подход к разработке; в частности, предполагается, что требования могут быть полностью определены в начале проекта. Однако МакКоннелл цитирует три исследования, которые показывают, что в среднем требования меняются примерно на 25% в ходе проекта. [10] Другие упомянутые выше методологии пытаются уменьшить влияние таких изменений требований, часто с помощью той или иной формы поэтапного, инкрементального или итеративного подхода. Для разных сред разработки могут подходить разные методологии.

С момента своего появления в 2001 году популярность гибкой разработки программного обеспечения возросла, чему способствовали разработчики программного обеспечения, стремящиеся к более итеративному и совместному подходу к разработке программного обеспечения. [11]

Требования [ править ]

Основная статья: Разработка требований

МакКоннелл заявляет: «Первое предварительное условие, которое вам необходимо выполнить перед началом строительства, — это четкое определение проблемы, которую должна решить система». [12]

Мик и Хит подчеркивают, что целью, к которой следует стремиться, является ясная, полная, точная и недвусмысленная письменная спецификация. [13] Обратите внимание, что достичь этой цели может быть невозможно, и цель, скорее всего, все равно изменится (как упоминалось в предыдущем разделе).

Соммервилль различает менее подробные требования пользователя и более подробные системные требования. [14] Он также различает функциональные требования (например, обновление записи) и нефункциональные требования (например, время ответа должно быть менее 1 секунды).

Архитектура [ править ]

Основная статья: Архитектура программного обеспечения

Хоар указывает: «Есть два способа создания проекта программного обеспечения: один способ — сделать его настолько простым, чтобы не было очевидных недостатков; другой способ — сделать его настолько сложным, чтобы не было очевидных недостатков. Первый метод — гораздо сложнее». [15]

Архитектура программного обеспечения связана с решением того, что должно быть сделано и какой программный компонент будет это делать (то, как что-то будет сделано, остается на этапе детального проектирования ниже). Это особенно важно, когда система программного обеспечения содержит более одной программы, поскольку она эффективно определяет интерфейс между этими различными программами. Он также должен включать в себя некоторое рассмотрение любых пользовательских интерфейсов, не вдаваясь в чрезмерные детали.

На этом этапе необходимо учитывать любые нефункциональные требования к системе (время отклика, надежность, ремонтопригодность и т. д.). [16]

Архитектура программного обеспечения также представляет интерес для различных заинтересованных сторон (спонсоров, конечных пользователей и т. д.), поскольку дает им возможность проверить, могут ли быть выполнены их требования.

Дизайн [ править ]

Основная статья: Разработка программного обеспечения

Основная цель дизайна — заполнить детали, которые были упущены в архитектурном проекте. Цель состоит в том, чтобы проект был достаточно подробным, чтобы обеспечить хорошее руководство для фактического кодирования, включая детали любых конкретных алгоритмов, которые будут использоваться. Например, на архитектурном уровне можно было отметить, что некоторые данные необходимо отсортировать, а на уровне проектирования необходимо решить, какой алгоритм сортировки использовать. В качестве еще одного примера: если используется объектно-ориентированный подход, необходимо определить детали объектов (атрибуты и методы).

Выбор языка(ов) программирования [ править ]

Майер утверждает: «Ни один язык программирования не идеален. Не существует даже одного лучшего языка; есть только языки, которые хорошо или, возможно, плохо подходят для определенных целей. Понимание проблемы и связанных с ней требований программирования необходимо для выбора языка, лучше всего подходящего для конкретной цели». решение." [17]

Из книги Мика и Хита: «Суть искусства выбора языка состоит в том, чтобы начать с проблемы, решить, каковы ее требования и их относительную важность, поскольку, вероятно, будет невозможно одинаково хорошо удовлетворить их все. Затем должны быть доступны доступные языки. оцениваться по списку требований и выбирать наиболее подходящий (или наименее неудовлетворительный)». [18]

Вполне возможно, что разные языки программирования подходят для разных аспектов проблемы. Если языки или их компиляторы позволяют, возможно объединить в одной программе подпрограммы, написанные на разных языках.

Даже если нет выбора, какой язык программирования использовать, МакКоннелл дает несколько советов: «У каждого языка программирования есть сильные и слабые стороны. Помните о конкретных сильных и слабых сторонах языка, который вы используете». [19]

Стандарты кодирования [ править ]

Основная статья: Соглашения о кодировании

Этот раздел также является необходимым условием для кодирования, как указывает МакКоннелл: «Определите соглашения программирования, прежде чем приступить к программированию. Почти невозможно изменить код, чтобы он соответствовал им позже». [19]

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

Использование соглашений о кодировании особенно важно, когда в проекте участвует более одного программиста (были проекты с участием тысяч программистов). Программисту гораздо легче читать код, написанный кем-то другим, если весь код соответствует одним и тем же соглашениям.

В качестве примеров плохих соглашений по кодированию Роуди Грин приводит длинную (ироничную) статью о том, как создавать неподдерживаемый код. [20]

Комментирование [ править ]

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

На заре компьютерной эры одной из практик комментирования было оставлять краткое описание следующего:

  1. Название модуля
  2. Цель модуля
  3. Описание модуля
  4. Оригинальный автор
  5. Модификации
  6. Авторы, изменившие код, с описанием причин его изменения.

«Описание модуля» должно быть как можно более кратким, но без ущерба для ясности и полноты.

Однако последние два пункта в значительной степени устарели с появлением систем контроля версий . Изменения и их авторство можно надежно отслеживать с помощью таких инструментов, а не с помощью комментариев.

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

Модульное тестирование может быть еще одним способом показать, как предполагается использовать код.

Соглашения об именах [ править ]

Смотрите также: венгерские обозначения

Использование правильных соглашений об именах считается хорошей практикой. Иногда программисты склонны использовать X1, Y1 и т. д. в качестве переменных и забывают заменить их значимыми, что приводит к путанице.

Обычно считается хорошей практикой использовать описательные имена.

Пример. Переменная, которая принимает вес в качестве параметра для грузовика, может называться TrkWeight, TruckWeightKilograms или Truck_Weight_Kilograms, при этом TruckWeightKilograms (см. именование переменных в регистре Pascal ) часто является предпочтительным, поскольку ее можно сразу распознать, но соглашение об именах не всегда соблюдается. согласованность между проектами и/или компаниями.

Сохраняйте код простым [ править ]

Код, который пишет программист, должен быть простым. Сложная логика для достижения простой цели должна быть сведена к минимуму, поскольку в будущем код может быть изменен другим программистом. Логика, реализованная одним программистом, может не иметь смысла для другого. Поэтому всегда старайтесь сделать код максимально простым. [21]

Портативность [ править ]

Код программы не должен содержать «жестко закодированных» (буквальных) значений, относящихся к параметрам среды, таким как абсолютные пути к файлам, имена файлов, имена пользователей, имена хостов, IP-адреса и URL-адреса, порты UDP/TCP. В противном случае приложение не будет работать на хосте, дизайн которого отличается от ожидаемого. Осторожный программист может параметризовать такие переменные и настроить их для среды размещения за пределами самого приложения (например, в файлах свойств, на сервере приложений или даже в базе данных). Сравните мантру о «единой точке определения». [22] (НИЖНИЙ).

В качестве расширения такие ресурсы, как файлы XML, также должны содержать переменные, а не литеральные значения, в противном случае приложение не будет перенесено в другую среду без редактирования файлов XML. Например, если приложения J2EE работают на сервере приложений, такие параметры среды могут быть определены в области JVM, и приложение должно получать значения оттуда.

Масштабируемость [ править ]

Разрабатывайте код с масштабируемостью в качестве цели дизайна, потому что очень часто в проектах программного обеспечения в проект, который становится больше, всегда добавляются новые функции. Таким образом, возможность добавлять новые функции в базу кода программного обеспечения становится неоценимым методом написания программного обеспечения.

Повторное использование [ править ]

Повторное использование — очень важная цель проектирования при разработке программного обеспечения. Повторное использование сокращает затраты на разработку, а также сокращает время разработки, если повторно используемые компоненты или модули уже протестированы. Очень часто проекты программного обеспечения начинаются с существующей базовой версии, которая содержит проект в его предыдущей версии, и в зависимости от проекта многие существующие программные модули и компоненты используются повторно, что сокращает время разработки и тестирования и, следовательно, увеличивает вероятность поставки программного обеспечения. проект по графику.

Краткое руководство по строительству [ править ]

Общий обзор всего вышеперечисленного:

  1. Знайте, что должен выполнять блок кода
  2. Соблюдайте единые правила именования.
  3. Укажите краткое описание, для чего нужна переменная (ссылка на комментарий)
  4. Исправляйте ошибки по мере их возникновения.
  5. Держите свой код простым
  6. Разрабатывайте код с учетом масштабируемости и повторного использования.

Разработка кода [ править ]

Создание кода [ править ]

Лучшая практика создания кода предполагает ежедневные сборки и тестирование или, еще лучше, непрерывную интеграцию или даже непрерывную доставку .

Тестирование [ править ]

Основная статья: Тестирование программного обеспечения

Тестирование — неотъемлемая часть разработки программного обеспечения, которую необходимо планировать. Также важно, чтобы тестирование проводилось заранее; это означает, что тестовые примеры планируются до начала кодирования, а тестовые сценарии разрабатываются во время проектирования и кодирования приложения.

Отладка кода и исправление ошибок [ править ]

Программисты склонны писать полный код, а затем приступать к его отладке и проверке на наличие ошибок. Хотя этот подход может сэкономить время в небольших проектах, более крупные и сложные проекты, как правило, требуют меньше времени.иметь слишком много переменных и функций, требующих внимания. Поэтому после завершения отладки полезно отлаживать каждый модуль, а не всю программу. В конечном итоге это экономит время, и вам не придется тратить много времени на выяснение того, что не так. модульные тесты для отдельных модулей и/или функциональные тесты для веб-сервисов В этом могут помочь и веб-приложений.

Развертывание [ править ]

Основные статьи: Развертывание программного обеспечения и среда развертывания.

Развертывание — это заключительный этап выпуска приложения для пользователей. Некоторые лучшие практики: [23] [24]

  1. Сохраняйте простую структуру установки: количество файлов и каталогов должно быть сведено к минимуму. Не устанавливайте ничего, что никогда не будет использоваться.
  2. Оставляйте только то, что необходимо. Действия по управлению конфигурацией программного обеспечения должны обеспечивать соблюдение этого требования. Неиспользуемые ресурсы (старые или вышедшие из строя версии файлов, исходный код, интерфейсы и т. д.) необходимо архивировать где-нибудь в другом месте, чтобы новые сборки оставались экономичными.
  3. Постоянно обновляйте все: действия по управлению конфигурацией программного обеспечения должны обеспечивать соблюдение этого требования. При развертывании на основе разностей перед развертыванием разностей убедитесь, что версии уже развернутых ресурсов являются самыми последними. Если вы не уверены, выполните развертывание с нуля (сначала удалите все, а затем выполните повторное развертывание).
  4. Примите многоэтапную стратегию: в зависимости от размера проекта иногда требуется больше развертываний. [25]
  5. Имейте стратегию отката: Должен быть способ вернуться к предыдущей (рабочей) версии.
  6. Положитесь на автоматизацию для повторяющихся процессов: существует слишком много места для человеческой ошибки, поэтому развертывание не должно выполняться вручную. Используйте инструмент, встроенный в каждую операционную систему, или используйте язык сценариев для кроссплатформенных развертываний. [26] [27]
  7. Воссоздайте реальную среду развертывания: учтите все (маршрутизаторы, межсетевые экраны, веб-серверы, веб-браузеры, файловые системы и т. д.).
  8. Не меняйте процедуры и сценарии развертывания на лету и документируйте такие изменения: дождитесь новой итерации и запишите такие изменения соответствующим образом.
  9. Настройка развертывания. Новые программные продукты, такие как API, микросервисы и т. д., требуют особого внимания для успешного развертывания. [28] [29] [30]
  10. Уменьшите риск на других этапах разработки: если другие действия, такие как тестирование и управление конфигурацией, неверны, развертывание наверняка завершится неудачей. [31] [32]
  11. Учитывайте влияние каждой заинтересованной стороны: организационные, социальные и правительственные соображения. [33] [34] [35]

См. также [ править ]

Примечания [ править ]

Ссылки [ править ]

  1. ^ МакКоннелл, Стив (2004). Код завершен . Редмонд, Вашингтон: Microsoft Press. п. [ нужна страница ] . ISBN  978-0-7356-9125-4 . OCLC   61315783 .
  2. ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. п. 38. ISBN  0-321-21026-3 .
  3. ^ Бентли, Джон (1985). «Жемчужины программирования: информатика на бампере» . Коммуникации АКМ . 28 (9): 896–901. дои : 10.1145/4284.315122 . ISSN   0001-0782 . S2CID   5832776 .
  4. ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. стр. 649–659 . ISBN  0-7356-1967-0 .
  5. ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (изд. Серебряного юбилея). Издательство Дорсет Хаус, Нью-Йорк. стр. 128–132. ISBN  978-0-932633-42-2 .
  6. ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. стр. 12–13. ISBN  0-321-21026-3 .
  7. ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (изд. Серебряного юбилея). Издательство Дорсет Хаус, Нью-Йорк. стр. 15–25. ISBN  978-0-932633-42-2 .
  8. ^ Хоар, ЦАР (1972). «Качество программного обеспечения» . Программное обеспечение: практика и опыт . 2 (2). Уайли: 103–105. дои : 10.1002/спе.4380020202 .
  9. ^ Мик, Брайан; Хит, Патриция (1980), Руководство по хорошей практике программирования , Эллис Хорвуд, Wiley, стр. 14
  10. ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. п. 40 . ISBN  0-7356-1967-0 .
  11. ^ Саколик, Исаак (8 апреля 2022 г.). «Краткая история гибкой методологии» . Инфомир . Проверено 6 февраля 2023 г.
  12. ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. п. 36 . ISBN  0-7356-1967-0 .
  13. ^ Мик, Брайан; Хит, Патриция (1980), Руководство по хорошей практике программирования , Эллис Хорвуд, Wiley, стр. 15
  14. ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. стр. 118–123. ISBN  0-321-21026-3 .
  15. ^ Хоар, ЦАР (1981). «Старая одежда императора» (PDF) . Коммуникации АКМ . 24 (2). АКМ: 75–83. дои : 10.1145/358549.358561 . S2CID   97895 . Проверено 25 ноября 2019 г.
  16. ^ Соммервилл, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. стр. 242–243. ISBN  0-321-21026-3 .
  17. ^ Майер, Герберт (1989). Продвинутое программирование на языке C на IBM PC . Книги Виндкреста. п. xii (предисловие). ISBN  0830693637 .
  18. ^ Мик, Брайан; Хит, Патриция (1980), Руководство по хорошей практике программирования , Эллис Хорвуд, Wiley, стр. 37
  19. ^ Jump up to: Перейти обратно: а б МакКоннелл, Стив (2004). Код завершен (второе изд.). Майкрософт Пресс. п. 70 . ISBN  0-7356-1967-0 .
  20. ^ Роуди Грин. «неподдерживаемый код: Глоссарий Java» . Проверено 26 ноября 2013 г.
  21. ^ Несколько (вики). «Лучшие практики» . Докфорж . Проверено 13 ноября 2012 г.
  22. ^ «Единая точка определения на примере» . Проверено 30 ноября 2015 г. — Ничего не повторяй. Стремитесь к единой точке определения для каждого аспекта вашего приложения [...]».
  23. ^ «7 лучших практик по развертыванию приложений – Done Devops» . dzone.com .
  24. ^ «Семь смертных грехов развертывания программного обеспечения [LWN.net]» . lwn.net .
  25. ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
  26. ^ Круз, Виктор (3 апреля 2013 г.). «Почему 30% развертываний приложений терпят неудачу» . Проводной – через www.wired.com.
  27. ^ «Правила развертывания программного обеспечения» . Архивировано из оригинала 13 мая 2010 г.
  28. ^ «Инструменты, необходимые для ускорения развертывания в соответствии со спросом» . 3 февраля 2017 г.
  29. ^ Анкерхольц, Эмбер (14 сентября 2016 г.). «DevOps и искусство безопасного развертывания приложений» .
  30. ^ «Организация развертывания программного обеспечения с учетом условий сбоя» . Веб-сервисы Amazon . 5 мая 2014 г.
  31. ^ «Лучшие практики для безопасного развертывания» . TheServerSide.com .
  32. ^ Эмблер, Скотт. «Эффективное развертывание программного обеспечения» . Доктор Добб .
  33. ^ «Развертывание корпоративных приложений: гуманность внедрения программного обеспечения» . Архивировано из оригинала 21 августа 2016 г.
  34. ^ «Хакерская бюрократия: улучшение найма и развертывания программного обеспечения | 18F: Предоставление цифровых услуг» . 18f.gsa.gov . 14 мая 2014 г.
  35. ^ «Плохое развертывание программного обеспечения хуже, чем ничего не делать» . Неповрежденная технология . 1 июня 2016 г.
  36. ^ Дэвис, Алан Марк. (1995). 201 принцип разработки программного обеспечения . Нью-Йорк: МакГроу-Хилл. ISBN  0-07-015840-1 . OCLC   31814837 .
  37. ^ Джонсон, Понт; Экстедт, Матиас; Джейкобсон, Ивар (2012). «Где теория разработки программного обеспечения?». Программное обеспечение IEEE . 29 (5): 96. doi : 10.1109/MS.2012.127 . ISSN   0740-7459 . S2CID   38239662 .
  38. ^ Круг, Стив (2014). Не заставляйте меня думать, еще раз: подход здравого смысла к удобству использования Интернета . Бэйл, Элизабет, Стрейгер, Арен, Матчо, Марк (Третье изд.). [Сан-Франциско, Калифорния]. ISBN  978-0-321-96551-6 . OCLC   859556499 . {{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Coding_best_practices&oldid=1227594824"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: c620f78b0711db105b988e90e36fb050__1717685520
URL1:https://arc.ask3.ru/arc/aa/c6/50/c620f78b0711db105b988e90e36fb050.html
Заголовок, (Title) документа по адресу, URL1:
Coding best practices - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)