Cacher is the code snippet organizer for pro developers

НОМЕНКЛАТУ́РА

НОМЕНКЛАТУ́РА - Совокупность или перечень употребляемых в какой-н. специальности названий, терминов.

СИГНАТУРА функции — характеристическая часть определения функции в программировании

PROGRESSIVE ENHANCEMENT - поддерживать каждую мелочь

GRACEFUL DEGRADATION - отказоустойчивость, поддерживать то, что поддерживается (css без префиксов, без теней в IE)

КАНАЛ - модель межпроцессного взаимодействия и синхронизации через передачу сообщений.

DISPATCHER (диспетчер) - функция, которая дополняет обьект

IMMUTABLE (неизменяемый) - объект,состояние которого не может быть изменено после создания.

МОНа́ДА — это абстракция линейной цепочки связанных вычислений. Монады позволяют организовывать последовательные вычисления.

КОМПОЗИЦИЯ - lavish language

ДИСТРУКТОРЫ - {props} = this Spread [a, ...arr, b] Rest (...arr) => {}

Интерфе́йс (англ. interface) — общая граница между двумя функциональными объектами, требования к которой определяются стандартом[1];

ТРУДНАЯ ЦЕЛЬ — это вызов, который требует упорства и изобретательности. Даже если такая цель не будет достигнута полностью, результат будет гораздо выше консервативных ожиданий.

РЕКУРСИЯ - function repeat(func) { if (func() !== undefined) { return repeat(func); } }

Экспат - чел, кот. Бросил родину и живет за ее пределами

Дихотомия - раздвоенность

Концепции ООП

АБСТРАКЦИЯ* - в объектно-ориентированном программировании — это придание объекту характеристик, которые чётко определяют его концептуальные границы, отличая от всех других объектов.

ИНКАПСУЛЯЦИЯ - (лат. en capsula) называется упаковка данных и/или функций в единый компонент.

ПОЛИМОРФИЗМ - способность функции обрабатывать данные разных типов

НАСЛЕДОВАНИЕ — механизм языка, позволяющий описать новый класс на основе уже существующего (родительского, базового) класса или интерфейса. Потомок может добавить собственные методы и свойства, а также пользоваться родительскими методами и свойствами. Позволяет строить иерархии

Принципы

ПРИНЦИП ИНВЕРСИИ ЗАВИСИМОСТЕЙ - код должен зависить от абстракций, а не от конкретных классов

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

Приемы в программировании

Корень N-ой степери: 27^1/3 = 3

Оркестрация контейнерами Федерация

80/20

АКУЛА-ВОЛК-СЛОН

• Акула - немедленное
• волк - если не сделать, то сожрет тебя
• слон - задача, которую делить

RED-GREEN-REFACTOR

• красный - что бы яхотел, чтобы код делал (тесты)
• зелёный - как написалть код, чтобы он сделал это
• рефактор - как мне сделать этот код лучше

https://www.youtube.com/watch?v=i08A2uTDoa8

ПЛАНИРОВАНИЕ В ДЕТАЛЯХ

[]      []         []   3 группировка по виду деятельности
     []         []      4 выделить минимальные цели
----------------------> время
[] ? ↿↾ [] ? [] ↿↾ []   1 всё, что приходит в голову по задаче,
     []      [] []      2 задачи, которые происходят в одно время
     []         []        строятся вертикально

https://www.youtube.com/watch?v=i08A2uTDoa8

5 ШАПОЧЕК

• Белая - общий вид
• Синяя - скрум, чтобы не откланялись
• Зеленая - генератор идей
• Черная - критик
• Желтая - успокоить

GIT &

SOLID.

S - SRP[5]
Принцип единственной ответственности (The Single Responsibility Principle) Каждый класс должен иметь одну и только одну причину для изменений. O - OCP[6]
Принцип открытости/закрытости (The Open Closed Principle) «программные сущности … должны быть открыты для расширения, но закрыты для модификации.» L - LSP[7]
Принцип подстановки Барбары Лисков (The Liskov Substitution Principle) «объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.» См. также контрактное программирование. Наследующий класс должен дополнять, а не изменять базовый.

I - ISP[8]
Принцип разделения интерфейса (The Interface Segregation Principle) «много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»[9] D DIP[10] Принцип инверсии зависимостей (The Dependency Inversion Principle) «Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»[9]

KISS Keep it simple, stupid

ACID

• Atomicity — Атомарность (никакая транзакция не будет зафиксирована в системе частично)
• Consistency — Согласованность (каждая успешная транзакция по определению фиксирует только допустимые результаты)
• Isolation — Изолированность (каждая успешная транзакция по определению фиксирует только допустимые результаты, есть режимы, не полностью изолирующие транзакцию)
• Durability — Прочность (изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу)

SP - анализировать git log ....file, чтобы понять почему меняется класс, для этого нужен понятная история логов OCP - в PR не должно быть красного (удалений/изменений) LSP - бот? ISP - git log --grep "" DIP - бот

https://www.youtube.com/watch?v=3OgbQOsW61Y

CLEAN CODE

• Functionality
• Maintainability
• Readability

MVP - minimum viable product ЖОПП - Жизненный опыт Получаемый Практикой

АРХИТЕКТУРНЫЙ ЦИКЛ

• RACI (Stakeholders)
• Responsible - что-то делают
• Accountable - прин. решения
• Consulted - которые консультируются (прин. решения)
• Informed - информированные
• Goals
• Requirements
• Architecture
• System

MoSCoW требования: M - Must o S - Should C - Could o W - Won`t

Circulit Breaker Pattern

Обеспечить отказоустойчивость, блокируя цикл при первой же неудаче. И возобновляя цикл только в том случае, когда все звенья снова работают.

Книги

Algorythms to leave by Pattern for fault tolerant software

Библиотеки

AsyncStorage Lodash async.js, momentjs и функции throttle, debounce, deffer

Цитаты

Компонент и его логика должны помещаться голову среднего программиста

Явное - лучше неявного. Стоймость написания кода - разы меньше стоймости его поддержки

The Junior hardcodes it. The medior creates an abstraction factory for it. The senior hardcodes it

Special case styles:

Camel case

"TheQuickBrownFoxJumpsOverTheLazyDog"

Snake case

"The_quick_brown_fox_jumps_over_the_lazy_dog"

Kebab case

"The-quick-brown-fox-jumps-over-the-lazy-dog"

Studly caps

e.g. "tHeqUicKBrOWnFoXJUmpsoVeRThElAzydOG"

Свойства Архитектуры REST

• Производительность
• Масштабируемость
• Простота унифицированного интерфейса
• Открытость компонентов
• Прозрачность связей
• Переносимость компонентов
• Устойчивость к отказам

Идемпоте́нтность (лат. idem — тот же самый + potens — способный) — свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом