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

Профессиональные навыки

- Принципы/методы программирования

- - ООП

- Методы WEB авторизации

- Клиент-серверное и межсервисное взаимодействие

- Методологии разработки

- Патерны разработки

- - Основные шаблоны проектирования

- - Архитектурные патерны

- - ORM

- Антипаттерны

- - Архитектурные антипаттерны

- - Антипаттерны при написании кода

- - Антипаттерны в ООП

- Алгоритмы и структуры данных

- - Основы алгоритмов

- - Cтруктуры данных

- - Сортировки массивов

- - Алгоритмы поиска

- - Криптография

- Методы тестирования

- CI/CD инструменты

- - Docker

- Базы данных и очередей

- - Основы проектирования БД

- - Транзакции

- - MySQL

- PHP

- - Фреймворки

- - Библиотеки/Инструменты

- Frontend

- - Javascript

- - - VueJS

- - CSS

- - - CSS фреймворки

- Сетевые протоколы (IP, Transport, etc)

Мягкие навыки

- Навыки общения и социализации

- Владение языками

- Методы достижения целей

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

Заполненных тем 35
Заполненных навыков 148
sql Data PHP docker php-vendors Сеть Paradigms frontend Search VueJS
2865
2024-12-06 20:36:04

Скачать PDF

Профессиональные навыки:

Hard skills

Проекты и сервисы:

Пет проекты и сервисы

Принципы/методы программирования:

https://ru.wikipedia.org/wiki/Парадигма_программирования

Не знаю Знаю YAGNI

Знаю: Знаю что это, читал/изучал.

