[A][B][C][D][E][F][G][I][J][K][L][M][N][O][P][Q][R][S][T][U][V][W][X]
abstraction
acceptable debt
as defensible space
acceptable debt
hitting market window
reflection and learning
requirements from stakeholders
waiting for abstraction
acceptance tests
ADP (Acyclic Dependencies Principle)
Agile Software Development, Principles, Patterns, and Practices
ambition level
API (application programming interface)
apply action, loan institute example
approve action, loan institute example
best practices.
See good practices.
Big Bang changes
Box, George E. P.
“Boy Scout Rule”
broken window syndrome
brownfield development
business goals
C/C++
C#
CCP (Common Closure Principle)
check marks on Mikado Graph
checking in often
checking-nodes mode for Mikado Graph
Clean Code
cleanup commits
co-driver
code bashing
code of conduct
code reviews
cohesion principles
collaboration
collective code ownership
commits
defined
separating cleanups
Common Closure Principle.
See CCP.
Common Reuse Principle.
See CRP.
communication
advantages of Mikado Method
bad debt and
team difficulties
with non-technical people
compiler
composite pattern
composition over inheritance
concepts
experiments
undoing changes
visualization
conditionals, avoiding
consistency first, then improvements
corner-cutting
coupling principles
CRP (Common Reuse Principle)
cURL tool
“curse of knowledge”
cyclic dependencies
DAG (directed acyclic graph)
DCG (directed cyclic graph)
dead code
debugging dynamic code
decision node, 2nd
dependencies
arrows on Mikado Graph
cyclic dependencies
moving code in direction of
packages and
side effect–free programming
dependency injection
Dependency Inversion Principle.
See DIP.
deployable component
DIP (Dependency Inversion Principle), 2nd
directed acyclic graph.
See DAG.
directed cyclic graph.
See DCG.
distributed teams
divide-and-conquer method
driver, pair programming
dynamically typed languages, 2nd, 3rd
feedback from
loan server example
code
testing
vs. static typing
eager compilers
empirical control systems
Empirical Model-Building and Response Surfaces
errors, finding
executable component
executable specifications
execution mode for Mikado Graph
experiments
defined
guidelines for
exploration mode for Mikado Graph
extract method refactoring
Extreme Programming
Feathers, Michael, 2nd
fetch action, loan institute example
fields, updating all references to
Flickr
framework frenzy
framework leakage
freezing parts of code
functional tests
Game Neverending
ghost code
gold-plating, avoiding
Graphviz
grouping node
IDE (integrated development environment)
automated refactorings
extracting new interfaces
Introduce Parameter
if statements
immediate solutions, 2nd
immutable objects
implicit branch
imposed technical debt
improvement projects
inheritance
inherited debt
inline method refactoring
integrated development environment.
See IDE.
interest on technical debt, 2nd
Interface Segregation Principle.
See ISP.
interfaces
creating
extracting new from existing
intermediate objective
Introduce Indirection refactoring
isolation, working in
ISP (Interface Segregation Principle)
Java
Java Servlet API
Java Virtual Machine.
See JVM.
JavaScript
JSON (JavaScript Object Notation)
just-in-time extraction
JVM (Java Virtual Machine)
lactic acid comparison
large-scale changes, 2nd.
See also loan institute example.
latent code pattern
“lean on the compiler”
Lean Software Development
leaves on Mikado Graph
lifespan of Mikado Graph
lightweight process
Liskov Substitution Principle.
See LSP.
load tests
LSP (Liskov Substitution Principle)
macro-level tests
main branch
Martin, Robert C., 2nd
medium-scale changes, 2nd
methods
length of code for
updating all references to
micro-level tests
mimic replacements
Naive Approach, 2nd
advantage of
defined
overview, 2nd
simplicity and
namespaces
.NET
Node.js
nondestructiveness
not-invented-here syndrome
OCP (Open-Closed Principle)
one-step-at-a-time process, 2nd
one-way code
over-analyzing changes
ownership
patch, 2nd
pauses
payment on technical debt
perfect vs. good enough
performance tests
pet projects
projects, separating code into
proudly-found-elsewhere syndrome, 2nd
pull systems
“Push down methods to subclass” refactoring
Python
reality check
red-green-refactor cycle, 2nd
refactoring
automated, 2nd
before adding functionality
patterns
concurrent goals with common prerequisites
creating API
exploring options
extracting preparatory prerequisites
grouping nodes for common prerequisites
grouping repeated set of prerequisites as templated change
merge, reorganize, split
moving code directly to new package
moving code gradually to new package
splitting graph
using temporary shelter
refactor relentlessly
scope of
large-scale
medium-scale
overview
small-scale
when to draw graph
sharing work
chart displaying options for
distributed teams
mob programming
overview
pair programming
single developer
teams
teams
combining improvements and features
difficulties
focus tactics
focusing on features
focusing on structural improvements
overview
references, updating all
reflecting on work
reflection (code)
regression testing
regular expressions
REP (Reuse-Release Equivalence Principle)
“Replace conditional with polymorphism (strategy)” refactoring
repository
adding changes to
commits
defined
separating cleanups
using only one
restructuring map
Reuse-Release Equivalence Principle.
See REP.
revision control system.
See VCS.
Ruby, 2nd
SAP (Stable Abstractions Principle), 2nd
scrapheap challenge
scripting languages
Scrum
SDP (Stable Dependencies Principle), 2nd
seams in code
search refactoring
shelving
side effect–free programming
signaling others on team
simplicity
single developer
Single Responsibility Principle.
See SRP.
small-scale changes, 2nd
source control module.
See VCS.
split-dependency arrow
SRP (Single Responsibility Principle)
Stable Abstractions Principle.
See SAP.
Stable Dependencies Principle.
See SDP.
staff turnover
stakeholders
stashing
state of work, remembering
statically typed languages, 2nd
step size on Mikado Graph
structural improvements
combining
focus on
super-interfaces
synchronization
system stability
TDD (test-driven development)
technical goals
templated change
temporary shelter pattern, 2nd
test-driven development.
See TDD.
Theory of Constraints.
See ToC.
thinking models
empirical control systems
pull systems
Theory of Constraints
third-level tactic
tips
focusing on goal
following flow of code
one step at a time
reflecting on work
remembering state of work
simplicity
visualization
ToC (Theory of Constraints)
too-clever code
Toyota Production System
transitive information
trial and error approach
ubiquitous language
UML (Unified Modeling Language)
unavoidable debt
chaotic environment
demand changes
external regulations
inherited debt
staff turnover
Unified Modeling Language.
See UML.
unprofessionalism
user story
vendor lock-in
visitor pattern
Whist
whiteboards
working condition
keeping code in, 2nd
reverting to
Working Effectively with Legacy Code, 2nd