Методы

Аннотация

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

Исследование рассматривается со стороны коммерческого сектора и самых эффективных форматов безопасной разработки. Исследование рассматривается с применением в практической части данных вариатив и их специфик в целом, и частном формате. Целью данной статьи является передача опыта и аналитика данных применяемых методологий, методов и средств разработки в защищенном исполнении. В статье представлен анализ, соответствующий разбор действующего рынка, законодательства, в части касающейся разработки информационных систем и сред в защищенном исполнении, которая именуются также как безопасная разработка, и которая с каждым днем набирает "критическую массу" популярности в различных отраслевых компаниях из-за ужесточения рекомендаций и требований регуляторов ИБ [1].

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

Введение

Данная статья базируется на принципах и процессах автоматизации ИС и сред организации, где рассматривается вопрос со стороны личной практики как руководителя, так и разработчика. В статье представлено практическое оценочное мнение и его эффективность. Частично статья касается вопроса со стороны OWASP TOP 10, но акцент на этом будет поставлен в последующих статьях. Стоит отметить, что не рассматривается практика сертификации, аттестации, выполнении требований опытных лабораторий, проектирования ПО по ПП РФ 608, включая приказ ФСТЭК России 55 и иных документов по безопасной разработке в данном направлении. Рассматривается формат представления универсальных характеристик разработки в безопасном исполнении, автоматизации, оптимизации, масштабируемости, адаптации БП (бизнес процесс), в формате ГОСТ Р 56939.

В коммерческом секторе РФ отсутствует установленное понятие для всех ветвей организации управления организации, в сфере прямо или косвенно касающихся IT и смежных с данными подразделений, такого как: ИС (информационная система) и среда. В том числе отсутствует понимание ее классификации в целом и частном порядке. В общепринятом представлении на рынке в потребительской сфере также отсутствует понимание построения структуры и непосредственно семантики работы ИС и сред. Данный общепринятый формат объясняется следующим образом, что методы, средства и методологии разработки по созданию, оптимизации, масштабируемости, итерационной интеграции, введению в промышленную эксплуатацию каноничны, во всем промежутке времени, которые парраллелелись по различным специфичным и обособленным между собою направлениям с применением разного рода подходов и методов для их реализаций. В последствии чего стали возникать угрозы, риски и последствия инцидентов для организаций, которые занимались обработкой, хранением информации, в том числе остро возник вопрос по ОИБ (обеспечение ИБ) информации: целостности, доступности, конфиденциальности. Этот вопрос также будет разобран отдельно в следующих статьях, где стоит отметить, что важнейшим аспектом стало на сегодня ОИБ КИИ РФ, также отдельно взяло направление по оценке рисков и инцидентов, в формате СУИБ (система управления информационной безопасности) и многое другое. В последствии данных форматов и форм-факторов возник вопрос безопасной разработки в организациях, где направление стало развиваться в геометрической прогрессии и набирать экспоненциальные обороты.

Информация и ИС в безопасной разработке

Приведем ИС в автоматизированном исполнении по типам, которые имеются на сегодняшний день и в связи с которыми разрослись методы, средства и методологии их реализации в разработке, проектировании и прототипировании, а именно:

1. Автоматизированные системы управления:
   1.1. Техническими процессами;
   1.2. Предприятием;
   1.3. Производством.
2. Системы автоматизированного проектирования и расчета, проектирования технологических процессов;
3. Автоматизированные системы научных исследований;
4. Автоматизированные системы обработки, передачи данных и БД, такие как:
   4.1. Автоматизированные информационно-поисковые системы;
   4.2. Автоматизированные системы информационно-терминологического обслуживания.
5. Автоматизированные информационные системы, представляющие из себя агрегаторы информации;
6. Автоматизированные системы технологической подготовки производства;
7. Автоматизированные системы контроля и испытаний;
8. Автоматизированные комплексные системы, методологические функциональные возможности специфик предприятий;
9. Автоматизированные информационные системы общего назначения;
10. Автоматизированные системы научно-технологической формации, оптимизации и сведения;
11. Автоматизированные системы нормативно-правовой документации, нормативно-методического и методологического обеспечения управления предприятием;
12. Автоматизированные обучающие системы организации;
13. Автоматизированные системы виртуальной реальности;
14. Автоматизированные профессионально ориентированные системы, экономические информационные системы, такие как:
    14.1. Бухгалтерские;
    14.2. Банковские;
    14.3. Рынка ценных бумаг;
    14.4. Маркетинговые;
    14.5. Продажные.