AGNI («You aren't gonna need it»; с англ. — «Вам это не понадобится») — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.

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

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

https://ru.wikipedia.org/wiki/YAGNI

Не знаю Знаю Понимаю TDD
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (англ. inspires confidence).

Преимущества

Исследование 2005 года показало, что использование разработки через тестирование предполагает написание большего количества тестов, в свою очередь, программисты, пишущие больше тестов, склонны быть более продуктивными.[5] Гипотезы, связывающие качество кода с TDD, были неубедительны.[6]

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

Разработка через тестирование предлагает больше, чем просто проверку корректности, она также влияет на дизайн программы. Изначально сфокусировавшись на тестах, проще представить, какая функциональность необходима пользователю. Таким образом, разработчик продумывает детали интерфейса до реализации. Тесты заставляют делать свой код более приспособленным для тестирования. Например, отказываться от глобальных переменных, одиночек (singletons), делать классы менее связанными и легкими для использования. Сильно связанный код или код, который требует сложной инициализации, будет значительно труднее протестировать. Модульное тестирование способствует формированию четких и небольших интерфейсов. Каждый класс будет выполнять определенную роль, как правило, небольшую. Как следствие, зацепление между классами будут снижаться, а связность повышаться. Контрактное программирование (англ. design by contract) дополняет тестирование, формируя необходимые требования через утверждения (англ. assertions).

Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше. Тесты защищают от ошибок. Поэтому время, затрачиваемое на отладку, снижается многократно.[8] Большое количество тестов помогает уменьшить количество ошибок в коде. Устранение дефектов на более раннем этапе разработки, препятствует появлению хронических и дорогостоящих ошибок, приводящих к длительной и утомительной отладке в дальнейшем.

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

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

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

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

Слабые места
```
Существуют задачи, которые невозможно (по крайней мере, на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность разработанного кода в области безопасности данных и взаимодействия между процессами. Безусловно, безопасность основана на коде, в котором не должно быть дефектов, однако она основана также на участии человека в процедурах защиты данных. Тонкие проблемы, возникающие в области взаимодействия между процессами, невозможно с уверенностью воспроизвести, просто запустив некоторый код.
Разработку через тестирование сложно применять в тех случаях, когда для тестирования необходимо прохождение функциональных тестов. Примерами может быть: разработка интерфейсов пользователя, программ, работающих с базами данных, а также того, что зависит от специфической конфигурации сети. Разработка через тестирование не предполагает большого объёма работы по тестированию такого рода вещей. Она сосредотачивается на тестировании отдельно взятых модулей, используя mock-объекты для представления внешнего мира.
Требуется больше времени на разработку и поддержку, а одобрение со стороны руководства очень важно. Если у организации нет уверенности в том, что разработка через тестирование улучшит качество продукта, то время, потраченное на написание тестов, может рассматриваться как потраченное впустую.[9]
Модульные тесты, создаваемые при разработке через тестирование, обычно пишутся теми же, кто пишет тестируемый код. Если разработчик неправильно истолковал требования к приложению, и тест, и тестируемый модуль будут содержать ошибку.
Большое количество используемых тестов может создать ложное ощущение надежности, приводящее к меньшему количеству действий по контролю качества.
Тесты сами по себе являются источником накладных расходов. Плохо написанные тесты, например, содержат жёстко вшитые строки с сообщениями об ошибках или подвержены ошибкам, дороги при поддержке. Чтобы упростить поддержку тестов, следует повторно использовать сообщения об ошибках из тестируемого кода.
Уровень покрытия тестами, получаемый в результате разработки через тестирование, не может быть легко получен впоследствии. Исходные тесты становятся всё более ценными с течением времени. Если неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.
```
Видимость кода

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

Из кода теста может не быть доступа к приватным (англ. private) полям и методам. Поэтому при модульном тестировании может потребоваться дополнительная работа. В Java разработчик может использовать отражение (англ. reflection), чтобы обращаться к полям, помеченными как приватные.[10] Модульные тесты можно реализовать во внутренних классах, чтобы они имели доступ к членам внешнего класса. В .NET Framework могут применяться разделяемые классы (англ. partial classes) для доступа из теста к приватным полям и методам.

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

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

Fake-, mock-объекты и интеграционные тесты

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

Когда разрабатываемый код использует базы данных, веб-сервисы или другие внешние процессы, имеет смысл выделить покрываемую тестированием часть. Это делается в два шага:
```
Везде, где требуется доступ к внешним ресурсам, должен быть объявлен интерфейс, через который этот доступ будет осуществляться. См. принцип инверсии зависимостей (англ. dependency inversion) для обсуждения преимуществ этого подхода независимо от TDD.
Интерфейс должен иметь две реализации. Первая, собственно предоставляющая доступ к ресурсу, и вторая, являющаяся fake- или mock-объектом. Всё, что делают fake-объекты, это добавляют сообщения вида «Объект person сохранен» в лог, чтобы потом проверить правильность поведения. Mock-объекты отличаются от fake- тем, что сами содержат утверждения (англ. assertion), проверяющие поведение тестируемого кода. Методы fake- и mock-объектов, возвращающие данные, можно настроить так, чтобы они возвращали при тестировании одни и те же правдоподобные данные. Они могут эмулировать ошибки так, чтобы код обработки ошибок мог быть тщательно протестирован. Другими примерами fake-служб, полезными при разработке через тестирование, могут быть: служба кодирования, которая не кодирует данные, генератор случайных чисел, который всегда выдает единицу. Fake- или mock-реализации являются примерами внедрения зависимости (англ. dependency injection).
```
Использование fake- и mock-объектов для представления внешнего мира приводит к тому, что настоящая база данных и другой внешний код не будут протестированы в результате процесса разработки через тестирование. Чтобы избежать ошибок, необходимы тесты реальных реализаций интерфейсов, описанных выше. Эти тесты могут быть отделены от остальных модульных тестов и реально являются интеграционными тестами. Их необходимо меньше, чем модульных, и они могут запускаться реже. Тем не менее, чаще всего они реализуются используя те же библиотеки для тестирования (англ. testing framework), что и модульные тесты.

Интеграционные тесты, которые изменяют данные в базе данных, должны откатывать состоянии базы данных к тому, которое было до запуска теста, даже если тест не прошёл. Для этого часто применяются следующие техники:
```
Метод TearDown, присутствующий в большинстве библиотек для тестирования.
try...catch...finally структуры обработки исключений, там где они доступны.
Транзакции баз данных.
Создание снимка (англ. snapshot) базы данных перед запуском тестов и откат к нему после окончания тестирования.
Сброс базы данных в чистое состояние перед тестом, а не после них. Это может быть удобно, если интересно посмотреть состояние базы данных, оставшееся после не прошедшего теста.
```
Существуют библиотеки Moq, jMock, NMock, EasyMock, Typemock, jMockit, Unitils, Mockito, Mockachino, PowerMock или Rhino Mocks, а также sinon для JavaScript предназначенные упростить процесс создания mock-объектов.

https://ru.wikipedia.org/wiki/Разработка_через_тестирование
Не знаю Знаю Понимаю 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/Предметно-ориентированное_проектирование
Не знаю Знаю Понимаю GRASP
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Каталог шаблонов
1. Информационный эксперт (Information Expert)
2. Создатель (Creator)
3. Контроллер (Controller)
4. Слабое (низкое) зацепление (Low Coupling)
5. Сильная (высокая) связность (High Cohesion)
6. Полиморфизм (Polymorphism)
7. Чистая выдумка (Pure Fabrication)
8. Перенаправление (Indirection)
9. Устойчивость к изменениям (Protected Variations)
10. Информационный эксперт (Information Expert)
Шаблон определяет базовый принцип распределения ответственностей. Обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом.

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

Локализация же ответственностей, проводимая согласно шаблону:
```
Повышает:
    Инкапсуляцию;
    Простоту восприятия;
    Готовность компонентов к повторному использованию;
Снижает:
    степень зацепления.
```
1. Создатель (Creator)
Проблема: Кто отвечает за создание объекта некоторого класса A?

Решение: Назначить классу B обязанность создавать объекты класса A, если класс B:
```
содержит(contains) или агрегирует(aggregate) объекты A;
записывает(records) объекты A;
активно использует объекты A;
обладает данными для инициализации объектов A
```
Можно сказать, что шаблон «Creator» — это интерпретация шаблона «Information Expert» (смотрите пункт № 1) в контексте создания объектов.

Большинство порождающих шаблонов проектирования так или иначе выводятся или опираются на шаблон «Creator».
1. Контроллер (Controller)
  
  Отвечает за операции, запросы которых приходят от пользователя, и может выполнять сценарии одного или нескольких вариантов использования (например, создание и удаление); Не выполняет работу самостоятельно, а делегирует компетентным исполнителям; Может представлять собой: Систему в целом; Подсистему; Корневой объект; Устройство.
2. Слабое (низкое) зацепление (Low Coupling) Основная статья: Зацепление (программирование)
Зацепление — мера того, насколько взаимозависимы разные подпрограммы или модули[2].

Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы.
1. Сильная (высокая) связность (High Cohesion) Основная статья: Связность (программирование)
Связность — мера силы взаимосвязанности элементов внутри модуля; способ и степень, в которой задачи, выполняемые некоторым программным модулем, связаны друг с другом[2].

Сильная связность класса / модуля означает, что его элементы тесно связаны и сфокусированы.

Слабая (низкая) связность класса / модуля означает, что он не сфокусирован на одной цели, его элементы предназначены для слишком многих несвязанных обязанностей. Такой модуль трудно понять, использовать и поддерживать.
1. Полиморфизм (Polymorphism) См. также: Полиморфизм (информатика)
Устройство и поведение системы:
```
Определяется данными;
Задано полиморфными операциями её интерфейса.
```
Пример: Адаптация коммерческой системы к многообразию систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (см. также: Шаблон «Адаптеры»).
1. Чистая выдумка (Pure Fabrication)
Не относится к предметной области, но:
```
Уменьшает зацепление;
Повышает связность;
Упрощает повторное использование.
```
«Pure Fabrication» отражает концепцию сервисов в модели предметно-ориентированного проектирования.

Пример задачи: Не используя средства класса «А», внести его объекты в базу данных.

Решение: Создать класс «Б» для записи объектов класса «А» (см. также: «Data Access Object»).
1. Перенаправление (Indirection) См. также: Посредник (шаблон проектирования)
Слабое зацепление между элементами системы (и возможность повторного использования) обеспечивается назначением промежуточного объекта их посредником.

Пример: В архитектуре Model-View-Controller, контроллер (англ. controller) ослабляет зацепление данных (англ. model) с их представлением (англ. view).
1. Устойчивость к изменениям (Protected Variations) Шаблон защищает элементы от изменения другими элементами (объектами или подсистемами) с помощью вынесения взаимодействия в фиксированный интерфейс, через который (и только через который) возможно взаимодействие между элементами. Поведение может варьироваться лишь через создание другой реализации интерфейса.
https://ru.wikipedia.org/wiki/GRASP https://habr.com/ru/articles/92570/
Не знаю Знаю Понимаю Императивное программирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Императи́вное программи́рование — парадигма программирования (стиль написания исходного кода компьютерной программы), для которой характерно следующее:
- в исходном коде программы записываются инструкции (команды);
- инструкции должны выполняться последовательно;
- данные, получаемые при выполнении предыдущих инструкций, могут читаться из памяти последующими инструкциями;
- данные, полученные при выполнении инструкции, могут записываться в память.
https://ru.wikipedia.org/wiki/Императивное_программирование
Не знаю Знаю Понимаю Функциональное программирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Функциона́льное программи́рование — парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).

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

