НОМЕНКЛАТУ́РА
НОМЕНКЛАТУ́РА - Совокупность или перечень употребляемых в какой-н. специальности названий, терминов.
СИГНАТУРА функции — характеристическая часть определения функции в программировании
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
SP - анализировать git log ....file
, чтобы понять почему меняется класс,
для этого нужен понятная история логов
OCP - в PR не должно быть красного (удалений/изменений)
LSP - бот?
ISP - git log --grep ""
DIP - бот
https://www.youtube.com/watch?v=3OgbQOsW61Y
CLEAN CODE
MVP - minimum viable product ЖОПП - Жизненный опыт Получаемый Практикой
АРХИТЕКТУРНЫЙ ЦИКЛ
MoSCoW требования: M - Must o S - Should C - Could o W - Won`t
Обеспечить отказоустойчивость, блокируя цикл при первой же неудаче. И возобновляя цикл только в том случае, когда все звенья снова работают.
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
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"
Идемпоте́нтность (лат. idem — тот же самый + potens — способный) — свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом