Матрица пользователя : Krauze.karina.work
- Заполненных тем 36
- Заполненных навыков 108
- social SDLC Javascript Data Auth OOP Paradigms Мягкие навыки sql Frontend
- 2362
- 2024-12-31 11:14:23
Hard skills
Пет проекты и сервисы
-
YAGNI
- Знаю: Знаю что это, читал/изучал.
AGNI («You aren't gonna need it»; с англ. — «Вам это не понадобится») — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.
Согласно адептам принципа 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/Функциональное_программирование
-
Структурное программирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков.
-
Закон Деметры
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Объе́ктно ориенти́рованное программи́рование (сокр. ООП) — методология или стиль программирования на основе описания типов/моделей предметной области и их взаимодействия, представленных порождением из прототипов или как экземпляры классов, которые образуют иерархию наследования.
При создании программных систем использование принципов SOLID способствует созданию такой системы, которую будет легко поддерживать и расширять в течение долгого времени. Принципы SOLID — это руководства, которые также могут применяться во время работы над существующим программным обеспечением для его улучшения, например, для удаления «дурно пахнущего кода».
-
Понятия ООП
- Знаю: Может рассказать и объяснить все термины
- Понимаю: На лайвкодинге может написать код используя термины.
Термины:
- Класс
- Объект
- Интерфейс
- Поля данных/Своиства
- Методы
- Контроль доступа
-
Принципы ООП
- Джун: Может объяснить базовые принципы.
- Мидл: Разбирается в принципах ООП.
- Синьор: Может на лафкодинге показать пример принципов ООП.
Принципы:
- Абстракция
- Инкапсуляция
- Наследование (Делегация, Композиция, Агрегация)
- Полиморфизм
Знания на сеньора:
- Динамическое связывание методов
- Динамическое создание и уничтожение объектов
- Значительная глубина абстракции
- Наследование «размывает» код
- Инкапсуляция снижает скорость доступа к данным
https://ru.wikipedia.org/wiki/Объектно-ориентированное_программирование
-
SOLID - S
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Знаю - знаю определение Понимаю - привести пример и досконально объяснить суть.
https://ru.wikipedia.org/wiki/Принцип_единственной_ответственности
-
SOLID - O
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
SOLID - L
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
SOLID - I
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
SOLID - D
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://habr.com/ru/companies/dataart/articles/262817/
https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc?permalink_comment_id=4823694
-
Cookie/Session
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
Token (Barrier)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://ru.wikipedia.org/wiki/Токен_(авторизации)
https://habr.com/ru/articles/534092/
https://ru.hexlet.io/qna/glossary/questions/bearer-token-chto-eto
-
JWT
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
GraphQL
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
REST(FULL) API
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
software development process or software development life cycle (SDLC)
https://ru.wikipedia.org/wiki/Процесс_разработки_программного_обеспечения
-
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/
-
Канбан
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Канбан (от яп. 看板 «рекламный щит, вывеска») — метод управления разработкой, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками. При данном подходе весь процесс разработки прозрачен для всех членов команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.
-
Инкрементная разработка
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
-
Итеративная разработка
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
«Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
-
Каскадная модель
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.
-
Cпиральная модель
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
«Спиральная модель» (Spiral Model) похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
Design Patterns, описанные в книге "Банды четырех"
Шаблоны используемы в построении архитектуры
-
MVC
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.
Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние. Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели. Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.
-
SSR & SPA
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Особенности и преимущества.
todo
-
Lazy Load
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
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
-
Состояние гонки
- Знаю: Знаю что это, читал/изучал.
Race hazard, Race condition: непредвидение возможности наступления событий в порядке, отличном от ожидаемого.
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
-
Ненужная сложность
- Знаю: Знаю что это, читал/изучал.
Внесение ненужной сложности в решение.
-
Кэширование ошибки
- Знаю: Знаю что это, читал/изучал.
Caching failure: Забывать сбросить флаг ошибки после её обработки.
-
Спагетти-код
- Знаю: Знаю что это, читал/изучал.
Spaghetti code, иногда «макароны»: Код с чрезмерно запутанным порядком выполнения.
-
Вызов предка
- Знаю: Знаю что это, читал/изучал.
Call super: Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка.
-
Висящие концы
- Знаю: Знаю что это, читал/изучал.
Висящие концы: Интерфейс, большинство методов которого бессмысленны и реализуются «пустышками».
-
Заглушка
- Знаю: Знаю что это, читал/изучал.
Stub: Попытка «натянуть» на объект уже имеющийся малоподходящий по смыслу интерфейс, вместо создания нового.
https://proglib.io/tests/proydi-test-na-znanie-algoritmov-i-struktur-dannyh
https://education.yandex.ru/handbook/algorithms https://apptractor.ru/info/articles/6-algoritmov-kotorye-dolzhen-znat-kazhdyy-razrabotchik.html https://codechick.io/tutorials/dsa/dsa-algorithm
-
Динамическое программирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Динамическое программирование — способ решения сложных задач путём разбиения их на более простые подзадачи. Он применим к задачам с оптимальной подструктурой, выглядящим как набор перекрывающихся подзадач, сложность которых чуть меньше исходной. В этом случае время вычислений, по сравнению с «наивными» методами, можно значительно сократить.
Ключевая идея в динамическом программировании достаточно проста. Как правило, чтобы решить поставленную задачу, требуется решить отдельные части задачи (подзадачи), после чего объединить решения подзадач в одно общее решение. Часто многие из этих подзадач одинаковы. Подход динамического программирования состоит в том, чтобы решить каждую подзадачу только один раз, сократив тем самым количество вычислений. Это особенно полезно в случаях, когда число повторяющихся подзадач экспоненциально велико.
Метод динамического программирования сверху — это простое запоминание результатов решения тех подзадач, которые могут повторно встретиться в дальнейшем. Динамическое программирование снизу включает в себя переформулирование сложной задачи в виде рекурсивной последовательности более простых подзадач.
-
Рекурсия
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Рекурсия – это когда функция вызывает сама себя(напрямую или через функцию посредника), как правило, с другими аргументами. Рекурсия помогает писать код более компактно и понятно, однако имеет оверхэд по памяти из-за необходимости хранить стек вызова. Для оптимизации можно переписать алгоритм используя циклы - любая рекурсия может быть переделана в цикл, как правило, вариант с циклом будет эффективнее. Также есть хвостовая рекурсия.
Хвостовая рекурсия — частный случай рекурсии, при котором любой рекурсивный вызов является последней операцией перед возвратом из функции. Подобный вид рекурсии примечателен тем, что может быть легко заменён на итерацию путём формальной и гарантированно корректной перестройки кода функции. Оптимизация хвостовой рекурсии путём преобразования её в плоскую итерацию реализована во многих оптимизирующих компиляторах. В некоторых функциональных языках программирования спецификация гарантирует обязательную оптимизацию хвостовой рекурсии.
-
Стэк(Stack)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Cтруктура данных, организованная по принципу "последний пришел, первый ушел" (LIFO). Элементы добавляются и удаляются с одного конца структуры.
Преимущества:
- Простота реализации
- Легкость использования в рекурсии и отката операций
Недостатки:
- Ограниченный доступ к элементам (только к вершине стека)
Применение:
- Стеки полезны при выполнении рекурсивных функций, обработке скобочных последовательностей и отмене операций.
-
Связанный список (Linked List)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Связанный список - это структура данных, состоящая из узлов, каждый из которых содержит значение элемента и указатель на следующий узел в списке.
Существуют односвязные списки, где каждый узел имеет указатель только на следующий узел, двусвязные списки, где узлы имеют указатели на предыдущий и следующий узлы и кольцевые.
Преимущества:
- Динамическое изменение размера списка (в отличие от массивов)
- Эффективное добавление и удаление элементов в начале или конце списка
- Относительно простая реализация
Недостатки:
- Непостоянное время доступа к элементам (в отличие от массивов)
- Больший объем занимаемой памяти по сравнению с массивами из-за хранения указателей на узлы
Применение:
- Связанные списки подходят для реализации стеков, очередей, а также для задач, где требуется частое добавление или удаление элементов и не требуется быстрый доступ к элементам по индексу.
-
Массивы (Arrays)
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Массивы – это простейшая структура данных, представляющая собой набор элементов одного типа, расположенных последовательно в памяти. Хранит набор значений (элементов массива), идентифицируемых по индексу или набору индексов, принимающих целые (или приводимые к целым) значения из некоторого заданного непрерывного диапазона.
Преимущества:
Быстрый доступ к элементам по индексу Непрерывная область памяти
Недостатки:
Фиксированный размер Неэффективное добавление/удаление элементов
Применение: Массивы подходят для хранения набора данных с фиксированным размером, где операции вставки и удаления элементов не требуются.
-
Двоичное дерево
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Двоичное дерево — древовидная структура данных, в которой у родительских узлов не может быть больше двух детей.
Типы двоичных деревьев
- Полное двоичное дерево — особый тип бинарных деревьев, в котором у каждого узла либо 0 потомков, либо 2.
- Совершенное двоичное дерево — особый тип бинарного дерева, в котором у каждого внутреннего узла по два ребенка, а листовые вершины находятся на одном уровне.
- Законченное двоичное дерево похоже на совершенное, но есть три большие отличия.
- Все уровни должны быть заполнены.
- Все листовые вершины склоняются влево.
- У последней листовой вершины может не быть правого собрата. Это значит, что завершенное дерево необязательно полное.
- Вырожденное двоичное дерево — дерево, в котором на каждый уровень приходится по одной вершине.
- Скошенное вырожденное дерево — вырожденное дерево, в котором есть либо только левые, либо только правые узлы. Таким образом, есть два типа скошенных деревьев — скошенные влево вырожденные деревья и скошенные вправо вырожденные деревья.
- Сбалансированное двоичное дерево — тип бинарного дерева, в котором у каждой вершины количество вершин в левом и правом поддереве различаются либо на 0, либо на 1.
https://backendinterview.ru/algostruct/graph.html https://backendinterview.ru/algostruct/index.html
https://habr.com/ru/companies/otus/articles/770248/ https://habr.com/ru/companies/otus/articles/782064/ https://habr.com/ru/companies/ruvds/articles/732648/
Криптогра́фия — наука о методах обеспечения конфиденциальности (невозможности прочтения информации посторонним), целостности данных (невозможности незаметного изменения информации), аутентификации (проверки подлинности авторства или иных свойств объекта), а также невозможности отказа от авторства.
-
Цифровые подписи
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Цифровые подписи используются для установления подлинности документа, его происхождения и авторства, исключает искажения информации в электронном документе.
https://habr.com/ru/articles/549054/ https://habr.com/ru/articles/587620/ https://xbsoftware.ru/blog/metodologii-testirovaniya-po-kakuyu-vybrat/
-
Пирамида тестирования
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Пирамида тестирования
-
Модульные тесты
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Модульное тестирование (Unit Testing) – это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения. Его цель заключается в том, чтобы проверить, что каждая единица программного кода работает должным образом. Данный вид тестирование выполняется разработчиками на этапе кодирования приложения. Модульные тесты изолируют часть кода и проверяют его работоспособность. Единицей для измерения может служить отдельная функция, метод, процедура, модуль или объект.
-
Интеграционные тесты
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Интеграционные тесты
-
Функциональные тесты
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Функциональные тесты
-
Smoke-тестирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Smoke-тестирование
Технологии используемые в разработке для развертывания и деплоя
-
Github CI/CD
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
-
Консольные команды
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
run, exec, ps, kill, stop, rm, rmi, volume, images, pull, compose, logs
-
Docker-compose
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
- Команды
- Настройка docker-compose.yml
- Принципы работы с сетью
https://habr.com/ru/companies/ruvds/articles/450312/ https://docs.docker.com/compose/
https://habr.com/ru/articles/258443/ https://kubernetes.io/ru/docs/concepts/overview/what-is-kubernetes/
- Сервисы метрик и логирования
-
Git
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Git — распределённая система управления версиями.
Базы данны SQL, NoSQL и сервисы очередей
-
Mongo
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Mongo
-
Firebase
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
Виды отношений таблиц
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
- один к одному
- один ко многим
- многие к одному
- многие ко многим
-
Внешний ключ
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Foreign key Внешние ключи позволяют установить связи между таблицами. Внешний ключ устанавливается для столбцов из зависимой, подчиненной таблицы, и указывает на один из столбцов из главной таблицы. Как правило, внешний ключ указывает на первичный ключ из связанной главной таблицы.
https://ru.wikipedia.org/wiki/Внешний_ключ https://metanit.com/sql/mysql/2.5.php
-
Join
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
- left
- right
- inner
- outer
Транзакционные базы данных (базы, работающие через транзакции) выполняют требования ACID, которые обеспечивают безопасность данных.
https://habr.com/ru/articles/537594/ https://ru.wikipedia.org/wiki/Транзакция_(информатика)
https://habr.com/ru/companies/tensor/articles/779698/ https://habr.com/ru/articles/340460/
Знания языка программирования PHP
-
Типы данных PHP
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
- Атомарные
- Составные
- Пересечение
- Объединение
- Псевдонимы
https://www.php.net/manual/ru/language.types.type-system.php
- Стрелочные функции
- Тернарный оператор
-
PDO
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
Symfony
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Symfony предлагает быструю разработку и управление веб-приложениями, позволяет легко решать рутинные задачи веб-программиста. Работает только с PHP 5 и выше. Имеет поддержку множества баз данных (MySQL, PostgreSQL, SQLite или любая другая PDO-совместимая СУБД). Информация о реляционной базе данных в проекте должна быть связана с объектной моделью. Это можно сделать при помощи ORM инструмента. Symfony поставляется с двумя из них: Propel и Doctrine.
Symfony бесплатен и публикуется под лицензией MIT.
-
Laravel
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Laravel — бесплатный веб-фреймворк с открытым кодом, предназначенный для разработки с использованием архитектурной модели MVC (англ. Model View Controller — модель-представление-контроллер). Laravel выпущен под лицензией MIT.
PHP vendors
-
Composer
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Composer — пакетный менеджер уровня приложений для языка программирования PHP, который предоставляет средства по управлению зависимостями в PHP-приложении. Composer разработали и продолжают поддерживать два программиста Nils Adermann и Jordi Boggiano. Они начали разрабатывать Composer в апреле 2011, а первый релиз состоялся 1 марта 2012. Идея создания пакетных менеджеров уровня приложений не нова и его авторы вдохновлялись уже существовавшими на тот момент времени npm для Node.js и bundler для Ruby.
Composer работает через интерфейс командной строки и устанавливает зависимости (например библиотеки) для приложения. Он также позволяет пользователям устанавливать PHP-приложения, которые доступны на packagist.org, который является его основным репозиторием, где содержатся все доступные пакеты.
-
PSR standart
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
- 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
-
PHPUnit
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Навыки связанные с client-side разработкой
-
Lazy Loading
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Загрузка кода по частям по мере необходимости.
Применяется совместно с Code Splitting
-
Форматы изображений
- Знакомо: Имею общее представление о большинстве форматах
- Знаю: Знаю плюсы и минусы основных форматов jpg, png, gif, svg, ico
- Понимаю: Понимаю и могу объяснить как устроены алгоритмы сжатия в различных форматах.
Растровые и векторные форматы изображений (jpg, png, gif, svg, ico, tiff, avif, apng, hiec, webp, bmp, raw и т.д.).
Оптимизация и особенности применения.
-
SVG
- Знаю: Базовый синтаксис и принцип работы
- Понимаю и применяю: Могу поменять текст, сформировать новое изображение с нуля, анимировать графику
-
Оптимизация загрузки ресурсов
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
способы подключения ресурсов (async/defer, prefetch/preload)
Preload, prefetch и другие теги https://habr.com/ru/articles/445264/
Разница между async и defer у тега script https://wp-kama.ru/id_12151/raznitsa-async-defer.html
Как быстрее DOM построить: парсинг, async, defer и preload https://habr.com/ru/articles/338840/
https://learn.javascript.ru/first-steps https://habr.com/ru/companies/ruvds/articles/416375/
-
.call и .apply
- Знаю: Знаю что это, читал/изучал.
разница между .call и .apply
-
cookie, sessionStorage и localStorage
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Разница и ограничения cookie, sessionStorage и localStorage.
https://learn.javascript.ru/localstorage?ysclid=m4f9fptrr1171420958
-
let, var и const
- Знаю: Знаю что это, читал/изучал.
Разница между let, var и const
-
Обработка ошибок и исключений
- Знаю: Знаю что это, читал/изучал.
Обработка ошибок и исключений
-
Promise
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
-
Fetch
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
-
CORS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
CORS (Cross-Origin Resource Sharing, англ. «совместное использование ресурсов разных источников») — это стандарт, позволяющий предоставлять веб-страницам доступ к объектам сторонних интернет-ресурсов. Сторонним считается любой интернет-ресурс, который отличается от запрашиваемого протоколом, доменом или портом.
Доступ предоставляется по специализированным запросам. Интернет-ресурс, принимающий запрос, содержит список доверенных источников, которым разрешен доступ к объектам. Страница-источник запроса получает доступ, если входит в список доверенных источников. Для предоставления доступа всем сторонним интернет-страницам используется маска «*». Как появился стандарт
Первоначально для защиты информации была разработана «Политика одинакового источника» (Same-Origin Policy, SOP). Поддерживающий политику SOP веб-браузер сверяет комбинации сетевого протокола (например, https), точное имя домена и номер порта, чтобы разрешить доступ к ресурсам веб-страницы по запросам с другой страницы. Политика SOP не обязательна к применению, однако все современные веб-браузеры ее поддерживают.
Если веб-ресурсы интернет-источника соответствуют SOP, для доступа к ним из другого источника браузер должен поддерживать технологию Cross-Origin Resource Sharing. В 2006 году рабочая группа Консорциума Всемирной паутины (World Wide Web Consortium, W3C – организация, разрабатывающая интернет-стандарты) представила первый рабочий проект этой технологии. В 2014 году CORS был принят в качестве Рекомендации W3C. Структура Cross-Origin Resource Sharing
Методы CORS предназначены для управления доступом к дескрипторам (тегам) на веб-страницах в сети. Управляемые типы доступа подразделяются на три основных категории по работе с информацией сторонних ресурсов:
Доступ на запись — это доступ к ссылкам, заполнению веб-форм и переадресации на сторонние веб-страницы, т.е. на передачу информации в сторонний источник (веб-ресурс).
Доступ на вставку относится к категории доступа на считывание информации из стороннего источника. К этому типу принадлежат вставки в код дескрипторов audio, video, img, embed, object, link, script, iframe и другие элементы оформления веб-страниц. Структура подобных дескрипторов подразумевает самостоятельную инициацию перекрестных (cross-origin) запросов из сторонних источников. Все дескрипторы этой категории представляют низкий уровень угрозы безопасности, поэтому разрешены в веб-браузере по умолчанию.
Доступ на считывание — это дескрипторы, загружаемые с использованием фоновых методов вызова, таких как fetch(), технологии обмена данными Ajax и пр. Поскольку подобные дескрипторы могут содержать в теле любые участки кода (в том числе вредоносного), они запрещены в веб-браузерах по умолчанию.
При настройке веб-сайта механизм CORS позволяет выборочно блокировать различные категории доступа пользователя к ресурсам (запись, вставку или считывание).
https://yandex.cloud/ru/docs/glossary/cors https://habr.com/ru/companies/macloud/articles/553826/
-
NaN
- Знаю: Знаю что это, читал/изучал.
Что такое и особенности NaN
-
Event loop
- Знаю: Знаю что это, читал/изучал.
Event loop
https://habr.com/ru/companies/piter/articles/820027/ https://habr.com/ru/companies/macloud/articles/559902/
-
Дженерики/Generic Types
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
https://itanddigital.ru/bloghrconsulting/tpost/o9gce6b1b1-50-osnovnih-voprosov-i-otvetov-na-sobese
-
Компоненты в Vue
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
компоненты в Vue
-
Система двусторонней привязки
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Vue упрощает обработку пользовательского ввода и синхронизацию с помощью v-model директивы. Директива v-model обновляет модель при каждом изменении шаблона и обновляет шаблон при изменении модели.
Webpack — это модульный сборщик (bundler) с открытым исходным кодом, написанный на JavaScript.
Он берёт несколько скриптов JavaScript с их зависимостями и объединяет в файл, который используется браузером.
Преимущества Webpack:
ускоряет разработку, убирая необходимость постоянно перезагружать веб-страницу при изменениях в JS-файлах;
обеспечивает разделение кода на отдельные модули, которые можно переиспользовать внутри веб-приложения;
позволяет избежать проблем с перезаписью глобальных переменных;
поддерживает минификацию, то есть сокращение объёма кода без изменения его функциональности;
умеет работать с разными спецификациями модулей.
-
Vite
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Vite
-
Семантическая верстка
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
-
Псевдо-классы
- Знаю: Знаю что это, читал/изучал.
псевдо-классы
-
Медиазапросы
- Знаю: Знаю что это, читал/изучал.
Медиазапросы
-
animation,transition,transform
- Знаю: Знаю что это, читал/изучал.
animation,transition,transform
-
Псевдо-элементы
- Знаю: Знаю что это, читал/изучал.
Псевдо-элементы
::after, ::before
-
Селекторы и приоритеты стилей
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
CSS фреймворки
-
LESS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
LESS
-
SASS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
SASS
-
БЭМ
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
БЭМ
-
Bootstrap
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Bootstrap
-
Pure
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Pure
Навыки по разработке приложений для Android
Навыки по разработке приложений на iOS, для iPhone , iMac
https://help.ubuntu.com/kubuntu/desktopguide/ru/linux-basics.html https://habr.com/ru/articles/655275/
-
Shell/Bash
- Джун: Начальные/Поверхностные знания.
- Мидл: Средние знания. Можете объяснить суть и есть опыт применения..
- Сеньор: Продвинутые знания. Можете показать на примере, знаете нюансы и можете научить.
Командный интерпретатор в Linux подобных системах.
https://habr.com/ru/articles/47163/ https://ruvds.com/doc/bash.pdf https://proglib.io/p/bash-23-advanced-commands
Сетевые протоколы (IP, Transport, etc)
-
TCP/IP
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
TCP/IP
-
HTTP/HTTPS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
HTTP/HTTPS
-
DNS
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
DNS
Soft skills
-
Таим менеджмент
- Базовые понятия: Умеете планировать свою жизнь и дела на 1-2 дня, есть абстрактные цели.
- Применяете методики: Знаете что такое VUCA, BANI или другой метод и используете его. Планируете свои дела на каждую неделю. Ставите цели минимум на 1 год. Переодический проводите ретроспективу и корректировку долгосрочных планов.
- Управляете временем: Время работает на вас. Вы наставник или можете быть им.
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://presium.pro/blog/what-is-emotional-intelligence https://journal.tinkoff.ru/emotional-intelligence/
-
Коммуникации
- Начальный уровень: Способность эффективно слушать и понимать других участников коммуникации, ясное и понятное выражение своих мыслей и идей, умение задавать вопросы и запрашивать уточнения для полного понимания задач и требований.
- Средний уровень: Грамотное и уверенное выступление перед аудиторией различного уровня сложности, адаптация к различным коммуникационным стилям и предпочтениям участников коммуникации, навыки убеждения и влияния на принятие решений и согласование с разными заинтересованными сторонами, способность конструктивно обрабатывать фидбэк и критику.
- Высокий уровень: Эффективное управление конфликтами и разрешение спорных ситуаций в коммуникации, умение адаптировать свой стиль коммуникации к разным культурным контекстам и международным командам, умение вести эффективные совещания и встречи, учитывая потребности и цели всех участников.
Устная, письменна, и чтение.
- Английский
Методы достижения целей
Бизнес-анализ
-
Оформление ТЗ.
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Способен выполнить полный цикл бизнес-анализа, включая адекватное управление требованиями
-
Планирование
- Знаю: Знаю что это, читал/изучал.
- Понимаю: Понимаю (знаю достоинства и недостатки) и был опыт применения.
Планирование