Links - gusenov/software-design-patterns GitHub Wiki

IF

Books

Interface

Domain-Driven Design

Idioms

SOLID

IoC, DI

MVC

MVP

MVVM

MVU

Flux

Redux

Observing

FSM

C++

Python

Go

Java

JavaScript

TypeScript

Android

iOS

Web

Wikipedia

Game

API

SOA

Back end

Microservices

Serverless

Messaging

Java

J2EE

Node.js

Microsoft

Collections

Press

Stack Overflow

Software Engineering Stack Exchange

Enterprise

Courses

Specification

Concurrency

wiki.c2.com

Data transfer object (DTO)

"Uncle Bob" Martin

Talk

Blogs

  • Архитектура ИТ-решений (Максим Смирнов)
  • Oleg Knyazev
    • Про инкрементальную архитектуру (эволюционная архитектура (evolutionary architecture / design)) by Oleg Knyazev
      • все нынче знают, как нужно разрабатывать софт: stories, спринты, continuous integration (лучше — delivery), рефакторинг, тесты
      • Начинаем с нуля, делаем одну маленькую стори за другой, не делаем больше, чем нужно для текущей стори.
      • набрасывать нужно не структуру системы, которую мы собрались строить, а структуру системы на текущую стори. Максимум — на несколько стори вперед. Не более того.
      • строгое следование agile-практикам, вроде выпуска версии каждую итерацию и прочего, дало эффекты
      • Лучше обдумать самый малой кусок, какой только возможно обдумать. Ведь это гораздо проще сделать!
      • Просто не нужно брать слишком много за раз. В этом мало смысла. Хотя бы потому, что весь “придуманный” код все равно не удастся написать за один подход. Все равно придется обдумывать заново, когда дойдет до этих фич. Если вообще дойдет.
      • Иногда кажется, что новый дизайн принципиально не совместим со старым. Отсюда и появляются сказки про “неделю рефакторинга”. Но это не совсем так. Вот есть у нас архитектура А, хотим прийти к архитектуре Б. Можно соединить их прямой линией — сделать все за один шаг, уйдя в рефакторинг с головой. А можно соединить ломаной линией из кучи маленьких сегментов: выделили класс, перенесли метод, добавили делегирование и т.п. — все те маленькие приемы
      • мы каждый раз добавляем по чуть-чуть. Каждый раз работаем с маленьким кусочком системы. И когда мы смотрим на маленький кусочек, то он обычно понятен.
      • в классическом TDD есть обязательная фаза рефакторинга. Сделал, чтобы работало — сделай, чтобы было красиво. Такой подход нужно применить не только с TDD.
      • Суть инкрементальной архитектуры в том, чтобы не заглядывать далеко вперед. Делайте то, что нужно сегодня или через неделю, не то, что потребуется через полгода. Не делайте никаких предположений о том, что будет через полгода – все равно не угадаете.
      • сложные работающие системы вырастают из простых работающих систем

LOLZ

Diagrams

Most popular patterns

Creational patterns

Builder

Factory

Behavioral patterns

Command