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

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

  • Заполненных тем 8
  • Заполненных навыков 34
  • SDLC Auth architecture SOLID Paradigms API Design-Pattern ORM
  • 827
  • 2024-12-09 14:53:49
  • 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/Разработка_через_тестирование

  • 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/

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

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

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

    https://ru.wikipedia.org/wiki/OpenAPI_(спецификация)

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

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

    https://google.aip.dev/general

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

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

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

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

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

    Гибкие методологии разработки (англ. agile software development, agile-разработка) — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе[1].

    К гибким методикам, в частности, относят экстремальное программирование, DSDM, Scrum, FDD, BDD и другие.

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

    Agile-методы делают упор на непосредственном общении лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

    Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.

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

    Scrum (/skrʌm/[1]; англ. scrum «схватка») — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.

    https://ru.wikipedia.org/wiki/Scrum https://practicum.yandex.ru/blog/chto-takoe-scrum-metodologiya/

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

    Канбан (от яп. 看板 «рекламный щит, вывеска») — метод управления разработкой, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками. При данном подходе весь процесс разработки прозрачен для всех членов команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.

    https://ru.wikipedia.org/wiki/Канбан_(разработка)

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

    Scaled Agile Framework.

    Scaled Agile Framework® (SAFe®) — это набор организационных шаблонов и шаблонов рабочих процессов для реализации agile-методик в масштабе всей компании. Эта платформа представляет собой совокупность знаний, куда входят структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, а также соответствующие ценности.

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

    SAFe предоставляет структурированный подход к масштабированию agile-методик по мере роста бизнеса. SAFe имеет четыре конфигурации, подходящие для различного масштаба применения: Essential SAFe, Large Solution SAFe, Portfolio SAFe и Full SAFe.

    https://www.atlassian.com/ru/agile/agile-at-scale/what-is-safe

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

    RAD (от англ. rapid application development — быстрая разработка приложений) — концепция организации технологического процесса разработки программных продуктов, ориентированная на максимально быстрое получение результата в условиях сильных ограничений по срокам и бюджету и нечётко определённых требований к продукту. Эффект ускорения разработки достигается путём использования соответствующих технических средств и непрерывного, параллельного с ходом разработки, уточнения требований и оценки текущих результатов с привлечением заказчика. RAD создана в конце 1980-х как альтернатива более ранним каскадной и итеративной моделям. С конца XX века RAD получила широкое распространение.

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

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

    Feature driven development (FDD, разработка, управляемая функциональностью) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.

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

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

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

    https://janberg.by/incremental-process-model-inkrementalnaya-model-processa-razrabotki-programmnogo-obespecheniya/

    https://sergeiantonov23.thkit.ee/wp/инкрементная-модель/

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

    «Iterative Model» (итеративная или итерационная модель)

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

    https://ru.wikipedia.org/wiki/Итеративная_разработка

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

    Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.

    https://ru.wikipedia.org/wiki/Каскадная_модель

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

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

    Спиральная модель предполагает 4 этапа для каждого витка:

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

    Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.

    Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.
Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели.
Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

    https://ru.wikipedia.org/wiki/Model-View-Controller

  • SSR & SPA
    • Джун: Начальные/Поверхностные знания.
    • Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
    • Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.

    Особенности и преимущества.

    https://tproger.ru/articles/ssr-ili-spa-veb-sajty-chto-vybrat-dlya-vas-i-vawego-biznesa?ysclid=m48t4dcym7320970775

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

    todo