15. Автоматизированные информационные системы профильного назначения по БП организаций.

Исходя из приведенного формата стоит дать определение термина информация, применяемого в безопасной разработке, касательно АИС (автоматизированная информационная система) в отношении действующего законодательства РФ, а именно:

1. Это совокупность сведений, не зависимо от их формы, которые представляют из себя формализованный или не формализованный вид сообщения в независимой и ликвидной, либо не ликвидной форме;
2. Это система комбинирования взаимодействующих элементов, организованных и структурированных форматов для достижения определенных поставленных целей и задач [2-5].

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

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

С точки зрения ФЗ РФ 149 с изменениями и дополнениями, приводится следующее определение, такое как: Информационная система это совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств. Следовательно, отметим, что ИС представляется как прикладная подсистема, которая ориентирована на сбор, хранение, поиск и обработку текстовой или фактографической информации, работающая в режиме диалога с пользователем.

Далее отметим универсальные характеристики для безопасной разработки ИС, такие как:

1. Основное назначения функционирования: сбор, хранение и обработка информации;
2. Нацеленность функционирования АИС под потребительские нужны и цели, при необходимости реализации: объединения и распараллеливания функциональных возможностей АИС на подразделения и структуры, непосредственно самой организации;
3. Представление проектирования интерфейса, в том числе соотношения UI/UX, прикладного программно-аппаратного обеспечения, как принцип минимальной содержательной достаточности для представление реализации взаимодействия функционирования АИС с исключением эксплуатационной возможности НДВ (не декларированных возможностей), в целом и частном.

Общая спецификация методологий по безопасной разработки ПО

Под спецификацией методологии понимается объединение перечня средств и методов, применяющихся в специфике деятельности организации, со стороны теории и практики разработки, включая прототипирование. Методологией является формат объединения методов, средств и технологий, применяющихся во время всего жизненного цикла процесса разработки и прототипирования ПО в организации. Данный формат является совокупностью практически выработанного и действующего формата в узконаправленной специфике организации для всей программно-аппаратной части и комплекса в целом. Следовательно стоит отметить, что также под методологией безопасной разработки ИС понимается организация процессов прототипирования и выстраивания ИС и сред, таких как: обеспечения управления процессами для гарантированного выполнения ТТ, ТЗ и реорганизации процессов [6-10].

Приведем список-перечень задач для достижения обеспечения действенности методологии безопасной разработки ИС и среды, состоящей из:

1. Представления разработки и внедрения в промышленную эксплуатацию АИС, отвечающей целевым нуждам и спецификации по политикам работы организаций, в том числе ТТ и законодательных актов РФ, а также внутренних политик организаций и предъявленных к ним требований;
2. Предоставления гарантий выполнения требований действующих регуляторов из специфики организации и приложений на разработку и интеграцию АИС с заданными параметрами, относительно ТТ и ТЗ в течение утвержденного календарного плана, а также оговоренного бюджета на разработку. Данный формат также может рассматриваться исходя из применяемых методов разработки ПО;
3. Представления сопровождения технической и методологической части обучения, также модификации и масштабирования системы для обеспечения соответствия целевых нужд организаций, в том числе формата поддержания S.M.A.R.T.;
4. Представления обеспечения разработки и внедрения в промышленную эксплуатацию АИС, отвечающей требованиям оптимизированности, переносимости, масштабируемости, адаптивности;
5. Представления возможности вариативного использования в АИС разработанных средств и методов в программно-аппаратном обеспечении, СУБД, СУИБ и тому подобное. Отметим, что данный формат зависит от политик применяемых организацией, а также ее сферы деятельности.

Целью методологии является присвоение рамок конечного функционирования и бесперебойной работоспособности АИС по целевым и первоочередным нуждам организации. В реализации АИС применяются специализированные подсистемы ИБ для формирования средств и методов разработки и прототипирования посредством политик ИБ организации в СУИБ. Данные политики представляются в виде списка-перечня определенных действий для персонала, согласно определенной технологической базы и функционирования данных систем в настоящем, и будущем времени при использовании в промышленной эксплуатации.

Опираясь на сводную классификацию проектной части работы Одинцова И.О.: "Профессиональное программирование. Системный подход", следует выделить:

