Матрица компетенций для IT специалиста

Матрица пользователя : kkosasfaa

  • Заполненных тем 9
  • Заполненных навыков 17
  • Paradigms Search Auth mysql PHP Design-Pattern Бизнес-анализ API CSS
  • 475
  • 2024-12-08 12:20:36
  • DDD
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.

    Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. domain-driven design, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.

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

    Основные определения

    Область (англ. domain) — предметная область, для которой разрабатывается программное обеспечение.
Модель (англ. model) — описывает отдельные аспекты области и может быть использована для решения проблемы.
Язык описания — используется для единого стиля описания домена и модели.

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

    Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»

    Элементы DDD

    При проектировании на основе предметно-ориентированного подхода используются следующие понятия: Ограниченный контекст

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

    клиентская база
система безопасности и защиты
резервное копирование
взаимодействие с платежными системами
ведение отчётности
администрирование
система уведомлений

    Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают архитектурный стиль, который имеет красноречивое название «Большой ком грязи» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).[2]

    Сутью предметно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках. Сущность

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

    Объект-значение — это свойства, важные в той предметной области, которую вы моделируете. У них, в отличие от сущностей, нет обозначения; они просто описывают конкретные сущности, которые уже имеют обозначения. Полезность объектов-значений состоит в том, что они описывают свойства сущностей гораздо более изящным и объявляющим намерения способом. Стоит всегда помнить, что значение объекта никогда не изменяется на протяжении выполнения всего программного кода. После их создания, внесение поправок невозможно. Агрегат

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

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

    https://ru.wikipedia.org/wiki/Предметно-ориентированное_проектирование

  • Императивное программирование
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.

    Императи́вное программи́рование — парадигма программирования (стиль написания исходного кода компьютерной программы), для которой характерно следующее:

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

    https://ru.wikipedia.org/wiki/Императивное_программирование

  • Функциональное программирование
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.

    Функциона́льное программи́рование — парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).

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

    https://ru.wikipedia.org/wiki/Функциональное_программирование

  • Принципы ООП
    • Джун: Может объяснить базовые принципы.
    • Мидл: Разбирается в принципах ООП.
    • Синьор: Может на лафкодинге показать пример принципов ООП.

    Принципы:

    • Абстракция
    • Инкапсуляция
    • Наследование (Делегация, Композиция, Агрегация)
    • Полиморфизм

    Знания на сеньора:

    • Динамическое связывание методов
    • Динамическое создание и уничтожение объектов
    • Значительная глубина абстракции
    • Наследование «размывает» код
    • Инкапсуляция снижает скорость доступа к данным

    https://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование

  • Двоичный (бинарный) поиск
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.

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

    Ищет элемент в отсортированном массиве:

    Определение значения элемента в середине структуры данных. Полученное значение сравнивается с ключом.
Если ключ меньше значения середины, то поиск осуществляется в первой половине элементов, иначе — во второй.
Поиск сводится к тому, что вновь определяется значение серединного элемента в выбранной половине и сравнивается с ключом.
Процесс продолжается до тех пор, пока не будет найден элемент со значением ключа или не станет пустым интервал для поиска.
  • Троичный (Тернарный) поиск
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.

    Трои́чный по́иск (Тернарный поиск) — это метод в информатике для поиска максимумов и минимумов функции, которая либо сначала строго возрастает, затем строго убывает, либо наоборот. Троичный поиск определяет, что минимум или максимум не может лежать либо в первой, либо в последней трети области, и затем повторяет поиск на оставшихся двух третях. Троичный поиск демонстрирует парадигму программирования «разделяй и властвуй».

    /**
Находит максимум функции с одним экстремумом между l и r.
Чтобы найти минимум - достаточно поменять местами действия в ветках if/else.
*/
double l = ..., r = ..., EPS = ...; // входные данные
double m1, m2;
while (r - l > EPS) {
   m1 = l + (r - l) / 3;
   m2 = r - (r - l) / 3;
   if (f (m1) < f (m2))
      l = m1;
   else
      r = m2;
}

    https://ru.wikipedia.org/wiki/Троичный_поиск

  • Типы данных PHP
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
    • Атомарные
    • Составные
    • Пересечение
    • Объединение
    • Псевдонимы

    https://www.php.net/manual/ru/language.types.type-system.php

  • Псевдо-классы
    • Знаю: Знаю что это, читал/изучал.

    псевдо-классы

  • Оформление ТЗ.
    • Знаю: Знаю что это, читал/изучал.
    • Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.

    Способен выполнить полный цикл бизнес-анализа, включая адекватное управление требованиями