Матрица пользователя test1
- Заполненно 20 навыков
- Время заполнения: 1 мин
Hard skills
Принципы/методы программирования
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
AGNI («You aren't gonna need it»; с англ. — «Вам это не понадобится») — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.
Согласно адептам принципа YAGNI, желание писать код, который не нужен прямо сейчас, но может понадобиться в будущем, приводит к следующим нежелательным последствиям:
Тратится время, которое было бы затрачено на добавление, тестирование и улучшение необходимой функциональности. Новые функции должны быть отлажены, документированы и сопровождаться. Новая функциональность ограничивает то, что может быть сделано в будущем, — ненужные новые функции могут впоследствии помешать добавить новые нужные. Пока новые функции действительно не нужны, трудно полностью предугадать, что они должны делать, и протестировать их. Если новые функции тщательно не протестированы, они могут неправильно работать, когда впоследствии понадобятся. Это приводит к тому, что программное обеспечение становится более сложным (подчас чрезмерно сложным). Если вся функциональность не документирована, она может так и остаться неизвестной пользователям, но может создать различные риски для безопасности пользовательской системы. Добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту «снежного кома».
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Разработка через тестирование (англ. 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-объектов.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. domain-driven design, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.
Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс проектирования программного обеспечения в незнакомой предметной области.
Основные определения
Область (англ. domain) — предметная область, для которой разрабатывается программное обеспечение. Модель (англ. model) — описывает отдельные аспекты области и может быть использована для решения проблемы. Язык описания — используется для единого стиля описания домена и модели.
Подход DDD особо полезен в ситуациях, когда разработчик не является специалистом в области разрабатываемого продукта. К примеру: программист не может знать все области, в которых требуется создать ПО, но с помощью правильного представления структуры, посредством предметно-ориентированного подхода, может без труда спроектировать приложение, основываясь на ключевых моментах и знаниях рабочей области.
Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»
Элементы DDD
При проектировании на основе предметно-ориентированного подхода используются следующие понятия: Ограниченный контекст
В большинстве систем для предприятий используются крупномасштабные зоны ответственности. В DDD этот высший уровень организации называется ограниченным контекстом. Например, система биллинга крупной телекоммуникационной компании может иметь следующие ключевые элементы:
клиентская база система безопасности и защиты резервное копирование взаимодействие с платежными системами ведение отчётности администрирование система уведомлений
Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают архитектурный стиль, который имеет красноречивое название «Большой ком грязи» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).[2]
Сутью предметно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках. Сущность
Проще всего сущности выражать в виде существительных: люди, места, товары и т. д. У сущностей есть и индивидуальность, и жизненный цикл. Во время проектирования думать о сущностях следует как о единицах поведения, нежели как о единицах данных. Чаще всего какие-то операции, которые вы пытаетесь добавить в модель, должна получить какая-то сущность, или при этом начинает создаваться или извлекаться новая сущность. В более слабо связанном коде можно найти массу служебных или управляющих классов, проверяющих сущности снаружи. Объект-значение
Объект-значение — это свойства, важные в той предметной области, которую вы моделируете. У них, в отличие от сущностей, нет обозначения; они просто описывают конкретные сущности, которые уже имеют обозначения. Полезность объектов-значений состоит в том, что они описывают свойства сущностей гораздо более изящным и объявляющим намерения способом. Стоит всегда помнить, что значение объекта никогда не изменяется на протяжении выполнения всего программного кода. После их создания, внесение поправок невозможно. Агрегат
Агрегат — специальная сущность, к которой напрямую обращаются потребители. Использование агрегатов позволяет избегать чрезмерного соединения объектов, составляющих модель, между собой. Это позволяет избежать путаницы и упростить структуру, потому что не позволяет создавать тесно связанные системы. Службы предметных областей
Иногда в предметной области есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой класс, не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести многослойную архитектуру, так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.
https://ru.wikipedia.org/wiki/Предметно-ориентированное_проектирование
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Разработка, управляемая моделями
Разработка, управляемая моделями, (англ. model-driven development) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты[1].
Модель — это абстрактное описание программного обеспечения, которое скрывает информацию о некоторых аспектах с целью представления упрощенного описания остальных. Модель может быть исходным артефактом в разработке, если она фиксирует информацию в форме, пригодной для интерпретаций людьми и обработки инструментами. Модель определяет нотацию и метамодель. Нотация представляет собой совокупность графических элементов, которые применяются в модели и могут быть интерпретированы людьми. Метамодель описывает понятия используемые в модели и фиксирует информацию в виде метаданных, которые могут быть обработаны инструментами.
Модели описанные на предметно-ориентированном языке программирования могут быть использованы, как точки расширения каркасов.
Источник https://ru.wikipedia.org/wiki/Разработка,_управляемая_моделями
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Каталог шаблонов
-
Информационный эксперт (Information Expert)
-
Создатель (Creator)
-
Контроллер (Controller)
-
Слабое (низкое) зацепление (Low Coupling)
-
Сильная (высокая) связность (High Cohesion)
-
Полиморфизм (Polymorphism)
-
Чистая выдумка (Pure Fabrication)
-
Перенаправление (Indirection)
-
Устойчивость к изменениям (Protected Variations)
-
Информационный эксперт (Information Expert)
Шаблон определяет базовый принцип распределения ответственностей. Обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом.
Этот шаблон — самый очевидный и важный из девяти. Если его не учесть — получится спагетти-код, в котором трудно разобраться.
Локализация же ответственностей, проводимая согласно шаблону:
Повышает: Инкапсуляцию; Простоту восприятия; Готовность компонентов к повторному использованию; Снижает: степень зацепления.
- Создатель (Creator)
Проблема: Кто отвечает за создание объекта некоторого класса A?
Решение: Назначить классу B обязанность создавать объекты класса A, если класс B:
содержит(contains) или агрегирует(aggregate) объекты A; записывает(records) объекты A; активно использует объекты A; обладает данными для инициализации объектов A
Можно сказать, что шаблон «Creator» — это интерпретация шаблона «Information Expert» (смотрите пункт № 1) в контексте создания объектов.
Большинство порождающих шаблонов проектирования так или иначе выводятся или опираются на шаблон «Creator».
-
Контроллер (Controller)
Отвечает за операции, запросы которых приходят от пользователя, и может выполнять сценарии одного или нескольких вариантов использования (например, создание и удаление); Не выполняет работу самостоятельно, а делегирует компетентным исполнителям; Может представлять собой: Систему в целом; Подсистему; Корневой объект; Устройство.
-
Слабое (низкое) зацепление (Low Coupling) Основная статья: Зацепление (программирование)
Зацепление — мера того, насколько взаимозависимы разные подпрограммы или модули[2].
Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы.
- Сильная (высокая) связность (High Cohesion) Основная статья: Связность (программирование)
Связность — мера силы взаимосвязанности элементов внутри модуля; способ и степень, в которой задачи, выполняемые некоторым программным модулем, связаны друг с другом[2].
Сильная связность класса / модуля означает, что его элементы тесно связаны и сфокусированы.
Слабая (низкая) связность класса / модуля означает, что он не сфокусирован на одной цели, его элементы предназначены для слишком многих несвязанных обязанностей. Такой модуль трудно понять, использовать и поддерживать.
- Полиморфизм (Polymorphism) См. также: Полиморфизм (информатика)
Устройство и поведение системы:
Определяется данными; Задано полиморфными операциями её интерфейса.
Пример: Адаптация коммерческой системы к многообразию систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (см. также: Шаблон «Адаптеры»).
- Чистая выдумка (Pure Fabrication)
Не относится к предметной области, но:
Уменьшает зацепление; Повышает связность; Упрощает повторное использование.
«Pure Fabrication» отражает концепцию сервисов в модели предметно-ориентированного проектирования.
Пример задачи: Не используя средства класса «А», внести его объекты в базу данных.
Решение: Создать класс «Б» для записи объектов класса «А» (см. также: «Data Access Object»).
- Перенаправление (Indirection) См. также: Посредник (шаблон проектирования)
Слабое зацепление между элементами системы (и возможность повторного использования) обеспечивается назначением промежуточного объекта их посредником.
Пример: В архитектуре Model-View-Controller, контроллер (англ. controller) ослабляет зацепление данных (англ. model) с их представлением (англ. view).
- Устойчивость к изменениям (Protected Variations) Шаблон защищает элементы от изменения другими элементами (объектами или подсистемами) с помощью вынесения взаимодействия в фиксированный интерфейс, через который (и только через который) возможно взаимодействие между элементами. Поведение может варьироваться лишь через создание другой реализации интерфейса.
https://ru.wikipedia.org/wiki/GRASP https://habr.com/ru/articles/92570/
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Понятия/термины:
- Класс
- Объект
- Интерфейс
- Поля данных/Своиства
- Методы
- Контроль доступа
Принципы: -Абстракция -Инкапсуляция -Наследование -Полиморфизм
-Динамическое связывание методов -Значительная глубина абстракции -Наследование «размывает» код -Инкапсуляция снижает скорость доступа к данным -Динамическое создание и уничтожение объектов итп
https://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Императи́вное программи́рование — парадигма программирования (стиль написания исходного кода компьютерной программы), для которой характерно следующее:
- в исходном коде программы записываются инструкции (команды);
- инструкции должны выполняться последовательно;
- данные, получаемые при выполнении предыдущих инструкций, могут читаться из памяти последующими инструкциями;
- данные, полученные при выполнении инструкции, могут записываться в память.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Функциона́льное программи́рование — парадигма программирования, в которой процесс вычисления трактуется как вычисление значений функций в математическом понимании последних (в отличие от функций как подпрограмм в процедурном программировании).
Противопоставляется парадигме императивного программирования, которая описывает процесс вычислений как последовательное изменение состояний (в значении, подобном таковому в теории автоматов). При необходимости, в функциональном программировании вся совокупность последовательных состояний вычислительного процесса представляется явным образом, например, как список.
https://ru.wikipedia.org/wiki/Функциональное_программирование
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Начальный - знаю определение Средний - как и для чего применять Высокий - могу привести пример и досконально объяснить суть.
При создании программных систем использование принципов SOLID способствует созданию такой системы, которую будет легко поддерживать и расширять в течение долгого времени. Принципы SOLID — это руководства, которые также могут применяться во время работы над существующим программным обеспечением для его улучшения, например, для удаления «дурно пахнущего кода». https://ru.wikipedia.org/wiki/SOLID_(программирование)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Принцип_единственной_ответственности
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://habr.com/ru/companies/dataart/articles/262817/
https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc?permalink_comment_id=4823694
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Заключается в том, что обе стороны-участники обмена данными имеют абсолютно одинаковые ключи для шифрования и расшифровки данных. Данный способ осуществляет преобразование, позволяющее предотвратить просмотр информации третьей стороной.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Предполагает использовать в паре два разных ключа — открытый и секретный. В асимметричном шифровании ключи работают в паре — если данные шифруются открытым ключом, то расшифровать их можно только соответствующим секретным ключом и наоборот — если данные шифруются секретным ключом, то расшифровать их можно только соответствующим открытым ключом. Использовать открытый ключ из одной пары и секретный с другой — невозможно. Каждая пара асимметричных ключей связана математическими зависимостями. Данный способ также нацелен на преобразование информации от просмотра третьей стороной.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Цифровые подписи используются для установления подлинности документа, его происхождения и авторства, исключает искажения информации в электронном документе.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Преобразование входного массива данных произвольной длины в выходную битовую строку фиксированной длины. Такие преобразования также называются хеш-функциями или функциями свёртки, а их результаты называют хеш-кодом, контрольной суммой или дайджестом сообщения (англ. message digest). Результаты хеширования статистически уникальны. Последовательность, отличающаяся хотя бы одним байтом, не будет преобразована в то же самое значение.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Жадный алгоритм оптимального префиксного кодирования алфавита с минимальной избыточностью.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Токен_(авторизации)
https://habr.com/ru/articles/534092/
https://ru.hexlet.io/qna/glossary/questions/bearer-token-chto-eto
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Процесс_разработки_программного_обеспечения https://habr.com/ru/companies/edison/articles/269789/
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://habr.com/ru/companies/postgrespro/articles/330544/ https://habr.com/ru/companies/quadcode/articles/696498/
Кроме сервисов хранения
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- PSR1 - Basic Coding Standard
- PSR12 - Extended Coding Style Guide
- PSR3 - Logger Interface
- PSR4 - Autoloading Standard
- PSR6 - Caching Interface
- PSR16 - Simple Cache
- PSR7 - HTTP Message Interface
- PSR15 - HTTP Handlers
- PSR18 - HTTP Client
- PSR11 - Container Interface
- PSR13 - Hypermedia Links
- PSR14 - Event Dispatcher
- PSR17 - HTTP Factories
- PSR20 - Clock
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Design Patterns, описанные в книге "Банды четырех"
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Абстрактная_фабрика_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Строитель_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Прототип_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Одиночка_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Компоновщик_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Декоратор_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Приспособленец_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Заместитель_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Команда_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Интерпретатор_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Итератор_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Посредник_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Хранитель_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Наблюдатель_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Состояние_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Стратегия_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Шаблонный_метод_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Посетитель_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Шаблон_функционального_дизайна
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Интерфейс_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Интерфейс-маркер_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Контейнер_свойств_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Канал_событий_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Мультитон_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Единая_точка_входа_(шаблон_проектирования)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Null_object_(шаблон_проектирования)
Шаблоны используемы в построении архитектуры
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://habr.com/ru/articles/258443/ https://kubernetes.io/ru/docs/concepts/overview/what-is-kubernetes/
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
run, exec, ps, kill, stop, rm, rmi, volume, images, pull, compose, logs
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Самостоятельная подготовка образа. Знание назначение большинства команд, и отличие CMD, RUN и ENTRYPOINT.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Понимание как работает кэширование и сборка образа, многоступенчатая сборка.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- Команды
- Настройка docker-compose.yml
- Принципы работы с сетью
https://habr.com/ru/companies/ruvds/articles/450312/ https://docs.docker.com/compose/
todo
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- примеры где используется
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
todo
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
todo
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
todo
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
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
-
- Знаю: Можете объяснить и понимаете суть.
Abstraction inversion Сокрытие части функциональности от внешнего использования, в надежде на то, что никто не будет её использовать.
-
- Знаю: Можете объяснить и понимаете суть.
Ambiguous viewpoint Представление модели без спецификации её точки рассмотрения.
-
- Знаю: Можете объяснить и понимаете суть.
Big ball of mud: Система с нераспознаваемой структурой.
-
- Знаю: Можете объяснить и понимаете суть.
Gas factory: Необязательная сложность дизайна.
-
- Знаю: Можете объяснить и понимаете суть.
Re-Coupling: Процесс внедрения ненужной зависимости.
-
- Знаю: Можете объяснить и понимаете суть.
Stovepipe System: Редко поддерживаемая сборка плохо связанных компонентов.
-
- Знаю: Можете объяснить и понимаете суть.
Race hazard, Race condition: непредвидение возможности наступления событий в порядке, отличном от ожидаемого.
-
- Знаю: Можете объяснить и понимаете суть.
Mutilation: Излишнее «затачивание» объекта под определенную очень узкую задачу таким образом, что он не способен будет работать с никакими иными, пусть и очень схожими задачами.
-
- Знаю: Можете объяснить и понимаете суть.
Save or die: Сохранение изменений в конфигурации на жесткий диск лишь при завершении приложения; приводит к тому, что в случае отказа в программе эти данные будут утеряны
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
-
- Знаю: Можете объяснить и понимаете суть.
Analysis paralysis неоправданно большие затраты на анализ и проектирование. Часто приводит к закрытию проекта до начала его реализации.
-
- Знаю: Можете объяснить и понимаете суть.
Creeping featurism добавление новых улучшений в ущерб суммарному качеству системы.
-
- Знаю: Можете объяснить и понимаете суть.
Cash cow: при наличии продукта, приносящего выгоду без существенных вложений, не вкладываются средства в развитие и разработку новых продуктов.
-
- Знаю: Можете объяснить и понимаете суть.
Внесение ненужной сложности в решение.
-
- Знаю: Можете объяснить и понимаете суть.
Неожиданное взаимодействие между широко разделёнными частями системы.
-
- Знаю: Можете объяснить и понимаете суть.
Accumulate and fire Установка параметров подпрограмм в наборе глобальных переменных.
-
- Знаю: Можете объяснить и понимаете суть.
Blind faith Недостаточная проверка корректности исправления ошибки или результата работы подпрограммы.
-
- Знаю: Можете объяснить и понимаете суть.
Boat anchor Сохранение более не используемой части системы.
-
- Знаю: Можете объяснить и понимаете суть.
Busy spin, busy waiting: Потребление ресурсов ЦПУ (процессорного времени) во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать асинхронное программирование (к примеру, систему сообщений или событий).
-
- Знаю: Можете объяснить и понимаете суть.
Caching failure: Забывать сбросить флаг ошибки после её обработки.
-
- Знаю: Можете объяснить и понимаете суть.
The Diaper Pattern Stinks: Сброс флага ошибки без её обработки или передачи вышестоящему обработчику.
-
- Знаю: Можете объяснить и понимаете суть.
Checking type instead of membership, Checking type instead of interface: Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс.
-
- Знаю: Можете объяснить и понимаете суть.
Code momentum: Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы.
-
- Знаю: Можете объяснить и понимаете суть.
Coding by exception: Добавление нового кода для поддержки каждого специального распознанного случая.
-
- Знаю: Можете объяснить и понимаете суть.
Cryptic code: Использование аббревиатур вместо мнемоничных имён.
-
- Знаю: Можете объяснить и понимаете суть.
Hard code: Внедрение предположений об окружении системы в слишком большом количестве точек её реализации.
-
- Знаю: Можете объяснить и понимаете суть.
Soft code: Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование.
-
- Знаю: Можете объяснить и понимаете суть.
Lava flow: Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия.
-
- Знаю: Можете объяснить и понимаете суть.
Magic numbers: Использование числовых констант без объяснения их смысла.
-
- Знаю: Можете объяснить и понимаете суть.
Procedural code: Когда другая парадигма является более подходящей.
-
- Знаю: Можете объяснить и понимаете суть.
Spaghetti code, иногда «макароны»: Код с чрезмерно запутанным порядком выполнения.
-
- Знаю: Можете объяснить и понимаете суть.
Lasagnia code, или «лук» (onion): Чрезмерное связывание между собой уровней абстракции, приводящее к невозможности изменения одного уровня без изменения остальных.
-
- Знаю: Можете объяснить и понимаете суть.
Ravioli code, или «пельмени»: Объекты настолько «склеены» между собой, что практически не допускают рефакторинга.
-
- Знаю: Можете объяснить и понимаете суть.
Soap bubble: Объект, инициализированый мусором, максимально долго притворяется, что содержит какие-то данные.
-
- Знаю: Можете объяснить и понимаете суть.
Mutex hell: Внедрение слишком большого количества объектов синхронизации между потоками.
-
- Ваше представление о том какой уровень знания в данной области
Английский
-
- Ваше представление о том какой уровень знания в данной области
Французкий
-
- Ваше представление о том какой уровень знания в данной области
Немецкий
-
- Ваше представление о том какой уровень знания в данной области
Испанский
https://proglib.io/tests/proydi-test-na-znanie-algoritmov-i-struktur-dannyh
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Модульные тесты
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Интеграционные тесты
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Функциональные тесты
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Приемочное тестирование
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Тестирование производительности
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Smoke-тестирование
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
AB-тесты
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Пирамида тестирования
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Stub
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Mock
https://habr.com/ru/articles/549054/ https://habr.com/ru/articles/587620/ https://xbsoftware.ru/blog/metodologii-testirovaniya-po-kakuyu-vybrat/
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Се́рвис-ориенти́рованная архитекту́ра (СОА, англ. service-oriented architecture- SOA) — модульный подход к разработке программного обеспечения, базирующийся на обеспечении удаленного использования по стандартизированным протоколам распределённых, слабо связанных[англ.], легко заменяемых компонентов (сервисов) со стандартизированными интерфейсами.
Программные комплексы, разработанные в соответствии с СОА, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).
https://ru.wikipedia.org/wiki/Сервис-ориентированная_архитектура https://habr.com/ru/companies/vk/articles/342526/
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Луковая архитектура / Onion architecture / Hexagonal Architecture
Если мы делим код приложения на слои, то получаем слоистую архитектуру. Если применим к ней инверсию зависимости, то получим луковую. Гексагональная - это то же самое что и луковая, но с акцентом на разделение ответственностей внутри одного слоя.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.
Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние. Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели. Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://en.wikipedia.org/wiki/Presentation–abstraction–control
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
RLBS
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://ru.wikipedia.org/wiki/Событийно-ориентированная_архитектура
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Архитектура, управляемая событиями (event-driven architecture, EDA) архитектура, в основе которой лежит создание, определение, потребление и реакции на события. Т.е любое изменение в системы должно выбрасывать событие, на которое могут реагировать другие части системы.
https://apptractor.ru/develop/event-driven-architecture.html
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
SideCar
-
- Знаю: Можете объяснить и понимаете суть.
Rate Limiting
-
- Знаю: Можете объяснить и понимаете суть.
Strangler Fig
-
- Знаю: Можете объяснить и понимаете суть.
Health Endpoint Monitoring
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Domain layer — модель бизнес-логики приложения. В идеале вся бизнес логика(понятия и операции которым оперирует бизнес) должна находиться в этом слое. Задача остальных слоев, это инкапсуляция бизнес логики от объектов реального мира(бд, сети, файлов, пользователей, и т.д).
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Слой ответственный за "связь" доменной модели и инфраструктурными сервисами. Никакие другие классы, кроме классов данного слоя не могут дергать объекты доменного. В терминологии Фаулера, называется service layer.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Инфраструктурный слой, содержащий всё необходимое для общения приложения с внешним миром(пользователями, сторонними сервисами, железом и т.д). быстро может стать очень жирным. Как я уже говорил, обычно, этот код сложен и нестабилен. Инфраструктурный код соединяет ядро нашего драгоценного приложения с:
Файловой системой Сетью Орм Фреймворком Сторонними библиотеками
Очень важно понимать что здесь не может быть НИКАКОЙ бизнес логики.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Шаблон “Saga” используется для моделирования long-running (Как это будет по-русски? Долгосрочные? Долгоиграющие?) бизнес-процессов. Фактически, мы можем сказать, что Saga представляет собой Workflow для какого-то определённого сценария.
Long-running не следует понимать в терминах секундной стрелки и задаваться вопросом: 200 миллисекунд – это long-running или нет? В системах с архитектурой, построенной на событиях и сообщениях подобные вопросы вряд ли имеют смысл.
Идея, которую реализует шаблон “Saga” проста: после каждого успешно выполненного шага мы имеем некоторое состояние, с которого можно будет продолжить исполнение процесса. Шагом является выполнение какого-то действия, реакция на какое-то событие и т.д. То есть, если мы не смогли подтвердить транзакцию в базу данных, или если вызов второго веб-сервиса завершился неудачей, у нас имеется состояние, валидное на момент до его вызова. Наш бизнес-процесс остановлен – это да, но он и не потерян. Мы можем предпринять какие-то действия и продолжить процесс. Как результат – процесс просто выполнялся дольше.
Кроме того, имея такое состояние, мы можем легко моделировать процессы, “управляемые” событиями!
Технологии используемые в разработке для развертывания и деплоя
-
- Знаю: Можете объяснить и понимаете суть.
BaseBean: Наследование функциональности из класса-утилиты вместо делегирования к нему.
-
- Знаю: Можете объяснить и понимаете суть.
Anemic Domain Model: боязнь размещать логику в объектах предметной области.
-
- Знаю: Можете объяснить и понимаете суть.
Call super: Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка.
-
- Знаю: Можете объяснить и понимаете суть.
Empty subclass failure: Создание класса (в Perl), который не проходит «проверку пустоты подкласса» («Empty Subclass Test») из-за различного поведения по сравнению с классом, который наследуется от него без изменений.
-
- Знаю: Можете объяснить и понимаете суть.
God object: Концентрация слишком большого количества функций в одной части системы (классе).
-
- Знаю: Можете объяснить и понимаете суть.
Object cesspool: Переиспользование объектов, находящихся в непригодном для переиспользования состоянии.
-
- Знаю: Можете объяснить и понимаете суть.
Poltergeist: Объекты, чьё единственное предназначение — передавать информацию другим объектам.
-
- Знаю: Можете объяснить и понимаете суть.
Yo-yo problem: Чрезмерная размытость сильно связанного кода (например, выполняемого по порядку) по иерархии классов.
-
- Знаю: Можете объяснить и понимаете суть.
Singletonitis: Неуместное использование паттерна одиночка.
-
- Знаю: Можете объяснить и понимаете суть.
Friend zone: Неуместное использование дружественных классов и дружественных функций в языке C++.
-
- Знаю: Можете объяснить и понимаете суть.
Interface soup: Объединение нескольких интерфейсов, разделенных согласно принципу изоляции интерфейсов (Interface segregation), в один.
-
- Знаю: Можете объяснить и понимаете суть.
Висящие концы: Интерфейс, большинство методов которого бессмысленны и реализуются «пустышками».
-
- Знаю: Можете объяснить и понимаете суть.
Stub: Попытка «натянуть» на объект уже имеющийся малоподходящий по смыслу интерфейс, вместо создания нового.
Базы данных
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Round Robin - это один из классических алгоритмов балансировки нагрузки, который базируется на простой и эффективной идее: запросы от клиентов равномерно распределяются между серверами в циклическом порядке. Этот алгоритм был разработан исключительно для обеспечения равномерной нагрузки на серверы и минимизации времени ожидания ответа клиента.
Round Robin был одним из первых алгоритмов балансировки нагрузки и использовался в сетях даже до развития веб-приложений. Его суть заключается в том, что каждый новый запрос направляется на следующий сервер в кольце серверов, и при достижении конца списка серверов процесс начинается снова. Это гарантирует, что нагрузка распределяется равномерно, что особенно важно, когда серверы имеют одинаковые характеристики и могут обрабатывать запросы одинаково быстро.
Round Robin прост в реализации и обеспечивает базовую балансировку нагрузки. Однако, при использовании данного алгоритма, не учитывается актуальное состояние серверов или их производительность. Если один из серверов становится недоступным или медленным, алгоритм продолжит направлять к нему запросы, что может привести к неэффективному использованию ресурсов.
Преимущества:
- Простота реализации: один из самых простых алгоритмов балансировки нагрузки, и его легко внедрить.
- Равномерное распределение: обеспечивает равномерное распределение нагрузки на сервера, что делает его хорошим выбором для сценариев, где серверы имеют схожую производительность.
Недостатки:
- Не учитывает состояние серверов: не учитывает актуальное состояние серверов, поэтому даже недоступные серверы продолжат получать запросы.
- Не реагирует на нагрузку: не учитывает текущую нагрузку на серверы, что может привести к перегрузке некоторых серверов, особенно если они обрабатывают запросы медленнее других.
Ограниченный вариант: может быть менее подходящим для сценариев, где серверы имеют различную производительность или актуальное состояние серверов критично.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Least Connections (Наименьшее количество соединений) - это алгоритм балансировки нагрузки, который призван выбирать сервер с наименьшим активным соединением из числа доступных серверов.
Этот алгоритм ориентирован на учет текущей нагрузки на серверы и позволяет маршрутизировать запросы к серверам, у которых наименьшая нагрузка.
Работа алгоритма состоит в следующем:
При поступлении нового запроса, балансировщик нагрузки анализирует количество активных соединений на каждом из серверов в пуле. Запрос направляется на сервер с наименьшим количеством активных соединений. Счетчик активных соединений обновляется.
Least Connections является более интеллектуальным алгоритмом по сравнению с Round Robin, так как он учитывает текущую нагрузку на серверы, позволяя эффективно распределять запросы даже в ситуациях, где серверы имеют разную производительность.
Преимущества:
Эффективное распределение нагрузки: Обеспечивает более равномерное распределение нагрузки на серверы, что делает его подходящим для сценариев, где серверы имеют разную производительность. Учет активных соединений: Алгоритм учитывает актуальное состояние серверов и направляет запросы к серверу с наименьшим количеством активных соединений, что уменьшает вероятность перегрузки.
Недостатки:
Сложность реализации: может потребовать сложных механизмов учета активных соединений на серверах. Отсутствие учета производительности серверов: учитывает только количество активных соединений, но не учитывает производительность серверов, что может привести к неоптимальному распределению нагрузки в некоторых случаях.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Алгоритм IP Hash – это метод балансировки нагрузки, который основан на IP-адресе клиента. Этот метод определяет сервер, на который следует направить запрос, исходя из IP-адреса клиента. Таким образом, одному и тому же клиенту всегда будет назначен один и тот же сервер, что позволяет сохранить состояние между запросами от одного и того же клиента.
Работа алгоритма IP Hash следующая:
Для каждого входящего запроса определяется IP-адрес клиента. Применяется хеш-функция к IP-адресу, чтобы получить числовое значение (хеш). Хеш значение используется для выбора сервера из пула серверов. Обычно используется операция взятия остатка от деления хеша на количество серверов.
IP Hash может быть особенно полезным в сценариях, где необходимо поддерживать сессию между клиентом и сервером. Например, в веб-приложениях, где пользователь должен оставаться на одном и том же сервере для сохранения состояния в течение сеанса.
Преимущества:
Сохранение состояния: IP Hash обеспечивает сохранение состояния между клиентом и сервером, что делает его подходящим для сценариев, требующих управления сессиями и кеширования. Постоянная маршрутизация: Клиент всегда будет направляться на один и тот же сервер, что полезно для устойчивости и непрерывности обслуживания клиентов.
Недостатки:
Ограничения масштабирования: IP Hash может ограничивать масштабирование, так как клиенты будут всегда маршрутизироваться на один и тот же сервер, что может создавать дисбаланс нагрузки. Особенности прокси и балансировщиков: В некоторых случаях, использование балансировщиков или прокси-серверов может затруднить применение IP Hash.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Наименьшее время отклика.
Алгоритм Least Response Time балансирует нагрузку, направляя запросы на сервер, которые демонстрируют наилучшую производительность в данный момент. Он учитывает два ключевых фактора: время отклика сервера и количество активных соединений. Принцип работы
Для каждого сервера в системе балансировщик нагрузки постоянно мониторит время, которое требуется серверу для обработки запроса и отправки ответа. Также отслеживается количество активных соединений на каждом сервере. При поступлении нового запроса выбирается сервер с наименьшим временем отклика и наименьшим количеством активных соединений. Помимо времени отклика и количества активных соединений могут учитываться дополнительные веса: score = (response_time * weight1) + (active_ connections * weight2)
Преимущества
- Учет текущей производительности серверов и динамическая адаптация обеспечивают оптимальный баланс и наилучший пользовательский опыт.
- Метод хорошо работает с серверами разной мощности и приложениями с разными характеристиками.
Недостатки
- Сложность реализации – алгоритм требует постоянного мониторинга и анализа производительности серверов.
- Необходимость обработки большего объема данных для принятия решений создает повышенную нагрузку на балансировщик.
- Определение и динамическое обновление дополнительных весов может стать нетривиальной задачей.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Случайный выбор (Random, Randomized Load Balancing) распределяет входящие запросы между серверами случайным образом. Каждый новый запрос направляется на произвольно выбранный сервер из доступного пула, и для того, чтобы у каждого сервера был равный шанс (1/n, где n – число серверов) быть выбранным, для реализации алгоритма следует использовать не генератор псевдослучайных чисел, а тасование Фишера-Йетса. Преимущества
Обеспечивает равномерное распределение нагрузки в долгосрочной перспективе. Простота реализации и низкие вычислительные затраты. Не требует хранения состояния предыдущих запросов.
Недостатки
Недостаток – не учитывает текущую нагрузку на серверы и их производительность, поэтому лучше всего подходит для систем, где серверы имеют примерно одинаковую производительность, а задачи – более-менее равную сложность.
Алгоритм Power of Two Random Choices (лучший из двух случайных вариантов), представленный в 1996 году Майклом Митценмахером – усовершенствованная версия случайного выбора: вместо выбора одного случайного сервера, алгоритм выбирает два случайных сервера и направляет запрос на тот из них, который имеет меньшую нагрузку. Преимущества этого подхода перед простым случайным выбором:
Более равномерное распределение нагрузки и максимальное снижение вероятности перегрузки отдельных серверов. Скорость – требует сравнения метрик всего лишь двух серверов вместо анализа состояния всей системы.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Наименьший объем трафика (Least Bandwidth, буквально – наименьшая пропускная способность) – динамический алгоритм балансировки нагрузки, который направляет входящие запросы на сервер, передающий наименьший объем данных в текущий момент. Особенно эффективен в средах, где пропускная способность сети является критическим фактором производительности. Принцип работы
Балансировщик нагрузки постоянно мониторит использование пропускной способности каждого сервера. При поступлении нового запроса выбирается сервер с наименьшим текущим использованием полосы пропускания. Запрос направляется на выбранный сервер.
Преимущества
Оптимизация использования сетевых ресурсов – алгоритм эффективно предотвращает перегрузку отдельных сетевых каналов. Улучшение производительности за счет избежания задержек, связанных с перегрузкой сети. Адаптация к изменениям в пропускной способности системы в реальном времени.
Недостатки
Постоянное измерение пропускной способности может создавать дополнительную нагрузку на систему. Не учитывает использование CPU и памяти.
Знания языка программирования PHP
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- Атомарные
- Составные
- Пересечение
- Объединение
- Псевдонимы
https://www.php.net/manual/ru/language.types.type-system.php
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://www.php.net/manual/ru/language.oop5.late-static-bindings.php https://www.php.net/manual/ru/language.oop5.static.php
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://www.php.net/manual/ru/language.generators.overview.php https://www.php.net/manual/ru/language.oop5.iterations.php https://www.php.net/manual/ru/class.iterator.php
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
l
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://www.php.net/manual/ru/class.fiber.php https://habr.com/ru/articles/756642/ https://habr.com/ru/articles/756642/
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- Встроенные классы исключений.
- Try/Catch/Finally
-
-
- Знаю: Можете объяснить и понимаете суть.
https://code-basics.com/ru/languages/php/lessons/ternary-operator
-
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- errorclearlast
- errorgetlast
- error_log
- error_reporting
- seterrorhandler
- restoreerrorhandler
- setexceptionhandler
- restoreexceptionhandler
- trigger_error
- user_error
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Php libs
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
TCP/IP
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
UDP
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
HTTP/HTTPS
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
IMAP/POP3
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
SSH
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
TLS
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
DNS
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- DDOS
- XSS
https://learn.javascript.ru/first-steps https://habr.com/ru/companies/ruvds/articles/416375/
https://help.ubuntu.com/kubuntu/desktopguide/ru/linux-basics.html https://habr.com/ru/articles/655275/
-
- Знаю: Можете объяснить и понимаете суть.
псевдо-классы
-
- Знаю: Можете объяснить и понимаете суть.
нормализаця стилей
-
- Знаю: Можете объяснить и понимаете суть.
Медиазапросы
-
- Знаю: Можете объяснить и понимаете суть.
animation,transition,transform
CSS фреймворки
Сетевые протоколы (IP, Transport, etc)
-
- Знаю: Можете объяснить и понимаете суть.
LESS
-
- Знаю: Можете объяснить и понимаете суть.
SASS
-
- Знаю: Можете объяснить и понимаете суть.
БЭМ
-
- Знаю: Можете объяснить и понимаете суть.
Bootstrap
-
- Знаю: Можете объяснить и понимаете суть.
Foundation
-
- Знаю: Можете объяснить и понимаете суть.
Bulma
-
- Знаю: Можете объяснить и понимаете суть.
Tailwind
-
- Знаю: Можете объяснить и понимаете суть.
UIKit
-
- Знаю: Можете объяснить и понимаете суть.
Pure
Soft skills
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://practicum.yandex.ru/blog/taym-menedzhment-kak-upravlyat-vremenem/ https://trends.rbc.ru/trends/education/606335659a7947a191c4b092
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- Способен предоставлять отчет по задаче, когда спрашивают
- Проактивно предупреждает о потенциальных проблемах, запрашивает помощь и так далее
- Способен самостоятельно ставить себе задачи на протяжении длительного времени, занимаясь только согласованием видения с "архитекторами" и "владельцами продукта"
- Имеет четкое понимание приоритетов задач с точки зрения разработки. Прислушивается к приоритетам с точки зрения бизнеса, способен обеспечить "героические" усилия (деливери в ограниченные сроки) не путем сверхусилий команды, а путем совместного упрощения задач и т.п.
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
- Способен отвечать на вопросы по проекту / технологиям. Способен делиться своими знаниями, в формате "здесь надо делать не так"
- Способен эффективно обучать небольшую группу сотрудников. Составлять план развития.
- Способен доносить знания неопределённо широкому кругу людей. Владеет навыками психологии-педагогики-групповой динамики для максимально эффективного менторинга
Нвык общения / Социальный навык https://blog.karpachoff.com/kommunikativnye-navyki-kak-ih-razvit-i-uluchshit
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Иницирует коммуникации по мере возникновения проблем в текущих задачахи и в рамках действующих регламентов (стэндапы, ретроспективы и т.д.)
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Способен оппонировать другим разработчикам, в том числе и вышестоящим, если уверен в своих аргументах. Отслеживает результаты коммуникаций в контексте конкретных действий
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Применяет инженерный подход в общении - коммуникации используются как эффективный инструмент достижения целей. В рабочих процессах полностью отсутсвуют коммуникации, которые не способствуют достижению конкретных целей
-
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
Владеет понятиями эмоционального интеллекта, базовыми принципами НЛП и всем, что способно помочь в выстраивании общения со "сложными" людьми. Строет общение исходя не только из бизнес целей, но и психологических особенностей другой стороны в общении
Устная, письменна, и чтение.
Методы достижения целей
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://kubernetes.io/docs/concepts/services-networking/ingress/
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://kubernetes.io/docs/concepts/services-networking/service/
Бизнес-анализ
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
https://www.elastic.co/guide/en/kibana/current/development.html
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.
-
- Знакомо: Обладаете поверхностными заниями, когда-то читали про это.
- Знаю: Можете объяснить суть.
- Понимаю и применяю: Можете показать на примере и рассказать подробности.