1. Классификацию по ядрам методологий, в которой утверждается, что имеет место быть ядру методологии с методами, которые уточняются дополнительными особенностями, а сами ядра определяются способами описания их алгоритмов, где к ним соотносятся:
   1.1. Методология императивного программирования, которая характеризуется принципом последовательного изменения состояния операнд итерационным образом, ориентированная на классическую модель Джона фон Неймана, получившей широкое практическое и теоретическое применение, с такими концепциями как:
   1.1.1. Метод последовательного изменения состояний, поддерживаемый концепцией алгоритма;
   1.1.2. Метод потокового управления на исполнение, в итерационном контроле.
   1.2. Методология объектно-ориентированного программирования (ООП), которая использует объектные декомпозиции. Отметим, что статическая структура ИС и сред описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами, как в UI/UX и системном программировании. Пример: инкапсуляция, то есть абстрактный тип данных, его наследование и полиморфизм, с применение таких методов как:
   1.2.1. Метод объектно-ориентированной декомпозиции, который заключается в выделении объектов и связей между ними, поддерживающийся концепциями инкапсуляции, наследования и полиморфизма;
   1.2.2. Метод абстрактных типов данных, который лежит в основе инкапсуляции, поддерживающийся концепцией абстрагирования;
   1.2.3. Метод пересылки сообщений, который заключается в описании поведения системы в терминах обмена сообщениями между объектами, поддерживаемый концепцией сообщения.
   1.3. Методология функционального программирования как способ составления программно-аппаратной части, в которой единственным действием является вызов функции, как вариативы, то есть способа расчленения программно-аппаратной части на отдельные сектора, где имеет место быть формат введения имени для функции и задания для него вычисляющего значения, применяемый с такими методами концепций как:
   1.3.1. Метод аппликативности, где: программно-аппаратная часть есть выражение, которое подставлено из функции к аргументу, состоящему из определения функции, представляющей собой вызов от другой функций и вложенной друг в друга, поддерживается концепцией функции;
   1.3.2. Метод рекурсивного поведения, который заключается в самоповторяющемся поведении, то есть возвращающемуся к самому себе, поддерживается концепцией рекурсии;
   1.3.3. Метод настраиваемости, который заключается в порождении новых программных объектов по специальному образцу, где значения соответствующих выражений применяется как порождающая функция к параметрам образца [11].
   1.4. Методология логического программирования, где программно-аппаратная часть содержит описание проблемы в терминах фактов и логических формул, а решение проблемы ИС и среды выполняется с помощью механизмов логического вывода, где применяются такие методы и концепции как:
   1.4.1. Метод единообразия, где используется применение механизма логического доказательства ко всей программе;
   1.4.2. Метод унификации, то есть механизм сопоставления с образцом для создания и декомпозиции структур БД.
   1.5. Методология программирования с ограничениями, при котором в ПО определяется тип данных для его решения, где предметная область шифруется на соответствующие ограничения значений искомого решения, которая находится в ИС и средах. В данной методологии предлагается двухуровневая архитектура, которая интегрируется как компонент ограничения программно-аппаратного компонента. В данном формате подразумевается описательная модель вычислений, где программа содержит описание понятий и задач в формате поддерживания концепции модели.
2. Классификацию по топологической специфике самой методологий то есть форм-факторы топологии на базе методологии со способностью выбора самих методов для получения уточненного ядра, с такими методами и концепциями как:
   2.1. Последовательная декомпозиция алгоритма решения задачи сверху вниз в итерационной детализации, которая начинается с общей задачи и обеспечивает ее структурированность, которая поддерживается концепцией алгоритма;
   2.2. Метод модульной организации частей программы, где происходит разбиение программы на специальные компоненты, которые поддерживаются концепцией модуля;
   2.3. Использование структурного кодирования, где используется кодирование трех основных управляющих конструкций, которые поддерживаются концепцией управления.
