Final Prep Flashcards
When did Agile really start taking off
about 13 years ago (2005)
before, we used waterfall
Uncle Bob Video:
smaller iterations and constant feedback (like a RD in writing)
don’t let yourself get blocked by anything
delay decisions with good architecture. make business rules early and defer everything else
no grand redesigns. just clean up a little each time
say no to things. choose good code over meeting deadlines
When did Test-Driven Development (TDD) really start taking off?
8 years ago
you don’t want to be good at debugging
tests bring enthusiasm and sense of accomplishment
continuous stream of quality documentation
cost and risk of making changes goes way down. code is sensitive on the one-bit level. other things in life aren’t like this
– TDD is like double-entry bookkeeping in accountancy
tests must be automated
“decoupled code”
testable code
INVEST - [ I ]
User Stories.
Independent
not always possible but good thing to seek
INVEST - [ N ]
User Stories.
Negotiable
conversation to be had
INVEST - [ V ]
User Stories.
Valuable
to the user
INVEST - [ E ]
User Stories.
Estimable
should be small/discrete enough that a decent timeframe can be given
INVEST - [ S ]
User Stories.
Small
big = not estimable
INVEST - [ T ]
User Stories.
Testable
able to create definition of done
acceptance criteria established
Three components of a user story
CARDS (physical medium)
CONVERSATION (discussion surrounding)
CONFIRMATION (tests to verify)
SMART - [ S ]
Tasks.
Specific
Everyone knows what’s involved. Tasks don’t overlap. Can determine whether it fits within the bigger plan.
SMART - [ M ]
Tasks.
Measurable
Do you know when it’s done
SMART - [ A ]
Tasks.
Achievable
No person should have a task too difficult for them to complete. And everyone should be able to ask for help if it’s not doable.
SMART - [ R ]
Tasks.
Relevant
Fits into the bigger story. Stories are broken up for the sake of developers. Should be able to explain to a customer why a task is relevant though.
SMART - [ T ]
Tasks.
Time-Boxed
doesn’t have to be a formal, strict estimate, but there should be expectations so that people know when they need to seek help/split up a task
Core Design Principles of Java
platform independent
- JVM is an abstraction and programs do not access the OS directly
- high portability
object-oriented
- except primitive data types, all elements are objects
strongly-typed
- variables are pre-defined and conversion is relatively strict
interpreted and compiled
- source code is transferred into bytecode format
- these instructions are interpreted by the JVM
A Few More Basics of Java
- syntax heavily influenced by C++
- statically typed
- imperative language
- criticized for being verbose
- most-used language according to GitHub
- owned by Oracle
- visibility (scope) is the same as in C++
A few predefined classes in Java
String, Vector, Stack, Hashtable, and many others
A Stack is a subclass of Vector which is a subclass of Object. All classes in Java are subclasses of the class Object.
Java “field”
= variable
Java “method”
= function
methods can be overloaded with one name referring to multiple methods (params/return val/etc different)
abstract methods (from polymorphic abstract object) have to be overwritten/cannot have an implementation
public interface Driveable { }
Git
Distributed version control system
“upstream” is your teams repository after forking
rebase = alternative to git merge master (produces cleaner history)
TDDs’ three rules
Write a failing test before writing any production code
don’t write more of a test than is sufficient to fail/fail to compile
don’t write more production code than is sufficient to make the currently failing test pass
The TDD cycle
RED (fail test)
GREEN (production code)
REFACTOR
Why TDD?
Design and documentation more than it is verification
close feedback loops
clear starting points
throw away less code
worry about I/O less
more confidence
non-functional requirements
SLA’s (Service Level Agreement)
quantitative
functional requirements
what it needs to do
system behavior when interacted with
User Story basics
plain english
As a ____, I want ____ so that ______
3x5 index
stick to wall/whiteboard
have conversation with product owner
confirmation written on back of the card
functional decomposition
programs (like C) are decomposed into functions, that operate on common data structures
as opposed to OO-decomposition
object oriented decomposition
A system is decomposed according to the objects a
system is supposed to manipulate (like Java)
Objects communicate through well defined
interfaces
as opposed to functional decomposition
Encapsulation
Group together data (variables) and methods
(functions) in one unit
all variables should be hidden (private) and
only accessible by the methods in the class
Inheritance
Also known as subclassing or subtyping
Classes inherit fields and methods with the extends keyword
Java only supports single inheritance (you can only
extend from one class)
– all roots trace back to the Object class
Polymorphism
subclass can always be used instead of parent class
SOLID - [ S ]
Object-Oriented Design.
Single Responsibility Principle (SRP)
class has only one responsibility/reason to change
class should only know about one thing; it should only act like one logical object
SOLID - [ O ]
Object-Oriented Design.
Open-Closed Principle (OCP)
classes should be closed for modification, open for extension
when new requirements, add code instead of changing code
examples: chrome extensions, IDE plugins, OS drivers
SOLID - [ L ]
Object-Oriented Design.
Liskov Substitution Principle (LSP)
subclass has contract with parent to do everything it does
SOLID - [ I ]
Object-Oriented Design.
Interface Segregation Principle (ISP)
only use classes you need
SOLID - [ D ]
Object-Oriented Design.
Dependency Inversion Principle (DIP)
depend on abstractions not concretions
“Message” from “text message” and “email message”
“Ship” from _____
formal inspection code review
expensive. long. heavyweight. Michael Fagan in the 70s
4 roles 7 stages
9 person-hours per 200 lines of code
lightweight approaches to code reviews
over the shoulder
pair programming
pull requests
code review suggestions
< 400 lines at once
< 60 minutes at a time
peer review checklist
follow up on comments
verification vs validation
VALIDATION :: are we building what we should be building?
- Acceptance testing
- User demos
- Beta testing
VERIFICATION :: are we building that thing right?
- Formal methods
- Unit tests
- Regression tests
Types of testing
development - done during dev by developers and testers
release - done prior to release or other milestone. done outside dev team (e.g. the customer)
user - users (beta testing)
integration - components interact as expected
regression testing - make sure bugs reappear
JUnit basics
in Maven, src/test/java
each production class has a test class and they live in the same package
annotate test methods with @Test (line before)
annotate with @Before to setup - sets up a “test fixture,” which is the context in which a test is run
@After to release resources after a test
@BeforeClass and @AfterClass to do test fixture setup/teardown only once per class run (bookends of the entire file)
org.junit.Assert
JUnit executes tests in a deterministic, but unpredictable order (independence assumption of tests)
Blackbox and whitebox
blackbox
- you don’t know the implementation
- tests are derived from specifications/documentation/etc.
whitebox = you do
- trying to execute all lines of the code, branches, conditionals, etc.
equivalence class partitioning (blackbox)
try things that are basically representative of all inputs
boundary testing (blackbox)
like equivalence class partitioning (ECP), but more focused on boundaries
statement/line coverage (whitebox)
how many (executable) statements were covered?
does not mean 100%, because you could cover all lines, but not all branches
branch coverage (whitebox)
all decision points are exercised
all choices in switch/conditional statements are covered
path coverage (whitebox)
similar to branch coverage but takes it a step further, not only ensuring that all branches are covered, but all paths possible prior to reaching that branch.
if there’s a theoretically unlimited loop, 100% is impossible
Nielsen’s Usability Goals
MEELS
- Memorability
- Easy to remember after learning? Pick back up easily after gone awhile. - Efficiency
- Once it has been learned, how effective is it? How many clicks away? - Errors (safety)
- How easy to crash/break/reach state of perceived fear?
- Check before deleting/etc. - Learnability
- Do you need manuals and courses to learn it? - Satisfaction
- Important with video games
Heuristic Evaluation
- Visibility of system status
- user knows what is happening - Match between system and real world
- intuitive by imitating the real world - User control and freedom
- Consistency and standards
- similar across platforms - Error prevention
- Recognition rather than recall
- minimize cognitive load by maintaining task-relevant information within display
- assist the user in remembering things - Flexibility and efficiency of use
- expert can use more efficiently/powerfully - Aesthetic and minimalist design
- Help users recognize, diagnose and recover from errors
- tell them what the error is in plain English - Help and documentation
Code, methods and classes that have increased to
such gargantuan proportions that they are hard to work with
Bloaters
Long Method/Class/Param List
method longer than 10 is suspicious. longer than 30 is problematic
more than 4 params is too many. indicator of inadequate abstraction
check for code preceded by comments, long switch/conditionals
Incomplete or incorrect application of object-oriented
programming principles
OO Abusers
use not all inherited fields/methods
complex switch = bad class hierarchy
Any change requires you to make many
changes in other places too
Change Preventers
single responsibility has been distributed
Something pointless whose absence would
make the code better
Dispensables
duplicated code
data class
speculative generality (unused. “just in case” stuff)
Excessive coupling between classes
Couplers
feature envy (method accesses data of another more than its own)
inappropriate intimacy (one class uses internal fields and methods of another) good classes know as little as possible about one another
Refactoring
give new stuff meaningful name
extract stuff into another class
take repeatedly passed parameter and make it a field
if multiple parameters belong to another object, just pass the object
replace inheritance with delegation (extract common behavior then delegate methods to that class)
move method
move field
pull up method (move to superclass)
collapse hierarchy - remove unused abstract
inline class - remove unnecessary classes
unused fields and methods simply removed
Responsibility Driven Design (RDD)
- find the classes in your system
- determine the responsibilities of each class
- determine how objects collaborate with each other to fulfill their responsibilities
- factor common responsibilities to build class hierarchies
Assigning Responsibilities
Be lazy (don’t do anything you can push to someone else)
Be tough (don’t let others play with your toys)
Be socialist (evenly distribute system intelligence)
CRC
Class-Responsibility-Collaborator
class name (top)
responsibilities (left)
collaborators (right)
Responsibilities
can class fulfill responsibility by itself?
if not, what does it need, and from what class can it obtain that?
For each class
What does this class know?
What other classes need its information or results?
Classes that do not interact with others should be discarded
UML
Unified Modeling Language
design
high-level picture
communication
vocabulary
teaching
classes of UML diagrams
Behavior
- activity, sequence, state machine
Structure
- elements irrespective of time
Activity Diagram
start with black circle
rounded rectangle = action
diamond = decision
black bar = concurrent activities
end with black circle with ring
Sequence Diagram***
how processes operate and in what order
asynchronous code
usage scenarios, logic of methods, logic of services
each actor is a labeled vertical line
each message is a horizontal line with message name written above the line
open arrow heads represent async messages
dashed line = response
State Diagram
states of an object
normal state
start/initial state
stop/accepting/final state
transition
actions vs activities
actions quick and not interruptible
associated with transitions
activities associated with states, take longer, and can be interrupted
Use Case Diagrams
user interaction
summary of usage requirements from user’s point of view
Class Diagrams***
Name
Attributes (fields)
Operations (methods)
fixed numbers on lines or ranges with a “..” including * for “any”
Dotted line to an arrow
Association class
Filled Arrow
Employee works in => Office
most common
Empty Arrow
Inheritance
Filled Diamond
composition (engine is a part of a car) (catalog is a part of library) part can't exist outside of the whole tear down a visitor center and the lobby and bathroom get destroyed in the process
Empty Diamond
aggregation
(person goes in a car)
can exist outside the whole by itself or be a part of the whole. tortoise a part of the “creep”
Four elements that describe a design pattern
Name
Purpose (problem it solves)
Solution
Constraints (that we consider in our solution)
Three categories of design patterns
Creational
abstract away the object instantiation (creation)
Structural
concerned with how classes and objects are composed to form larger structures
Behavioral
concerned with how algorithms and the assignment of responsibilities between objects
Singleton
Creational
ensure one instance and provide global point of access to it
make the constructor private
if (s == null)
s = new Singleton()
Factory Method
Creational
creates an instance of several derived classes
define interfaces for creating an object. let subclasses decide which class to instantiate
framework instantiates the objects
the instantiated objects are sometimes knows as
products
Transport object = logistics.makeInstance();
and this decides whether road or sea transport
complex, but makes adding new products easy and follows OCP
Composite
Structural
a tree structure of simple and composite objects
compose objects into tree structures to
represent part-whole hierarchies. Clients can treat
individual objects and compositions uniformly
A file system has files and folders. Users
want to manipulate files and folders the same way
(e.g. move, rename, delete etc)
Different but they still want to share some same capabilities
Facade
Structural
a single class that represents an entire subsystem
unified interface to a set of
interfaces in a subsystem
higher-level
interface that makes the subsystem easier to use
Template
Behavioral
define a skeleton of an algorithm and defer
some steps to subclasses
The base class provides the basic steps of the algorithm. The subclasses provide the details
Observer
Behavioral
Define a one-to-many relationship between
objects, so that when one object changes its state,
the dependents are notified and updated
automatically
Command
Behavioral
encapsulate a command request as an object
State
Behavioral
Alter an object’s behavior when its state changes
Chain of responsibility
Behavioral
Pass a request between a chain of objects
Visitor
Behavioral
Define a new operation to a class without change
4+1 Architectural View
Logical View:
functionality to end users.
Process View:
runtime behavior, including processes and their
communication
Development View:
perspective of the developer management, maintenance etc;
Physical View:
deployment on actual physical hardware
Monolith Architecture
single-tier software application
components in a single application
Client-server Architecture
distributes functionality of a system into services
Micro-service Architecture
extreme generalization of client-server architecture
RESTful Architecture
inspired by the largest distributed application ever: The Web
stateless requests
every resource has individual URI (uniform resource identifier)
uniform interface for all resources (GET, POST, PUT, DELETE)
structure of response not specified
3-Tier Architecture
client server architecture,
where the
[ application layer ] functional process logic (business logic),
[ data access layer ]
data persistence
(data access, storage management) and
[ presentation layer ]
user interfaces
are developed a 3 separate modules
Layered Architecture
subtasks, where each group of subtasks is at a particular layer of abstraction
each layer provides set of services to layer “above”
Generic
Online Library
OSI reference
Android
Event Driven Architecture
components perform services in reaction to external events generated by other components
In broadcast models an event is broadcast to all
sub-systems
In interrupt-driven models real-time interrupts are
detected by an interrupt handler and passed to
some other component for processing