https://ru.wikipedia.org/wiki/Функциональное_программирование
Не знаю Знаю Понимаю Закон Деметры
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/Закон_Деметры

Методы WEB авторизации:

https://habr.com/ru/companies/dataart/articles/262817/

https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc?permalink_comment_id=4823694

Не знаю Знаю Понимаю Cookie/Session
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://htmlacademy.ru/blog/php/sessions-cookies
Не знаю Знаю Понимаю OpenAuth
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/OAuth
Не знаю Знаю Понимаю JWT
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://www.tester-today.com/jwt-authorization

Клиент-серверное и межсервисное взаимодействие:

https://habr.com/ru/articles/729528/

Не знаю Знаю Понимаю OpenAPI
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/OpenAPI_(спецификация)
Не знаю Знаю Понимаю UML
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/UML

Патерны разработки:

https://refactoring.guru/ru/design-patterns

Архитектурные патерны:

Шаблоны используемы в построении архитектуры

Не знаю Джун Мидл Сеньор SOA
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Се́рвис-ориенти́рованная архитекту́ра (СОА, англ. service-oriented architecture- SOA) — модульный подход к разработке программного обеспечения, базирующийся на обеспечении удаленного использования по стандартизированным протоколам распределённых, слабо связанных[англ.], легко заменяемых компонентов (сервисов) со стандартизированными интерфейсами.

Программные комплексы, разработанные в соответствии с СОА, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

https://ru.wikipedia.org/wiki/Сервис-ориентированная_архитектура https://habr.com/ru/companies/vk/articles/342526/
Не знаю Знаю Понимаю CQRS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/CQRS
Не знаю Знаю Понимаю MVC
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.
```
Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.
Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели.
Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.
```
https://ru.wikipedia.org/wiki/Model-View-Controller
Не знаю Знаю Понимаю Локатор служб
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/Локатор_служб
Не знаю Знаю Понимаю Domain layer
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Domain layer — модель бизнес-логики приложения. В идеале вся бизнес логика(понятия и операции которым оперирует бизнес) должна находиться в этом слое. Задача остальных слоев, это инкапсуляция бизнес логики от объектов реального мира(бд, сети, файлов, пользователей, и т.д).
Не знаю Знаю Понимаю Application/service layer
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Слой ответственный за "связь" доменной модели и инфраструктурными сервисами. Никакие другие классы, кроме классов данного слоя не могут дергать объекты доменного. В терминологии Фаулера, называется service layer.
Не знаю Знаю Понимаю Infrastructure layer
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Инфраструктурный слой, содержащий всё необходимое для общения приложения с внешним миром(пользователями, сторонними сервисами, железом и т.д). быстро может стать очень жирным. Как я уже говорил, обычно, этот код сложен и нестабилен. Инфраструктурный код соединяет ядро нашего драгоценного приложения с:

Файловой системой Сетью Орм Фреймворком Сторонними библиотеками

Очень важно понимать что здесь не может быть НИКАКОЙ бизнес логики.
Не знаю Знаю Понимаю Saga
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Шаблон “Saga” используется для моделирования long-running (Как это будет по-русски? Долгосрочные? Долгоиграющие?) бизнес-процессов. Фактически, мы можем сказать, что Saga представляет собой Workflow для какого-то определённого сценария.

Long-running не следует понимать в терминах секундной стрелки и задаваться вопросом: 200 миллисекунд – это long-running или нет? В системах с архитектурой, построенной на событиях и сообщениях подобные вопросы вряд ли имеют смысл.

Идея, которую реализует шаблон “Saga” проста: после каждого успешно выполненного шага мы имеем некоторое состояние, с которого можно будет продолжить исполнение процесса. Шагом является выполнение какого-то действия, реакция на какое-то событие и т.д. То есть, если мы не смогли подтвердить транзакцию в базу данных, или если вызов второго веб-сервиса завершился неудачей, у нас имеется состояние, валидное на момент до его вызова. Наш бизнес-процесс остановлен – это да, но он и не потерян. Мы можем предпринять какие-то действия и продолжить процесс. Как результат – процесс просто выполнялся дольше.

Кроме того, имея такое состояние, мы можем легко моделировать процессы, “управляемые” событиями!

Антипаттерны:

https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD

Архитектурные антипаттерны:

https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD

Не знаю Знаю Большой комок грязи
- Знаю: Знаю что это, читал/изучал.
Big ball of mud: Система с нераспознаваемой структурой.

Организационные антипаттерны:

https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD

Антипаттерны в ООП:

https://ru.wikipedia.org/wiki/Антипаттерн

Не знаю Знаю Anemic Domain Model
- Знаю: Знаю что это, читал/изучал.
Anemic Domain Model: боязнь размещать логику в объектах предметной области.
Не знаю Знаю Божественный объект
- Знаю: Знаю что это, читал/изучал.
God object: Концентрация слишком большого количества функций в одной части системы (классе).

Алгоритмы и структуры данных:

https://proglib.io/tests/proydi-test-na-znanie-algoritmov-i-struktur-dannyh

https://backendinterview.ru/algostruct/index.html

Основы алгоритмов:

https://education.yandex.ru/handbook/algorithms https://apptractor.ru/info/articles/6-algoritmov-kotorye-dolzhen-znat-kazhdyy-razrabotchik.html https://codechick.io/tutorials/dsa/dsa-algorithm

Не знаю Знаю Понимаю Асимптотический анализ / Сложность
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Асимптотический анализ показывает порядок роста алгоритма - как увеличивается время работы алгоритма при увеличении объема входных данных. По факту измеряем не время, а число операций, например - сравнения,присваивания,выделение памяти. Обычно измеряется наихудший случай выполнения, если не оговорено иное. Записывается, как O(n) (О нотация, О большое) . Примеры:
```
Константный — O(1)
Линейный — O(n)
Логарифмический — O( log n)
Линеарифметический — O(n·log n)
Квадратичный — O(n 2)
И другие
```
https://education.yandex.ru/handbook/algorithms/article/algoritmy-i-slozhnost
Не знаю Знаю Понимаю Рекурсия
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Рекурсия – это когда функция вызывает сама себя(напрямую или через функцию посредника), как правило, с другими аргументами. Рекурсия помогает писать код более компактно и понятно, однако имеет оверхэд по памяти из-за необходимости хранить стек вызова. Для оптимизации можно переписать алгоритм используя циклы - любая рекурсия может быть переделана в цикл, как правило, вариант с циклом будет эффективнее. Также есть хвостовая рекурсия.

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

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

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

Cтруктуры данных:

https://algolist.manual.ru/ds/index.php

https://backendinterview.ru/algostruct/structBasics.html

Не знаю Знаю Понимаю Хэш-таблица (Hash Table)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Структура данных, основанная на хэш-функции, которая преобразует ключ в индекс массива для хранения значения.

Преимущества:
- Быстрый доступ, вставка и удаление элементов (в среднем O(1))
- Гибкость структуры
Недостатки:
- Возможность коллизий хэш-функции
- Затраты памяти на хранение элементов и обработку коллизий
Применение:
- Хэш-таблицы используются в поисковых алгоритмах, кэшировании данных, реализации ассоциативных массивов и словарей.
https://backendinterview.ru/algostruct/hashTable.html
Не знаю Знаю Понимаю Стэк(Stack)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Cтруктура данных, организованная по принципу "последний пришел, первый ушел" (LIFO). Элементы добавляются и удаляются с одного конца структуры.

Преимущества:
- Простота реализации
- Легкость использования в рекурсии и отката операций
Недостатки:
- Ограниченный доступ к элементам (только к вершине стека)
Применение:
- Стеки полезны при выполнении рекурсивных функций, обработке скобочных последовательностей и отмене операций.
https://codechick.io/tutorials/dsa/dsa-stack
Не знаю Знаю Понимаю Очередь (Queue)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Структура данных, организованная по принципу "первый пришел, первый ушел" (FIFO). Элементы добавляются в конец очереди и удаляются из начала.

Преимущества:
- Поддержка естественного порядка обработки элементов
- Применение в алгоритмах обхода и поиска
Недостатки:
- Ограниченный доступ к элементам (только к началу и концу очереди)
Применение:
- Очереди используются в алгоритмах обхода в ширину, приоритетных очередях и многопоточных приложениях для обработки задач.
Виды:
- Простая очередь
- Круговая очередь
- Очередь с приоритетом
- Двухсторонняя очередь https://codechick.io/tutorials/dsa/dsa-queue
Не знаю Знаю Понимаю Связанный список (Linked List)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Связанный список - это структура данных, состоящая из узлов, каждый из которых содержит значение элемента и указатель на следующий узел в списке.

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

Преимущества:
- Динамическое изменение размера списка (в отличие от массивов)
- Эффективное добавление и удаление элементов в начале или конце списка
- Относительно простая реализация
Недостатки:
- Непостоянное время доступа к элементам (в отличие от массивов)
- Больший объем занимаемой памяти по сравнению с массивами из-за хранения указателей на узлы
Применение:
- Связанные списки подходят для реализации стеков, очередей, а также для задач, где требуется частое добавление или удаление элементов и не требуется быстрый доступ к элементам по индексу.
Не знаю Джун Мидл Сеньор Граф (Graph)
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Структура данных, состоящая из вершин (узлов) и ребер, которые соединяют эти вершины. Графы могут быть ориентированными (направленными) или неориентированными.

Преимущества:
- Отражение сложных отношений между элементами
- Гибкость структуры
Недостатки:
- Сложность реализации и обработки
- Большие затраты памяти
Применение:
- в транспортных сетях
- социальных сетях
- веб-технологиях
- задачи оптимизации
https://backendinterview.ru/algostruct/graph.html
Не знаю Знаю Понимаю Куча (Heap)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Куча (структура данных) — это полное двоичное дерево, удовлетворяющее свойству кучи: если узел A — это родитель узла B, то ключ узла A ≥ ключ узла B.
- Если любой узел всегда больше дочернего узла (узлов), а ключ корневого узла является наибольшим среди всех остальных узлов, это max-куча.
- Если любой узел всегда меньше дочернего узла (узлов), а ключ корневого узла является наименьшим среди всех остальных узлов, это min-куча.
Не знаю Знаю Понимаю Массивы (Arrays)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Массивы – это простейшая структура данных, представляющая собой набор элементов одного типа, расположенных последовательно в памяти. Хранит набор значений (элементов массива), идентифицируемых по индексу или набору индексов, принимающих целые (или приводимые к целым) значения из некоторого заданного непрерывного диапазона.

Преимущества:
```
Быстрый доступ к элементам по индексу
Непрерывная область памяти
```
Недостатки:
```
Фиксированный размер
Неэффективное добавление/удаление элементов
```
Применение: Массивы подходят для хранения набора данных с фиксированным размером, где операции вставки и удаления элементов не требуются.

https://backendinterview.ru/algostruct/array.html
Не знаю Знаю Понимаю Двоичное дерево
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Двоичное дерево — древовидная структура данных, в которой у родительских узлов не может быть больше двух детей.

Типы двоичных деревьев
- Полное двоичное дерево — особый тип бинарных деревьев, в котором у каждого узла либо 0 потомков, либо 2.
- Совершенное двоичное дерево — особый тип бинарного дерева, в котором у каждого внутреннего узла по два ребенка, а листовые вершины находятся на одном уровне.
- Законченное двоичное дерево похоже на совершенное, но есть три большие отличия.
  - Все уровни должны быть заполнены.
  - Все листовые вершины склоняются влево.
  - У последней листовой вершины может не быть правого собрата. Это значит, что завершенное дерево необязательно полное.
- Вырожденное двоичное дерево — дерево, в котором на каждый уровень приходится по одной вершине.
- Скошенное вырожденное дерево — вырожденное дерево, в котором есть либо только левые, либо только правые узлы. Таким образом, есть два типа скошенных деревьев — скошенные влево вырожденные деревья и скошенные вправо вырожденные деревья.
- Сбалансированное двоичное дерево — тип бинарного дерева, в котором у каждой вершины количество вершин в левом и правом поддереве различаются либо на 0, либо на 1.
Не знаю Знаю Понимаю Дерево двоичного поиска
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Дерево двоичного поиска — это структура данных, которая позволяет быстро работать с отсортированном списком чисел.

Дерево двоичное, потому что у каждого узла не более двух дочерних элементов.

Дерево поиска, потому что его можно использовать для проверки вхождения числа — за время O(log(n)).

Чем отличается от обычного двоичного дерева
```
Все узлы левого поддерева меньше корневого узла.
Все узлы правого поддерева больше корневого узла.
Оба поддерева каждого узла тоже являются деревьями двоичного поиска, т. е. также обладают первыми двумя свойствами.
```
У правого дерева есть поддерево со значением 2, которое меньше, чем корень 3 — таким дерево двоичного поиска быть не может.
Не знаю Знаю Понимаю B-дерево
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
B-дерево (читается как Би-дерево) — это особый тип сбалансированного дерева поиска, в котором каждый узел может содержать более одного ключа и иметь более двух дочерних элементов. Из-за этого свойства B-дерево называют сильноветвящимся.

Зачем нужно

Вторичные запоминающие устройства (жесткие диски, SSD) медленно работают с большим объемом данных. Людям захотелось сократить время доступа к физическим носителям информации, поэтому возникла потребность в таких структурах данных, которые способны это сделать.

Двоичное дерево поиска, АВЛ-дерево, красно-черное дерево и т. д. могут хранить только один ключ в одном узле. Если нужно хранить больше, высота деревьев резко начинает расти, из-за этого время доступа сильно увеличивается.

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

Свойства
- Ключи в каждом узле x упорядочены по неубыванию.
- В каждом узле есть логическое значение x.leaf. Оно истинно, если x — лист.
- Каждый узел, кроме корня, содержит не менее t-1 ключей, а каждый внутренний узел имеет как минимум t дочерних узлов, где t — минимальная степень B-дерева.
- Все листья находятся на одном уровне, т. е. обладают одинаковой глубиной, равной высоте дерева.
- Корень имеет не менее 2 дочерних элементов и содержит не менее 1 ключа.
Не знаю Знаю Понимаю АВЛ-дерево
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
сбалансированное по высоте двоичное дерево поиска: для каждой его вершины высота её двух поддеревьев различается не более чем на 1.

Алгоритмы поиска:

https://backendinterview.ru/algostruct/graph.html https://backendinterview.ru/algostruct/index.html

Не знаю Знаю Понимаю Двоичный (бинарный) поиск

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

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

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

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

Не знаю Знаю Понимаю Поиск в ширину (BFS)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Поиск в ширину(Breadth-First Search, BFS) — это один из основных алгоритмов на графах. В результате поиска в ширину находится путь кратчайшей длины в невзвешенном графе, т.е. путь, содержащий наименьшее число рёбер. Например, если мы ищем на карте метро путь от Сокольников, до Парка Победы, содержащий наименьшее число станций, то мы ищем в ширину.

BFS следует концепции «расширяйся, поднимаясь на высоту птичьего полета» («go wide, bird’s eye-view»). Вместо того чтобы двигаться по определенному пути до конца, BFS предполагает движение вперед по одному соседу за раз.
Не знаю Знаю Понимаю Поиск в глубину (DFS)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Поиск в глубину(Depth-First Search, DFS) находит такой путь от данной вершины, до нужной, что этот путь содержит минимальную сумму ребер графа. Например, если мы ищем на карте метро путь от Сокольников, до Парка Победы, требующий наименьшее время для переезда(расстояние между каждыми соседними станциями, будет весом ребра), то мы ищем в глубину.

DFS следует концепции «погружайся глубже, головой вперед» («go deep, head first»). Идея заключается в том, что мы двигаемся от начальной вершины (точки, места) в определенном направлении (по определенному пути) до тех пор, пока не достигнем конца пути или пункта назначения (искомой вершины). Если мы достигли конца пути, но он не является пунктом назначения, то мы возвращаемся назад (к точке разветвления или расхождения путей) и идем по другому маршруту.
Не знаю Знаю Понимаю Алгори́тм Де́йкстры
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Алгори́тм Де́йкстры (Dijkstra’s algorithm) — алгоритм на графах, изобретённый нидерландским учёным Эдсгером Дейкстрой в 1959 году. Находит кратчайшие пути от одной из вершин графа до всех остальных. Алгоритм работает только для графов без рёбер отрицательного веса.

Каждой вершине из V сопоставим метку — минимальное известное расстояние от этой вершины до a. Алгоритм работает пошагово — на каждом шаге он «посещает» одну вершину и пытается уменьшать метки. Работа алгоритма завершается, когда все вершины посещены.

Инициализация. Метка самой вершины a полагается равной 0, метки остальных вершин — бесконечности. Это отражает то, что расстояния от a до других вершин пока неизвестны. Все вершины графа помечаются как не посещённые.

Шаг алгоритма. Если все вершины посещены, алгоритм завершается. В противном случае из ещё не посещённых вершин выбирается вершина u, имеющая минимальную метку. Мы рассматриваем всевозможные маршруты, в которых u является предпоследним пунктом. Вершины, в которые ведут рёбра из u, назовём соседями этой вершины. Для каждого соседа вершины u, кроме отмеченных как посещённые, рассмотрим новую длину пути, равную сумме значений текущей метки u и длины ребра, соединяющего u с этим соседом. Если полученное значение длины меньше значения метки соседа, заменим значение метки полученным значением длины. Рассмотрев всех соседей, пометим вершину u как посещённую и повторим шаг алгоритма.
Не знаю Знаю Понимаю Задача о рюкзаке
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Задача о рюкзаке (также задача о ранце) — NP-полная задача комбинаторной оптимизации. Своё название получила от конечной цели: уложить как можно большее число ценных вещей в рюкзак при условии, что вместимость рюкзака ограничена. С различными вариациями задачи о рюкзаке можно столкнуться в экономике, прикладной математике, криптографии и логистике.

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

https://ru.wikipedia.org/wiki/Задача_о_рюкзаке

Алгоритм балансировки нагрузки:

https://habr.com/ru/companies/otus/articles/770248/ https://habr.com/ru/companies/otus/articles/782064/ https://habr.com/ru/companies/ruvds/articles/732648/

Криптография:

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

https://backendinterview.ru/algostruct/crypto.html

Не знаю Знаю Понимаю Хеширование/Соль
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Преобразование входного массива данных произвольной длины в выходную битовую строку фиксированной длины. Такие преобразования также называются хеш-функциями или функциями свёртки, а их результаты называют хеш-кодом, контрольной суммой или дайджестом сообщения (англ. message digest). Результаты хеширования статистически уникальны. Последовательность, отличающаяся хотя бы одним байтом, не будет преобразована в то же самое значение.

https://backendinterview.ru/algostruct/hashTable.html

Методы тестирования:

https://habr.com/ru/articles/549054/ https://habr.com/ru/articles/587620/ https://xbsoftware.ru/blog/metodologii-testirovaniya-po-kakuyu-vybrat/

Не знаю Джун Мидл Сеньор Модульные тесты
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Модульное тестирование (Unit Testing) – это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения. Его цель заключается в том, чтобы проверить, что каждая единица программного кода работает должным образом. Данный вид тестирование выполняется разработчиками на этапе кодирования приложения. Модульные тесты изолируют часть кода и проверяют его работоспособность. Единицей для измерения может служить отдельная функция, метод, процедура, модуль или объект.

https://logrocon.ru/news/unit_testing

CI/CD инструменты:

Технологии используемые в разработке для развертывания и деплоя

Kubernetes:

https://habr.com/ru/articles/258443/ https://kubernetes.io/ru/docs/concepts/overview/what-is-kubernetes/

Сервисы и инструменты:

Сервисы метрик и логирования

Базы данных и очередей:

Базы данны SQL, NoSQL и сервисы очередей

Не знаю Знаю Понимаю Redis
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
- Строка (String)
- Битовый массив (Bitmap)
- Битовое поле (Bitfield)
- Хеш-таблица (Hash)
- Список (List)
- Множество (Set)
- Упорядоченное множество (Sorted set)
- Геопространственные данные (Geospatial)
- Структура HyperLogLog (HyperLogLog)
- Поток (Stream)
https://habr.com/ru/articles/204354/ https://redis.io/docs/latest/

Транзакции:

Транзакционные базы данных (базы, работающие через транзакции) выполняют требования ACID, которые обеспечивают безопасность данных.

https://habr.com/ru/articles/537594/ https://ru.wikipedia.org/wiki/Транзакция_(информатика)

Не знаю Джун Мидл Сеньор Уровни изоляции транзакций
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций.

Уровни описаны в порядке увеличения изолированности транзакций и, соответственно, надёжности работы с данными.
```
0 — Чтение незафиксированных данных (Read Uncommitted) — чтение незафиксированных изменений как своей транзакции, так и параллельных транзакций. Нет гарантии, что данные, изменённые другими транзакциями, не будут в любой момент изменены в результате их отката, поэтому такое чтение является потенциальным источником ошибок. Невозможны потерянные изменения (lost changes), возможны грязное чтение (dirty read), неповторяемое чтение и фантомы.
1 — Чтение зафиксированных данных (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений параллельных транзакций. Потерянные изменения и грязное чтение не допускается, возможны неповторяемое чтение и фантомы.
2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые параллельными транзакциями после начала своей, недоступны. Потерянные изменения, грязное и неповторяемое чтение невозможны, возможны фантомы.
3 — Сериализуемый (Serializable) — сериализуемые транзакции. Результат параллельного выполнения сериализуемой транзакции с другими транзакциями должен быть логически эквивалентен результату их какого-либо последовательного выполнения. Проблемы синхронизации не возникают.
```
Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы его обеспечить. Соответственно, повышение изолированности может приводить к снижению скорости выполнения параллельных транзакций, что является «платой» за повышение надёжности.

В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Committed). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редко изменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.
Не знаю Джун Мидл Сеньор Взаимная блокировка
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Взаимная блокировка (англ. deadlocks)

В некоторых случаях, две транзакции могут в ходе их обработки пытаться получить доступ к одной и той же части базы данных в одно и то же время, таким образом, что это будет препятствовать их совершению. Например, транзакция А может получить доступ к части Х базы данных, и транзакция В может получить доступ к Y части базы данных. Если в этот момент транзакция А пытается получить доступ к части Y базы данных, в то время как транзакция B пытается получить доступ к части X, возникает ситуация взаимоблокировки, и ни одна транзакция не может быть произведена. Системы обработки транзакций предназначены для обнаружения таких ситуаций. Обычно обе транзакции отменяются и производится откат, а затем они автоматически запускаются в другом порядке, так что взаимоблокировка не повторится. Или иногда, только одна из транзакций, попавших в тупик, отменяется, производится откат, и автоматически повторяется после небольшой задержки.

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

MySQL:

https://www.opennet.ru/docs/RUS/sql/ https://wiki.gentoo.org/wiki/MySQL/Startup_Guide/ru

Не знаю Джун Мидл Сеньор Типы индексов
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
- Btree https://ru.wikipedia.org/wiki/B-дерево
- R-Tree (Пространственный индекс) https://ru.wikipedia.org/wiki/R-дерево_(структура_данных)
- Hash index
- Inverted index
- Уникальный индекс (Unique Index)
- Полнотекстовый индекс (Full-Text Index)
- Составной индекс
- Кластеризованные
- некластеризованные
https://timeweb.cloud/tutorials/sql/indeksy-v-sql-sozdanie-vidy-i-kak-rabotayut https://www.mysql.ru/docs/man/MySQL_indexes.html https://habr.com/ru/articles/556440/

PostgreSQL:

https://habr.com/ru/companies/tensor/articles/779698/ https://habr.com/ru/articles/340460/

Фреймворки:

https://kinsta.com/blog/php-frameworks/

Не знаю Джун Мидл Сеньор Symfony
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Symfony предлагает быструю разработку и управление веб-приложениями, позволяет легко решать рутинные задачи веб-программиста. Работает только с PHP 5 и выше. Имеет поддержку множества баз данных (MySQL, PostgreSQL, SQLite или любая другая PDO-совместимая СУБД). Информация о реляционной базе данных в проекте должна быть связана с объектной моделью. Это можно сделать при помощи ORM инструмента. Symfony поставляется с двумя из них: Propel и Doctrine.

Symfony бесплатен и публикуется под лицензией MIT.

https://symfony.com/doc/current/index.html
Не знаю Джун Мидл Сеньор Laravel
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Laravel — бесплатный веб-фреймворк с открытым кодом, предназначенный для разработки с использованием архитектурной модели MVC (англ. Model View Controller — модель-представление-контроллер). Laravel выпущен под лицензией MIT.