3. Классификацию по реализационной специфике методологии, где применяется использование каждого из ядер методологии с конкретной спецификой. В данной классификации определяется некоторая организация аппаратной поддержки, такая как: централизованная или параллельная, использующаяся для централизованных архитектур;
4. Классификацию по смешанной методологии, которая включает объединение методов нескольких методологий, таких как методологии функционального и логического программирования;
5. Классификацию по идейной задумке Петрова В.Н.: "Технологии разработки программного обеспечения", являющейся методологией RAD (Rapid Application Development). Данная методология носит наименование методологии быстрой разработки приложений. Целевая предпосылка в области инструментальных средств быстрой разработки приложений основана на таких элементах как:
   5.1. Объёмное положение разработчиков, которые разрабатывают АИС со всей спецификой и вариацией относительно ТТ, ТЗ. Например: минимальная группа разработчиков, представляет из себя от 2 до 10 человек, для большей части вариатива, может достигать до 100 разработчиков, такая специфика прослеживается в основном в игровой индустрии;
   5.2. Тщательная проработка производственного графа работ кадрового состава организации, его оптимизации и управления над ним, так же влияющий на календарный план разработки и прототипирования. Данный граф по временным отрезкам представляется от 2 до 6 месяцев, в среднем, но все зависит от целевых нужд организации для АИС, согласно ТТ и ТЗ.

Следует отметить, что приведенные методологии позволяют обеспечить безопасную разработку в организации по всем БП, что в свою очередь облегчит функционирование организации и управления кадровым составом, а это позволить повысить рентабельность и ликвидность конечного продукта. Данные форматы являются опосредованными и целостным, где позволят предотвратить методы и меры по OWASP TOP 10, что снизит риски и шансы возникновения инцидентов, а также их расследований по семейству ISO/IEK 27000.

Принципы выбора методологий в безопасной разработке

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

Следовательно, первоочередно стоит привести классическую (каноническую, монументальную) методологию, которая применяется исходя из наличия следующих принципов, таких как:

1. Четкое понимание необходимого и конечного функционала, дизайна, прототипа интерфейса UI/UX и всей грядущей разработки АИС, то есть присутствует детализация специфики АИС. Стоит отметить, что она является четко регламентированной, с конечным конкретным ТЗ и ТТ, где описано: что и как должно работать;
2. Формализованные целевые нужды конечного потребителя, тогда когда разработчики и руководящий состав, включая Заказчика представляют четкую "картину" в документированном виде, то есть: создается подробное ТЗ, где данная дефиниция регламентируется полноценным процессным состоянием каждого элемента в АИС, которая также содержит полноценное описание в цикле по специализированным алгоритмам, включая детализацию по UI/UX;
3. Конечные требования к АИС являются стабильными, вследствие чего потребитель не дополняет условий по изменению функциональности АИС во время ее разработки, модернизации, исключая возможный формат блочного масштабирования в рамках текущих отношений;
4. Представление итерационного процесса в формации аналитики, где проектирование и разработка ТЗ строго линейно.

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

Приведем далее более гибкую адаптивную методологию, которая применяется по следующим принципам, таким как:

1. Предоставляются не понятийные, изменчивые требования к АИС;
2. Потребителю предоставляется разрабатываемая АИС только в общих очерках, где предполагается внесение изменений функциональности или дизайна разрабатываемой АИС посредственно в сам момент произведения процесса разработки;
3. Представление необходимости быстрого получения первых вариаций версионности продукта и дальнейшего масштабирования исходя от нужд организации и решений Digital, в момент работающего АИС;
4. Представление решаемой задачи посредством программно-аппаратного комплекса АИС неэффективно поддается документированию по объективным причинам;
5. Представление реализации всех требований к проекту, вновь внесенных в том числе, которые варьируется как добавочный ликвидный запас временного отрезка для разработки и прототипирования.

Приведенная методология позволяет спрогнозировать разностороннюю вариативность при разработки и прототипировании продукта, исходя из общего формата различных пользовательских кейсов, в том числе со стороны злоумышленник по типу: "а как бы это сделал я?". Методология позволяет предопределить возможные вариативные изменения в процессе разработки и контролировать итерационность получаемого продукта, что позволяет "бизнесу" контролировать риски, в том числе со стороны финансирования организацией. Отмечу, что приведенные принципы схожи с возможностью изменения продукта исходя из метрик при анализе для "бизнеса", что позволяет в процессе разработки контролировать все жизненные циклы и процессы версионности продукта, в том числе монетизирования. Этот формат подходит для долгосрочных продуктов, которым необходимо иметь возможность постоянной монетизации и частично быть конкурентноспособными исходя из максимизации перекрытия спроса предложением [12].

Следует предоставить и разобрать самые признанные и распространённые манифесты для представления гибкой безопасной разработки ПО, таких видов как:

