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

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

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

- - ООП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- - Docker

- - Kubernetes

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

- - MySQL

- PHP

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

- Frontend

- - Javascript

- - CSS

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

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

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

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

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

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

Заполненных тем 23
Заполненных навыков 100
Data Paradigms Сеть SDLC Владение языками Search DB php-vendors docker Design-Pattern
2301
2024-12-11 07:23:50
Предыдущий триал 2301

Скачать 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/Разработка_через_тестирование
Не знаю Знаю Понимаю MDD
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Разработка, управляемая моделями

Разработка, управляемая моделями, (англ. model-driven development) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты[1].

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

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

Источник 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/Закон_Деметры

ООП:

Объе́ктно ориенти́рованное программи́рование (сокр. ООП) — методология или стиль программирования на основе описания типов/моделей предметной области и их взаимодействия, представленных порождением из прототипов или как экземпляры классов, которые образуют иерархию наследования.

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

https://ru.wikipedia.org/wiki/SOLID_(программирование)

Не знаю Джун Мидл Синьор Принципы ООП
- Джун: Может объяснить базовые принципы.
- Мидл: Разбирается в принципах ООП.
- Синьор: Может на лафкодинге показать пример принципов ООП.
Принципы:
- Абстракция
- Инкапсуляция
- Наследование (Делегация, Композиция, Агрегация)
- Полиморфизм
Знания на сеньора:
- Динамическое связывание методов
- Динамическое создание и уничтожение объектов
- Значительная глубина абстракции
- Наследование «размывает» код
- Инкапсуляция снижает скорость доступа к данным
https://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование

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

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

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

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

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

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

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

ORM:

todo

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

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

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

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/Антипаттерн

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

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

Не знаю Знаю Базовый класс-утилита
- Знаю: Знаю что это, читал/изучал.
BaseBean: Наследование функциональности из класса-утилиты вместо делегирования к нему.
Не знаю Знаю Вызов предка
- Знаю: Знаю что это, читал/изучал.
Call super: Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка.

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

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
Не знаю Знаю Понимаю Динамическое программирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Динамическое программирование — способ решения сложных задач путём разбиения их на более простые подзадачи. Он применим к задачам с оптимальной подструктурой, выглядящим как набор перекрывающихся подзадач, сложность которых чуть меньше исходной. В этом случае время вычислений, по сравнению с «наивными» методами, можно значительно сократить.

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

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

Хвостовая рекурсия — частный случай рекурсии, при котором любой рекурсивный вызов является последней операцией перед возвратом из функции. Подобный вид рекурсии примечателен тем, что может быть легко заменён на итерацию путём формальной и гарантированно корректной перестройки кода функции. Оптимизация хвостовой рекурсии путём преобразования её в плоскую итерацию реализована во многих оптимизирующих компиляторах. В некоторых функциональных языках программирования спецификация гарантирует обязательную оптимизацию хвостовой рекурсии.
Не знаю Знаю Понимаю Задача NP-полная (NP-complete problem)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Тип задач, принадлежащих классу NP (non-deterministic polynomial – «недетерминированные с полиномиальным временем»), для которых отсутствуют быстрые алгоритмы решения. Время работы алгоритмов решения таких задач существенно (обычно, экспоненциально) возрастает с увеличением объема входных данных.

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

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

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

К классу NP-полных относятся задача о коммивояжере, о вершинном покрытии и покрытии множеств.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не знаю Знаю Понимаю Троичный (Тернарный) поиск
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Трои́чный по́иск (Тернарный поиск) — это метод в информатике для поиска максимумов и минимумов функции, которая либо сначала строго возрастает, затем строго убывает, либо наоборот. Троичный поиск определяет, что минимум или максимум не может лежать либо в первой, либо в последней трети области, и затем повторяет поиск на оставшихся двух третях. Троичный поиск демонстрирует парадигму программирования «разделяй и властвуй».
```
/**
Находит максимум функции с одним экстремумом между 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/Троичный_поиск
Не знаю Знаю Понимаю Поиск в глубину (DFS)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Поиск в глубину(Depth-First Search, DFS) находит такой путь от данной вершины, до нужной, что этот путь содержит минимальную сумму ребер графа. Например, если мы ищем на карте метро путь от Сокольников, до Парка Победы, требующий наименьшее время для переезда(расстояние между каждыми соседними станциями, будет весом ребра), то мы ищем в глубину.

DFS следует концепции «погружайся глубже, головой вперед» («go deep, head first»). Идея заключается в том, что мы двигаемся от начальной вершины (точки, места) в определенном направлении (по определенному пути) до тех пор, пока не достигнем конца пути или пункта назначения (искомой вершины). Если мы достигли конца пути, но он не является пунктом назначения, то мы возвращаемся назад (к точке разветвления или расхождения путей) и идем по другому маршруту.
Не знаю Знаю Понимаю Алгоритм Флойда (алгоритм Флойда–Уоршелла)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Алгоритм нахождения длин кратчайших путей между всеми парами вершин во взвешенном ориентированном графе. Работает корректно, если в графе нет циклов отрицательной величины, а в случае, когда такой цикл есть, позволяет найти хотя бы один такой цикл. Алгоритм работает за Θ(n3) времени и использует Θ(n2) памяти.

https://neerc.ifmo.ru/wiki/index.php?title=Алгоритм_Флойда
Не знаю Знаю Понимаю HyperLogLog
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
HyperLogLog: является улучшенной версией LogLog и использует тот же базовый принцип для оценки кардинальности. Однако HLL включает дополнительные оптимизации, которые позволяют более эффективно использовать память и предоставлять более точные оценки в больших наборах данных. Вместо простого подсчета максимального количества ведущих нулей, HLL использует специальные функции хэширования (гиперлогарифмические хэши) и аппроксимацию среднего значения для повышения точности оценки кардинальности. HLL позволяет оценивать кардинальность с небольшой погрешностью при значительно меньшем использовании памяти по сравнению с LogLog.

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

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

Сравнение двух сигнатур MinHash позволяет оценить схожесть множеств, приближенно определить пересечение элементов и вычислить коэффициент Жаккара (отношение пересечения к объединению множеств). Чем меньше значение коэффициента Жаккара, тем менее схожи множества.

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

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

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

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

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

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

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

Не знаю Знаю Понимаю IP Hash

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

Алгоритм IP Hash – это метод балансировки нагрузки, который основан на IP-адресе клиента. Этот метод определяет сервер, на который следует направить запрос, исходя из IP-адреса клиента. Таким образом, одному и тому же клиенту всегда будет назначен один и тот же сервер, что позволяет сохранить состояние между запросами от одного и того же клиента.

Работа алгоритма IP Hash следующая:

Для каждого входящего запроса определяется IP-адрес клиента.

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

Хеш значение используется для выбора сервера из пула серверов. Обычно используется операция взятия остатка от деления хеша на количество серверов.

IP Hash может быть особенно полезным в сценариях, где необходимо поддерживать сессию между клиентом и сервером. Например, в веб-приложениях, где пользователь должен оставаться на одном и том же сервере для сохранения состояния в течение сеанса.

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

Сохранение состояния: IP Hash обеспечивает сохранение состояния между клиентом и сервером, что делает его подходящим для сценариев, требующих управления сессиями и кеширования.

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

Недостатки:

Ограничения масштабирования: IP Hash может ограничивать масштабирование, так как клиенты будут всегда маршрутизироваться на один и тот же сервер, что может создавать дисбаланс нагрузки.

Особенности прокси и балансировщиков: В некоторых случаях, использование балансировщиков или прокси-серверов может затруднить применение IP Hash.

Не знаю Знаю Понимаю Random
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Случайный выбор (Random, Randomized Load Balancing) распределяет входящие запросы между серверами случайным образом. Каждый новый запрос направляется на произвольно выбранный сервер из доступного пула, и для того, чтобы у каждого сервера был равный шанс (1/n, где n – число серверов) быть выбранным, для реализации алгоритма следует использовать не генератор псевдослучайных чисел, а тасование Фишера-Йетса. Преимущества
```
Обеспечивает равномерное распределение нагрузки в долгосрочной перспективе.
Простота реализации и низкие вычислительные затраты.
Не требует хранения состояния предыдущих запросов.
```
Недостатки

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

Алгоритм Power of Two Random Choices (лучший из двух случайных вариантов), представленный в 1996 году Майклом Митценмахером – усовершенствованная версия случайного выбора: вместо выбора одного случайного сервера, алгоритм выбирает два случайных сервера и направляет запрос на тот из них, который имеет меньшую нагрузку. Преимущества этого подхода перед простым случайным выбором:
```
Более равномерное распределение нагрузки и максимальное снижение вероятности перегрузки отдельных серверов.
Скорость – требует сравнения метрик всего лишь двух серверов вместо анализа состояния всей системы.
```

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

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

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

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

Docker:

https://docs.docker.com/engine/reference/commandline/docker/

Не знаю Джун Мидл Сеньор Консольные команды
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
run, exec, ps, kill, stop, rm, rmi, volume, images, pull, compose, logs
Не знаю Джун Мидл Сеньор Dickerfile - сборка образов
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Самостоятельная подготовка образа. Знание назначение большинства команд, и отличие CMD, RUN и ENTRYPOINT.

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

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

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

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

Транзакции:

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

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

MySQL:

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

Не знаю Знаю Понимаю Движки таблиц
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
- MyIsam
- InnoDb
- Memory
- ...

PostgreSQL:

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

PHP:

Знания языка программирования PHP

Фреймворки:

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

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

PHP vendors

Не знаю Джун Мидл Сеньор Composer
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Composer — пакетный менеджер уровня приложений для языка программирования PHP, который предоставляет средства по управлению зависимостями в PHP-приложении. Composer разработали и продолжают поддерживать два программиста Nils Adermann и Jordi Boggiano. Они начали разрабатывать Composer в апреле 2011, а первый релиз состоялся 1 марта 2012. Идея создания пакетных менеджеров уровня приложений не нова и его авторы вдохновлялись уже существовавшими на тот момент времени npm для Node.js и bundler для Ruby.

Composer работает через интерфейс командной строки и устанавливает зависимости (например библиотеки) для приложения. Он также позволяет пользователям устанавливать PHP-приложения, которые доступны на packagist.org, который является его основным репозиторием, где содержатся все доступные пакеты.

https://getcomposer.org
Не знаю Джун Мидл Сеньор PHPUnit
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
https://phpunit.de/documentation.html

Python:

https://pythonworld.ru/samouchitel-python

GoLang:

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

Lua:

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

Frontend:

Навыки связанные с client-side разработкой

TypeScript:

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

VueJS:

https://itanddigital.ru/bloghrconsulting/tpost/o9gce6b1b1-50-osnovnih-voprosov-i-otvetov-na-sobese

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

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

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/

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

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

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

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

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

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

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

Недостатки:

Применение:

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

Недостатки:

Применение:

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

Недостатки:

Применение:

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

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