https://laravel.com/docs/

Python:

https://pythonworld.ru/samouchitel-python

GoLang:

https://tproger.ru/translations/golang-basics

Lua:

https://habr.com/ru/articles/77413/

Javascript:

https://learn.javascript.ru/first-steps https://habr.com/ru/companies/ruvds/articles/416375/

Не знаю Знаю let, var и const
- Знаю: Знаю что это, читал/изучал.
Разница между let, var и const
Не знаю Знаю Понимаю CORS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
CORS (Cross-Origin Resource Sharing, англ. «совместное использование ресурсов разных источников») — это стандарт, позволяющий предоставлять веб-страницам доступ к объектам сторонних интернет-ресурсов. Сторонним считается любой интернет-ресурс, который отличается от запрашиваемого протоколом, доменом или портом.

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

Первоначально для защиты информации была разработана «Политика одинакового источника» (Same-Origin Policy, SOP). Поддерживающий политику SOP веб-браузер сверяет комбинации сетевого протокола (например, https), точное имя домена и номер порта, чтобы разрешить доступ к ресурсам веб-страницы по запросам с другой страницы. Политика SOP не обязательна к применению, однако все современные веб-браузеры ее поддерживают.

Если веб-ресурсы интернет-источника соответствуют SOP, для доступа к ним из другого источника браузер должен поддерживать технологию Cross-Origin Resource Sharing. В 2006 году рабочая группа Консорциума Всемирной паутины (World Wide Web Consortium, W3C – организация, разрабатывающая интернет-стандарты) представила первый рабочий проект этой технологии. В 2014 году CORS был принят в качестве Рекомендации W3C. Структура Cross-Origin Resource Sharing

Методы CORS предназначены для управления доступом к дескрипторам (тегам) на веб-страницах в сети. Управляемые типы доступа подразделяются на три основных категории по работе с информацией сторонних ресурсов:

Доступ на запись — это доступ к ссылкам, заполнению веб-форм и переадресации на сторонние веб-страницы, т.е. на передачу информации в сторонний источник (веб-ресурс).

Доступ на вставку относится к категории доступа на считывание информации из стороннего источника. К этому типу принадлежат вставки в код дескрипторов audio, video, img, embed, object, link, script, iframe и другие элементы оформления веб-страниц. Структура подобных дескрипторов подразумевает самостоятельную инициацию перекрестных (cross-origin) запросов из сторонних источников. Все дескрипторы этой категории представляют низкий уровень угрозы безопасности, поэтому разрешены в веб-браузере по умолчанию.

Доступ на считывание — это дескрипторы, загружаемые с использованием фоновых методов вызова, таких как fetch(), технологии обмена данными Ajax и пр. Поскольку подобные дескрипторы могут содержать в теле любые участки кода (в том числе вредоносного), они запрещены в веб-браузерах по умолчанию.

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

https://yandex.cloud/ru/docs/glossary/cors https://habr.com/ru/companies/macloud/articles/553826/
Не знаю Знаю NaN
- Знаю: Знаю что это, читал/изучал.
Что такое и особенности NaN

TypeScript:

https://habr.com/ru/companies/piter/articles/820027/ https://habr.com/ru/companies/macloud/articles/559902/

Angular:

https://metanit.com/web/angular2/

React:

https://metanit.com/web/react/ https://ru.legacy.reactjs.org/tutorial/tutorial.html

Webpack:

Webpack — это модульный сборщик (bundler) с открытым исходным кодом, написанный на JavaScript.

Он берёт несколько скриптов JavaScript с их зависимостями и объединяет в файл, который используется браузером.

Преимущества Webpack:

ускоряет разработку, убирая необходимость постоянно перезагружать веб-страницу при изменениях в JS-файлах;

обеспечивает разделение кода на отдельные модули, которые можно переиспользовать внутри веб-приложения;

позволяет избежать проблем с перезаписью глобальных переменных;

поддерживает минификацию, то есть сокращение объёма кода без изменения его функциональности;

умеет работать с разными спецификациями модулей.

HTML:

https://developer.mozilla.org/ru/docs/Learn/Getting_started_with_the_web/HTML_basics

XML/XSL:

https://www.hostcms.ru/documentation/step-by-step/xslt/

CSS:

https://webref.ru/css

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

CSS фреймворки:

CSS фреймворки

Не знаю Знаю Понимаю БЭМ
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
БЭМ

Android:

Навыки по разработке приложений для Android

iOS:

Навыки по разработке приложений на iOS, для iPhone , iMac

Linux:

https://help.ubuntu.com/kubuntu/desktopguide/ru/linux-basics.html https://habr.com/ru/articles/655275/

Навыки общения и социализации:

https://blog.karpachoff.com/kommunikativnye-navyki-kak-ih-razvit-i-uluchshit

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

Владение языками:

Устная, письменна, и чтение.

Не знаю A1 A2 B1 B2 C1 C2 Английский

Сертификация CEFR

Английский

Методы достижения целей:

Методы достижения целей

Не знаю Знаю Понимаю SMART
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
подход к постановке целей, который помогает выбрать формулировку желаемого результата, дает чувство направления и помогает организовать и достичь целей.

Бизнес-анализ:

Бизнес-анализ

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

Преимущества:

Недостатки:

Применение:

Преимущества:

Недостатки:

Применение:

Преимущества:

Недостатки:

Применение:

Виды:

Преимущества:

Недостатки:

Применение:

Преимущества:

Недостатки:

Применение:

Типы двоичных деревьев

Зачем нужно

Свойства

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