1. Manifest for Agile Software Development, который был разработан с целью альтернативного решения в плане использования канонической методологии для разработки ПО и поддержания максимизации выходных параметров для продукта из ресурсов организации;
2. SCRUM реализуемая посредством создания "резервирования свойств системы", под резервом свойств понимается набор функциональных систем, которые необходимы для реализации, а функции описываются с помощью пользовательских сценарных подходов. Отличительная черта данной методологии представляется как проведение ежедневных митингов и обсуждений, которые называются stand-up, где в ходе совещания задаются каждому разработчику вопросы, такого типа:
   2.1. Что удалось выполнить для решения той или иной итерации за день?
   2.2. Какие были проблемы в моменте реализации?
   2.3. Что и как планируется сделать за сегодняшний день?
   2.4. Как происходит интеграция и оптимизация ПО в данном интервале?
   2.5. Иные виды вопросов исходя из практики организации.
3. Экстремальное программирование: eXtreme Programming, XP, которое обладает простотой решения, интенсивной разработкой малыми группами состава разработчиков, спецификой активного общения, где также "бизнес" напрямую вовлечён в процесс разработки;
4. Семейство методологий Crystal разработанная Алистером Коберном, который рассматривал процесс разработки как конечную целенаправленную игру, где утверждается, что у этой игры есть следующие цели, такие как:
   4.1. Основная цель, которая заключается в успешном закачивании разработки проектной части и внедрении в промышленную эксплуатацию;
   4.2. Вспомогательная цель, которая представляется в подготовке к следующей игре, для которой необходима определенного рода документация для разработки в виде оптимизированного и адаптированного исходного кода. Данная вариатива облегчает последующее масштабирование, а также поддержку продукта и тому подобное.
5. Адаптивная методология, под наименованием: Adaptive Software Development, ASD это альтернатива традиционного ориентирования на процессы, посредством методов управления разработкой, где результат представляется как минимизация процессов при максимальном увеличении взаимодействий между людьми. Также данная методология базируется на принципах непрерывной адаптации, где постоянные вариативные изменения в проектной части становятся нормированной практикой. В данном случае жизненный процессный цикл: "Планирование Проектирование Конструирование" изменен на более адаптивный и динамичный, такой как: "Обдумывание Взаимодействие Обучение;
6. Функционально-ориентированная разработка, под наименованием: Feature Driven Development, FDD, где та или иная функция реализовывается за две недели, если даже сценарии использования являются достаточно малыми, которые включают пять основных процессов:
   6.1. Разработка общих моделей;
   6.2. Составление списков необходимых функций для ПО;
   6.3. Планирование исполнительных работ над функциями;
   6.4. Проектирование самих функции;
   6.5. Конструирование самих функции.

Отмечу, что данные манифесты являются применимыми, но не всегда корректно, так как имеется практика введения только положительных методов из них, а не полноценного формата контроля и управления, где руководящий состав организации считает, что это будет наиболее эффективно, нежели чем процесс полноценной интеграции конкреной системы, что приводит к не корректному взаимодействию внутри команды и процесса разработки дающего только отрицательный характер влияния на "бизнес". Для безопасной разработки ПО считаются важными данные аспекты методологии, управления, разработки и проектирования, так как они позволяют решить подавляющую часть проблем связанных с рисками и инцидентами ИБ, в том числе выполнить и перекрыть требования, и рекомендации регуляторов ИБ и обезопасить конечный продукт, а также "бизнес". В том числе учитываются специалисты по PenTest, DevSecOps и так далее, так как профильные специалисты с опытом смогу предоставить ОИБ организации [13-15].

Выводы

Стоит отметить, что разработка и проектирование ПО при безопасной разработке основывается на базе функциональности ИС и совокупных сред, спроектированных относительно конечного ТТ и ТЗ. Также не мало важно понимание руководящего состава организации в обоснованности и целях безопасной разработке, где весомым показателем в данной ситуации являются оценочные метрики бизнеса в отношении рисков, которые фокусируются на целевых функциях ПО для монетизации. Данные функции разрабатываются и интерпретируются на вывод в необходимом количественном и качественном формате сведений, посредством представленных систем и подсистем в СУИБ, а не в процессе их верификационного построения.

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

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

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

P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.

Представляю вашему вниманию перевод статьи The Magical Methods in C# автора CEZARY PITEK.

