Index

[A][B][C][D][E][F][G][I][J][K][L][M][N][O][P][Q][R][S][T][U][V][W][X]

A

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

B


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++
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

D

DAG (directed acyclic graph)
DCG (directed cyclic graph)
dead code
debugging dynamic code
decision node2nd
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 languages2nd3rd
  feedback from
  loan server example
    code
    testing
  vs. static typing

E

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

F

Feathers, Michael2nd
fetch action, loan institute example
fields, updating all references to
Flickr
framework frenzy
framework leakage
freezing parts of code
functional tests

G

Game Neverending
ghost code
gold-plating, avoiding
Graphviz
grouping node

I

IDE (integrated development environment)
  automated refactorings
  extracting new interfaces
  Introduce Parameter
if statements
immediate solutions2nd
immutable objects
implicit branch
imposed technical debt
improvement projects
inheritance
inherited debt
inline method refactoring
integrated development environment.
    See IDE.
interest on technical debt2nd
Interface Segregation Principle.
    See ISP.
interfaces
  creating
  extracting new from existing
intermediate objective
Introduce Indirection refactoring
isolation, working in
ISP (Interface Segregation Principle)

J

Java
Java Servlet API
Java Virtual Machine.
    See JVM.
JavaScript
JSON (JavaScript Object Notation)
just-in-time extraction
JVM (Java Virtual Machine)

K

Kanban
key-value store

L

lactic acid comparison
large-scale changes2nd.
    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)

M

macro-level tests
main branch
Martin, Robert C.2nd
medium-scale changes2nd
methods
  length of code for
  updating all references to
micro-level tests
mimic replacements

N

Naive Approach2nd
  advantage of
  defined
  overview2nd
  simplicity and
namespaces
.NET
Node.js
nondestructiveness
not-invented-here syndrome

O

OCP (Open-Closed Principle)
one-step-at-a-time process2nd
one-way code
over-analyzing changes
ownership

P


patch2nd
pauses
payment on technical debt
perfect vs. good enough
performance tests
pet projects
projects, separating code into
proudly-found-elsewhere syndrome2nd
pull systems
“Push down methods to subclass” refactoring
Python

Q

QA department

R

reality check
red-green-refactor cycle2nd
refactoring
  automated2nd
  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.
Ruby2nd

S

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 changes2nd
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 languages2nd
step size on Mikado Graph
structural improvements
  combining
  focus on
super-interfaces
synchronization
system stability

T

TDD (test-driven development)
technical goals
templated change
temporary shelter pattern2nd
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

U

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

V


vendor lock-in
visitor pattern

W

Whist
whiteboards
working condition
  keeping code in2nd
  reverting to
Working Effectively with Legacy Code2nd

X

XML configuration, replacing with code

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset