Software engineering body of knowledge
This document maps the core concerns of software engineering — the craft foundations that precede specialized engineering disciplines — to the blueprint ecosystem.
Guide · Updated · Source
How software engineering relates to PDLC and SDLC: SE is embedded in every SDLC phase and enables PDLC learning loops through prototypes, measurements, and sustainable change. See Software engineering ↔ SDLC ↔ PDLC bridge for the full mapping.
Paradigms: Deeper paradigm guides are indexed in paradigms/.
Patterns: Deeper pattern catalogs are indexed in patterns/.
1. Programming paradigms
| Paradigm | Core principles | Strengths | Best fit |
|---|---|---|---|
| Object-oriented (OOP) | Encapsulation, abstraction, polymorphism, messaging between objects; identity + state + behavior | Rich domain modeling; boundaries around invariants; replaceable implementations behind interfaces | Business domains with stable nouns; UI components; plugin architectures |
| Functional (FP) | Pure functions, immutability, explicit effects, composition, referential transparency | Easier reasoning about concurrency; localized testing; algebraic data + transformations | Data pipelines, compilers, financial calculations, parallel maps/reductions |
| Reactive | Data flows over time; declarative composition of streams; backpressure and cancellation as first-class | UI and network-driven systems; combining many async sources; resilience to bursty load | Event-heavy services, real-time dashboards, stream processing edges |
| Procedural | Sequencing, procedures/subroutines, structured control flow, minimal abstraction ceremony | Low cognitive overhead; predictable resource use; straightforward tooling | Scripts, firmware bring-up, performance kernels, simple batch jobs |
Composition note: Production systems are usually multi-paradigm — e.g., FP core for transformations with OOP boundaries for IO and frameworks. Prefer one dominant style per module for readability.
2. Data structures and algorithms
Fundamental data structures
| Structure | Typical operations | Time notes (big-O, typical) | When to choose |
|---|---|---|---|
| Array / vector | Index access, contiguous memory | O(1) access; O(n) insert/delete in middle | Known size or amortized growth; cache-friendly scans |
| Linked list | Insert/delete at iterator | O(1) splice if node known; O(n) search | Frequent middle inserts with stable iterators; avoid for cache-sensitive scans |
| Stack / queue / deque | LIFO / FIFO / both ends | O(1) push/pop (amortized for dynamic arrays) | DFS, BFS, schedulers, undo stacks, work queues |
| Hash map / dictionary | Key → value | O(1) average lookup; O(n) worst case (poor hash / attack) | Membership, dedup, memoization, indexes |
| Tree (BST, balanced) | Ordered keys, range queries | O(log n) search/insert in balanced trees | Ordering + moderate mutation; avoid unguarded BST on adversarial input |
| Heap (priority queue) | Min/max retrieval | O(log n) push/pop; O(1) peek | Schedulers, top-K, event ordering |
| Trie / prefix tree | Prefix search | O(key length) operations | Autocomplete, IP routing tables, lexical structures |
| Graph (adjacency list) | Traverse, shortest paths | O(V+E) BFS/DFS; varies for shortest path algo | Dependencies, networks, state machines |
| Bloom filter | Probabilistic membership | O(k) per query; space-efficient | Cache negatives, pre-filters (accept false positives) |
| Bitmap / bitset | Dense sets of integers | Very compact; word-parallel ops | Feature flags at scale, inverted indexes |
Algorithm complexity and selection
| Concern | What to measure | Rule of thumb |
|---|---|---|
| Asymptotic class | How cost grows with n | Prefer O(n) or O(n log n) for large n unless constants dominate (small fixed n) |
| Constants and memory | Cache lines, allocations, GC pressure | Hot loops: prefer contiguous memory, fewer pointers, less allocation |
| Stability | Equal keys keep order | Important for multi-key sorts and reproducible pipelines |
| Determinism | Same input → same output path | Needed for tests, replay, and some compliance regimes |
| Amortized vs worst | Dynamic arrays, hash tables | Document worst-case hazards (rehash storms, adversarial keys) |
When complexity dominates: Profile first for measured hotspots; optimize the inner loop or cross-service chatter, not speculative abstractions.
3. Design patterns
GoF — creational
| Pattern | Intent | When to use | Watch-outs |
|---|---|---|---|
| Abstract Factory | Create families of related objects without concrete classes | Swappable UI/toolkits, multi-vendor integrations | Factory explosion; test doubles multiply |
| Builder | Construct complex objects step-by-step | Many optional fields; readable construction for nested configs | Not every POJO needs a builder |
| Factory Method | Let subclasses decide which class to instantiate | Framework hooks; plugin points | Indirection cost; discoverability |
| Prototype | Clone exemplars instead of subclassing | Expensive construction; runtime variation | Deep copy vs shallow copy bugs |
| Singleton | One instance globally | (Rarely justified) — prefer DI and explicit scopes | Hidden dependencies; test pain; concurrency |
GoF — structural
| Pattern | Intent | When to use | Watch-outs |
|---|---|---|---|
| Adapter | Make an interface usable where another is expected | Legacy/SDK boundaries | Leaky abstractions if adapter does too much |
| Bridge | Decouple abstraction from implementation | Multiple dimensions of variation (e.g., renderer × OS) | Upfront design cost |
| Composite | Tree structures; uniform treatment of part/whole | UI trees, ASTs, org charts | Type safety vs instanceof checks |
| Decorator | Add responsibilities dynamically | Cross-cutting per-instance behavior | Ordering bugs; debugging stack depth |
| Facade | Simplify a subsystem interface | Onboarding, migration slices | God facade anti-pattern |
| Flyweight | Share intrinsic state across many objects | Huge numbers of similar icons/tokens | Thread safety; identity semantics |
| Proxy | Surrogate controls access | Lazy load, access control, remote stub | Latency; stale caches |
GoF — behavioral
| Pattern | Intent | When to use | Watch-outs |
|---|---|---|---|
| Chain of Responsibility | Pass request along a chain until handled | Middleware, event pipelines | Hard-to-trace flows |
| Command | Encapsulate a request as an object | Undo/redo, macros, job queues | Command proliferation |
| Interpreter | Grammar + interpretation | Small DSLs | Performance; prefer parser generators for large grammars |
| Iterator | Sequential access without exposing internals | Collections, streams | Concurrent modification hazards |
| Mediator | Centralize complex many-to-many collaboration | Chat rooms, dialog orchestration | Mediator becomes a god object |
| Memento | Capture and restore object state | Snapshots, undo stacks | Memory cost; encapsulation leaks |
| Observer | Notify dependents of changes | Model–view, domain events | Ordering; memory leaks from strong refs |
| State | Object behavior changes with internal state | Protocols, game AI, workflow steps | State class sprawl |
| Strategy | Interchangeable algorithms | Pricing rules, parsers, validators | Selection logic at call sites |
| Template Method | Fixed skeleton; subclasses fill steps | Frameworks with extension points | Inheritance rigidity |
| Visitor | Operations over a stable class hierarchy | AST walkers, document export | Adding types breaks visitors |
Enterprise integration (representative)
| Pattern | Intent | When to use |
|---|---|---|
| Message Channel | Decouple producers/consumers | Async handoffs; burst absorption |
| Message Router | Route based on content/rules | Multi-tenant pipelines; versioned consumers |
| Message Translator | Transform between formats | Legacy + modern service boundaries |
| Publish-Subscribe | Broadcast to many subscribers | Event notifications; fan-out |
| Competing Consumers | Scale consumption horizontally | Work queues; backpressure with prefetch tuning |
| Idempotent Receiver | Safe retries | At-least-once messaging stacks |
4. Principles
SOLID
| Principle | Meaning in practice | Typical violation |
|---|---|---|
| S — Single Responsibility | One reason to change per module | “Utils” classes mixing IO, parsing, and business rules |
| O — Open/Closed | Extend behavior without modifying stable core | Copy-paste variants instead of strategy/plugin |
| L — Liskov Substitution | Subtypes honor supertype contracts | Throwing on “unsupported” overrides; stricter preconditions |
| I — Interface Segregation | Small, focused interfaces | Fat interfaces forcing dummy implementations |
| D — Dependency Inversion | Depend on abstractions; details plug in | New-ing concrete infrastructure in domain logic |
Other core principles
| Principle | Essence | Application |
|---|---|---|
| DRY | Each piece of knowledge has a single authoritative representation | Deduplicate business rules; do not merge accidental coincidence |
| KISS | Prefer the simplest design that meets forces | Resist framework gravity for toy problems |
| YAGNI | Do not build speculative generality | Add hooks when a second real use appears |
| Separation of concerns | Partition UI, domain, infrastructure | Boundaries align with change rates and ownership |
| Composition over inheritance | Build behavior from parts | Inheritance for is-a taxonomies; composition for has-a behavior wiring |
5. Clean code
Naming
| Practice | Guidance |
|---|---|
| Reveal intent | Names answer why and what, not encoding details (customerId, not str1) |
| Consistent vocabulary | One word per concept (fetch vs get vs load — pick one domain lexicon) |
| Avoid mental mapping | No i, j, k except tight loops; no gratuitous abbreviations |
| Searchable names | Length scales with scope — globals and exports deserve longer names |
Functions
| Practice | Guidance |
|---|---|
| Small and focused | One level of abstraction per function; early returns over deep nesting |
| Few parameters | Group related args into types/records; default to pure inputs over hidden globals |
| Command/query | Prefer functions that either do something or answer something — surprises break readers |
| Errors are part of the API | Use result types or exceptions consistently; document recoverability |
Error handling
| Practice | Guidance |
|---|---|
| Fail fast at boundaries | Validate inputs; convert external errors to domain-meaningful results |
| Preserve context | Chain causes; add correlation IDs in distributed systems |
| No empty catches | Log or translate — silence hides incidents |
| Resource safety | try/finally, using, RAII — leaks are defects |
Formatting and structure
| Practice | Guidance |
|---|---|
| Vertical density | Related lines together; blank lines separate ideas, not every line |
| File organization | Public API at top or bottom — pick team convention and automate with formatter |
| Comments | Explain why and invariants — not what the next line obviously does |
Code review practices
| Practice | Guidance |
|---|---|
| Checklist balance | Correctness, security, performance (where relevant), readability, tests |
| Small diffs | Easier review correlates with fewer defects |
| Teach in reviews | Prefer questions and references over tone |
| Automate the boring | Linters/formatters own style debates |
6. Concurrency and parallelism
| Topic | Key ideas | Failure modes |
|---|---|---|
| Threads | Shared memory; preemptive scheduling | Data races, deadlocks, priority inversion |
| Async / await | Cooperative tasks; non-blocking IO | Lost errors, unbounded queues, forgotten cancellation |
| Actors | Mailboxes; no shared mutable state by default | Mailbox backlog; distributed failure handling |
| CSP (channels) | Synchronous or buffered communication | Deadlock rings; channel leaks |
| Parallel collections | Fork-join, SIMD-friendly loops | Split imbalance; false sharing |
| Race conditions | Read/write ordering not what intuition says | Heisenbugs; flaky tests |
| Synchronization primitives | Locks, semaphores, barriers, RW locks, condition variables | Lock ordering discipline; missed signals |
| Lock-free / atomic | Compare-and-swap structures | ABA problem; subtle memory ordering — expert territory |
Design guidance: Prefer immutable data across threads, message passing across services, and bounded queues. Measure contention before micro-optimizing locks.
7. Networking fundamentals
| Topic | Essence | Practical notes |
|---|---|---|
| OSI vs TCP/IP | Layered responsibility — physical through application | TCP/IP is the de facto stack engineers implement against daily |
| HTTP/HTTPS | Request/response, verbs, status codes, headers, caching | Idempotency of GET/PUT vs POST; cache invalidation discipline |
| DNS | Name → record resolution | TTLs affect failover; understand CNAME vs A/AAAA |
| TLS | Confidentiality + integrity + authentication | Terminate thoughtfully; certificate rotation; minimum protocol/cipher policy |
| WebSocket | Bidirectional channel over HTTP upgrade | Heartbeats; backpressure; auth on upgrade |
| REST basics | Resources, statelessness, uniform interface | HATEOAS rarely fully adopted; hypermedia when discoverability matters |
8. Version control (Git)
| Workflow | Branching model | Strengths | Trade-offs |
|---|---|---|---|
| Trunk-based | Short-lived branches; frequent integration to main | Fast feedback; fewer merge storms | Requires discipline, feature flags, strong CI |
| GitFlow | develop, release, hotfix, feature branches |
Explicit release stabilization lanes | Branch overhead; slower integration for small teams |
| GitHub Flow | Feature branches off main; PR + deploy from main | Simple; aligns with PR review culture | Needs strong tests and safe deploys |
| Practice | Guidance |
|---|---|
| Merging vs rebasing | Merge preserves history graph; rebase linearizes feature work — agree team defaults for shared branches |
| Commit conventions | Imperative subject; scope optional; link issues; separate mechanical refactors from behavior change — Forge SDLC teams: branching + commit body/trailers for agent/search-friendly history in Git branching and commit conventions (Forge) |
| Small commits | Bisect-friendly history; easier cherry-pick and revert |
9. Debugging and profiling
| Area | Systematic approach | Tools (examples) |
|---|---|---|
| Reproduction | Minimize steps; capture data (logs, seeds, versions); binary search the timeline | Record/replay frameworks where available |
| Hypotheses | Change one variable; predict outcome; falsify quickly | Scientific method beats random tweaks |
| Profiling (CPU) | Sample or instrument hotspots; attribute time by call stack | perf, Intel VTune, language profilers |
| Profiling (alloc) | Track allocation sites; object lifetimes | Heap snapshots, allocation trackers |
| Concurrency | Thread dumps; lock contention views; race detectors | TSan, debuggers, tracer bullets |
| Performance analysis | Define SLO-related scenarios; measure p50/p95/p99 | Load drivers, A/B in shadow traffic |
| Memory analysis | Leak suspects: growth over time; dominator trees | Heap dumps, sanitizer builds |
10. Competencies
| Competency | Description |
|---|---|
| Computational thinking | Decomposing problems, recognizing patterns, choosing structures and algorithms |
| Paradigm fluency | Selecting and mixing OOP/FP/reactive/procedural idioms appropriately |
| API design | Clear contracts, versioning discipline, error models, documentation |
| Quality reflex | Testing mindset, review discipline, static analysis literacy |
| Concurrency literacy | Reasoning about races, deadlocks, backpressure, and failure in parallel work |
| Operational awareness | Logging, metrics, tracing hooks that make production diagnosable |
| Performance judgment | Knowing when to measure, optimize, or deliberately not optimize |
| VCS craftsmanship | Branch hygiene, readable history, conflict resolution, release alignment |
11. External references
| Topic | URL | Why it is linked |
|---|---|---|
| SWEBOK v3 (IEEE Computer Society) | https://www.computer.org/education/bodies-of-knowledge/software-engineering | Broad SE knowledge areas aligned to industry practice |
| Clean Code (Robert C. Martin) | https://www.pearson.com/en-us/subject-catalog/p/Clean-Code-A-Handbook-of-Agile-Software-Craftsmanship/P200000003998/9780132350884 | Naming, functions, and refactoring craft |
| Design Patterns (Gamma, Helm, Johnson, Vlissides) | https://www.pearson.com/en-us/subject-catalog/p/Design-Patterns-Elements-of-Reusable-Object-Oriented-Software/P200000003445/9780201633612 | Canonical pattern catalog and vocabulary |
| The Pragmatic Programmer (Hunt & Thomas) | https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/ | Habits, tooling, and trade-off thinking |
| Structure and Interpretation of Computer Programs (SICP) | https://mitpress.mit.edu/9780262020771/structure-and-interpretation-of-computer-programs/ | Foundational CS — abstraction, recursion, state, interpreters |
| Enterprise Integration Patterns (Hohpe & Woolf) | https://www.enterpriseintegrationpatterns.com/ | Messaging and integration design language |
Keep project-specific engineering standards in docs/development/ and architecture decisions in docs/adr/, not in this file.