Есть определенный набор сигнатур методов в C#, имеющих поддержку на уровне языка. Методы с такими сигнатурами позволяют использовать специальный синтаксис со всеми его преимуществами. Например, с их помощью можно упростить наш код или создать DSL для того, чтобы выразить решение проблемы более красивым образом. Я встречаюсь с такими методами повсеместно, так что я решил написать пост и обобщить все мои находки по этой теме, а именно:

• Синтаксис инициализации коллекций
• Синтаксис инициализации словарей
• Деконструкторы
• Пользовательские awaitable типы
• Паттерн query expression

Синтаксис инициализации коллекций

Синтаксис инициализации коллекции довольно старая фича, т. к. она существует с C# 3.0 (выпущен в конце 2007 года). Напомню, синтаксис инициализации коллекции позволяет создать список с элементами в одном блоке:

var list = new List<int> { 1, 2, 3 };

Этот код эквивалентен приведенному ниже:

var list = new List<int>();list.Add(1);list.Add(2);list.Add(3);

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

• тип имплементирует интерфейс IEnumerable
• тип имеет метод с сигнатурой void Add(T item)

public class CustomList<T>: IEnumerable{    public IEnumerator GetEnumerator() => throw new NotImplementedException();    public void Add(T item) => throw new NotImplementedException();}

Мы можем добавить поддержку синтаксиса инициализации коллекции, определив Add как метод расширения:

public static class ExistingTypeExtensions{    public static void Add<T>(ExistingType @this, T item) => throw new NotImplementedException();}

Этот синтаксис также можно использовать для вставки элементов в поле-коллекцию без публичного сеттера:

class CustomType{    public List<string> CollectionField { get; private set; }  = new List<string>();}class Program{    static void Main(string[] args)    {        var obj = new CustomType        {            CollectionField =            {                "item1",                "item2"            }        };    }}

Синтаксис инициализации коллекции полезен при инициализации коллекции известным числом элементов. Но что если мы хотим создать коллекцию с переменным числом элементов? Для этого есть менее известный синтаксис:

var obj = new CustomType{    CollectionField =    {        { existingItems }    }};

Такое возможно для типов, удовлетворяющих следующим условиям:

• тип имплементирует интерфейс IEnumerable
• тип имеет метод с сигнатурой void Add(IEnumerable<T> items)

public class CustomList<T>: IEnumerable{    public IEnumerator GetEnumerator() => throw new NotImplementedException();    public void Add(IEnumerable<T> items) => throw new NotImplementedException();}

К сожалению, массивы и коллекции из BCL не реализуют метод void Add(IEnumerable<T> items), но мы можем изменить это, определив метод расширения для существующих типов коллекций:

public static class ListExtensions{    public static void Add<T>(this List<T> @this, IEnumerable<T> items) => @this.AddRange(items);}

Благодаря этому мы можем написать следующее:

var obj = new CustomType{    CollectionField =    {        { existingItems.Where(x => /*Filter items*/).Select(x => /*Map items*/) }    }};

Или даже собрать коллекцию из смеси индивидуальных элементов и результатов нескольких перечислений (IEnumerable):

var obj = new CustomType{    CollectionField =    {        individualElement1,        individualElement2,        { list1.Where(x => /*Filter items*/).Select(x => /*Map items*/) },        { list2.Where(x => /*Filter items*/).Select(x => /*Map items*/) },    }};

Без подобного синтаксиса очень сложно получить подобный результат в блоке инициализации.

Я узнал об этой фиче совершенно случайно, когда работал с маппингами для типов с полями-коллекциями, сгенерированными из контрактов protobuf. Для тех, кто не знаком с protobuf: если вы используете grpctools для генерации типов .NET из файлов proto, все поля-коллекции генерируются подобным образом:

[DebuggerNonUserCode]public RepeatableField<ItemType> SomeCollectionField{    get    {        return this.someCollectionField_;    }}

Как можно заметить, поля-коллекции не имеют сеттер, но RepeatableField реализует метод void Add(IEnumerable items), так что мы по-прежнему можем инициализировать их в блоке инициализации:

/// <summary>/// Adds all of the specified values into this collection. This method is present to/// allow repeated fields to be constructed from queries within collection initializers./// Within non-collection-initializer code, consider using the equivalent <see cref="AddRange"/>/// method instead for clarity./// </summary>/// <param name="values">The values to add to this collection.</param>public void Add(IEnumerable<T> values){    AddRange(values);}

Синтаксис инициализации словарей

Одна из крутых фич C# 6.0 инициализация словаря по индексу, которая упростила синтаксис инициализации словарей. Благодаря ей мы можем писать более читаемый код:

var errorCodes = new Dictionary<int, string>{    [404] = "Page not Found",    [302] = "Page moved, but left a forwarding address.",    [500] = "The web server can't come out to play today."};

Этот код эквивалентен следующему:

var errorCodes = new Dictionary<int, string>();errorCodes[404] = "Page not Found";errorCodes[302] = "Page moved, but left a forwarding address.";errorCodes[500] = "The web server can't come out to play today.";

Это немного, но это определенно упрощает написание и чтение кода.

Лучшее в инициализации по индексу это то, что она не ограничивается классом Dictionary<T> и может быть использована с любым другим типом, определившим индексатор:

class HttpHeaders{    public string this[string key]    {        get => throw new NotImplementedException();        set => throw new NotImplementedException();    }}class Program{    static void Main(string[] args)    {        var headers = new HttpHeaders        {            ["access-control-allow-origin"] = "*",            ["cache-control"] = "max-age=315360000, public, immutable"        };    }}

Деконструкторы

В C# 7.0 помимо кортежей был добавлен механизм деконструкторов. Они позволяют декомпозировать кортеж в набор отдельных переменных:

var point = (5, 7);// decomposing tuple into separated variablesvar (x, y) = point;

Что эквивалентно следующему:

ValueTuple<int, int> point = new ValueTuple<int, int>(1, 4);int x = point.Item1;int y = point.Item2;

Этот синтаксис позволяет обменять значения двух переменных без явного объявления третьей:

int x = 5, y = 7;//switch(x, y) = (y,x);

Или использовать более краткий метод инициализации членов класса:

class Point{    public int X { get; }    public int Y { get; }    public Point(int x, int y)  => (X, Y) = (x, y);}

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

• метод называется Deconstruct
• метод возвращает void
• все параметры метода имеют модификатор out

Для нашего типа Point мы можем объявить деконструктор следующим образом:

class Point{    public int X { get; }    public int Y { get; }    public Point(int x, int y) => (X, Y) = (x, y);    public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);}

Пример использования приведен ниже:

var point = new Point(2, 4);var (x, y) = point;

"Под капотом" он превращается в следующее:

int x;int y;new Point(2, 4).Deconstruct(out x, out y);

Деконструкторы могут быть добавлены к типам с помощью методов расширения:

public static class PointExtensions{     public static void Deconstruct(this Point @this, out int x, out int y) => (x, y) = (@this.X, @this.Y);}

Один из самых полезных примеров применения деконструкторов это деконструкция KeyValuePair<TKey, TValue>, которая позволяет с легкостью получить доступ к ключу и значению во время итерирования по словарю:

foreach (var (key, value) in new Dictionary<int, string> { [1] = "val1", [2] = "val2" }){    //TODO: Do something}

KeyValuePair<TKey, TValue>.Deconstruct(TKey, TValue) доступно только с netstandard2.1. Для предыдущих версий netstandard нам нужно использовать ранее приведенный метод расширения.

Пользовательские awaitable типы

C# 5.0 (выпущен вместе с Visual Studio 2012) ввел механизм async/await, который стал переворотом в области асинхронного программирования. Прежде вызов асинхронного метода представлял собой запутанный код, особенно когда таких вызовов было несколько:

void DoSomething(){    DoSomethingAsync().ContinueWith((task1) => {        if (task1.IsCompletedSuccessfully)        {            DoSomethingElse1Async(task1.Result).ContinueWith((task2) => {                if (task2.IsCompletedSuccessfully)                {                    DoSomethingElse2Async(task2.Result).ContinueWith((task3) => {                        //TODO: Do something                    });                }            });        }    });}private Task<int> DoSomethingAsync() => throw new NotImplementedException();private Task<int> DoSomethingElse1Async(int i) => throw new NotImplementedException();private Task<int> DoSomethingElse2Async(int i) => throw new NotImplementedException();

Это может быть переписано намного красивее с использованием синтаксиса async/await:

async Task DoSomething(){    var res1 = await DoSomethingAsync();    var res2 = await DoSomethingElse1Async(res1);    await DoSomethingElse2Async(res2);}

Это может прозвучать удивительно, но ключевое слово await не зарезервировано только под использование с типом Task. Оно может быть использовано с любым типом, который имеет метод GetAwaiter, возвращающий удовлетворяющий следующим требованиям тип:

• тип имплементирует интерфейс System.Runtime.CompilerServices.INotifyCompletion и реализует метод void OnCompleted(Action continuation)
• тип имеет свойство IsCompleted логического типа
• тип имеет метод GetResult без параметров

Для добавления поддержки ключевого слова await к пользовательскому типу мы должны определить метод GetAwaiter, возвращающий TaskAwaiter<TResult> или пользовательский тип, удовлетворяющий приведенным выше условиям:

class CustomAwaitable{    public CustomAwaiter GetAwaiter() => throw new NotImplementedException();}class CustomAwaiter: INotifyCompletion{    public void OnCompleted(Action continuation) => throw new NotImplementedException();    public bool IsCompleted => throw new NotImplementedException();    public void GetResult() => throw new NotImplementedException();}

Вы можете спросить: "Каков возможный сценарий использования синтаксиса await с пользовательским awaitable типом?". Если это так, то я рекомендую вам прочитать статью Stephen Toub под названием "await anything", которая показывает множество интересных примеров.

Паттерн query expression

Лучшее нововведение C# 3.0 Language-Integrated Query, также известное как LINQ, предназначенное для манипулирования коллекциями с SQL-подобным синтаксисом. LINQ имеет две вариации: SQL-подобный синтаксис и синтаксис методов расширения. Я предпочитаю второй вариант, т. к. по моему мнению он более читаем, а также потому что я привык к нему. Интересный факт о LINQ заключается в том, что SQL-подобный синтаксис во время компиляции транслируется в синтаксис методов расширения, т. к. это фича C#, а не CLR. LINQ был разработан в первую очередь для работы с типами IEnumerable, IEnumerable<T> и IQuerable<T>, но он не ограничен только ими, и мы можем использовать его с любым типом, удовлетворяющим требованиям паттерна query expression. Полный набор сигнатур методов, используемых LINQ, таков:

class C{    public C<T> Cast<T>();}class C<T> : C{    public C<T> Where(Func<T,bool> predicate);    public C<U> Select<U>(Func<T,U> selector);    public C<V> SelectMany<U,V>(Func<T,C<U>> selector, Func<T,U,V> resultSelector);    public C<V> Join<U,K,V>(C<U> inner, Func<T,K> outerKeySelector, Func<U,K> innerKeySelector, Func<T,U,V> resultSelector);    public C<V> GroupJoin<U,K,V>(C<U> inner, Func<T,K> outerKeySelector, Func<U,K> innerKeySelector, Func<T,C<U>,V> resultSelector);    public O<T> OrderBy<K>(Func<T,K> keySelector);    public O<T> OrderByDescending<K>(Func<T,K> keySelector);    public C<G<K,T>> GroupBy<K>(Func<T,K> keySelector);    public C<G<K,E>> GroupBy<K,E>(Func<T,K> keySelector, Func<T,E> elementSelector);}class O<T> : C<T>{    public O<T> ThenBy<K>(Func<T,K> keySelector);    public O<T> ThenByDescending<K>(Func<T,K> keySelector);}class G<K,T> : C<T>{    public K Key { get; }}

Разумеется, мы не обязаны реализовывать все эти методы для того, чтобы использовать синтаксис LINQ с нашим пользовательским типом. Список обязательных операторов и методов LINQ для них можно посмотреть здесь. Действительно хорошее объяснение того, как это сделать, можно найти в статье Understand monads with LINQ автора Miosz Piechocki.

Подведение итогов

Цель этой статьи заключается вовсе не в том, чтобы убедить вас злоупотреблять этими синтаксическими трюками, а в том, чтобы сделать их более понятными. С другой стороны, их нельзя всегда избегать. Они были разработаны для того, чтобы их использовать, и иногда они могут сделать ваш код лучше. Если вы боитесь, что получившийся код будет непонятен вашим коллегам, вам нужно найти способ поделиться знаниями с ними (или хотя бы ссылкой на эту статью). Я не уверен, что это полный набор таких "магических методов", так что если вы знаете еще какие-то пожалуйста, поделитесь в комментариях.