Final Prep Flashcards
(96 cards)
1
Q
When did Agile really start taking off
A
about 13 years ago (2005)
before, we used waterfall
2
Q
Uncle Bob Video:
A
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
3
Q
When did Test-Driven Development (TDD) really start taking off?
A
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
4
Q
“decoupled code”
A
testable code
5
Q
INVEST - [ I ]
User Stories.
A
Independent
not always possible but good thing to seek
6
Q
INVEST - [ N ]
User Stories.
A
Negotiable
conversation to be had
7
Q
INVEST - [ V ]
User Stories.
A
Valuable
to the user
8
Q
INVEST - [ E ]
User Stories.
A
Estimable
should be small/discrete enough that a decent timeframe can be given
9
Q
INVEST - [ S ]
User Stories.
A
Small
big = not estimable
10
Q
INVEST - [ T ]
User Stories.
A
Testable
able to create definition of done
acceptance criteria established
11
Q
Three components of a user story
A
CARDS (physical medium)
CONVERSATION (discussion surrounding)
CONFIRMATION (tests to verify)
12
Q
SMART - [ S ]
Tasks.
A
Specific
Everyone knows what’s involved. Tasks don’t overlap. Can determine whether it fits within the bigger plan.
13
Q
SMART - [ M ]
Tasks.
A
Measurable
Do you know when it’s done
14
Q
SMART - [ A ]
Tasks.
A
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.
15
Q
SMART - [ R ]
Tasks.
A
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.
16
Q
SMART - [ T ]
Tasks.
A
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
17
Q
Core Design Principles of Java
A
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
18
Q
A Few More Basics of Java
A
- 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++
19
Q
A few predefined classes in Java
A
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.
20
Q
Java “field”
A
= variable
21
Q
Java “method”
A
= 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 { }
22
Q
Git
A
Distributed version control system
“upstream” is your teams repository after forking
rebase = alternative to git merge master (produces cleaner history)
23
Q
TDDs’ three rules
A
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
24
Q
The TDD cycle
A
RED (fail test)
GREEN (production code)
REFACTOR
25
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
26
non-functional requirements
SLA's (Service Level Agreement)
quantitative
27
functional requirements
what it needs to do
system behavior when interacted with
28
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
29
functional decomposition
programs (like C) are decomposed into functions, that operate on common data structures
as opposed to OO-decomposition
30
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
31
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
32
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
33
Polymorphism
subclass can always be used instead of parent class
34
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
35
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
36
SOLID - [ L ]
| Object-Oriented Design.
Liskov Substitution Principle (LSP)
subclass has contract with parent to do everything it does
37
SOLID - [ I ]
| Object-Oriented Design.
Interface Segregation Principle (ISP)
only use classes you need
38
SOLID - [ D ]
| Object-Oriented Design.
Dependency Inversion Principle (DIP)
depend on abstractions not concretions
"Message" from "text message" and "email message"
"Ship" from _____
39
formal inspection code review
expensive. long. heavyweight. Michael Fagan in the 70s
4 roles 7 stages
9 person-hours per 200 lines of code
40
lightweight approaches to code reviews
over the shoulder
pair programming
pull requests
41
code review suggestions
< 400 lines at once
< 60 minutes at a time
peer review checklist
follow up on comments
42
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
43
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
44
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)
```
45
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.
46
equivalence class partitioning (blackbox)
try things that are basically representative of all inputs
47
boundary testing (blackbox)
like equivalence class partitioning (ECP), but more focused on boundaries
48
statement/line coverage (whitebox)
how many (executable) statements were covered?
does not mean 100%, because you could cover all lines, but not all branches
49
branch coverage (whitebox)
all decision points are exercised
all choices in switch/conditional statements are covered
50
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
51
Nielsen's Usability Goals
| MEELS
1. Memorability
- Easy to remember after learning? Pick back up easily after gone awhile.
2. Efficiency
- Once it has been learned, how effective is it? How many clicks away?
3. Errors (safety)
- How easy to crash/break/reach state of perceived fear?
- Check before deleting/etc.
4. Learnability
- Do you need manuals and courses to learn it?
5. Satisfaction
- Important with video games
52
Heuristic Evaluation
1. Visibility of system status
- user knows what is happening
2. Match between system and real world
- intuitive by imitating the real world
3. User control and freedom
4. Consistency and standards
- similar across platforms
5. Error prevention
6. Recognition rather than recall
- minimize cognitive load by maintaining task-relevant information within display
- assist the user in remembering things
7. Flexibility and efficiency of use
- expert can use more efficiently/powerfully
8. Aesthetic and minimalist design
9. Help users recognize, diagnose and recover from errors
- tell them what the error is in plain English
10. Help and documentation
53
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
54
Incomplete or incorrect application of object-oriented
| programming principles
OO Abusers
use not all inherited fields/methods
complex switch = bad class hierarchy
55
Any change requires you to make many
| changes in other places too
Change Preventers
single responsibility has been distributed
56
Something pointless whose absence would
| make the code better
Dispensables
duplicated code
data class
speculative generality (unused. "just in case" stuff)
57
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
58
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
59
Responsibility Driven Design (RDD)
1. find the classes in your system
2. determine the responsibilities of each class
3. determine how objects collaborate with each other to fulfill their responsibilities
4. factor common responsibilities to build class hierarchies
60
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)
61
CRC
Class-Responsibility-Collaborator
class name (top)
responsibilities (left)
collaborators (right)
62
Responsibilities
can class fulfill responsibility by itself?
if not, what does it need, and from what class can it obtain that?
63
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
64
UML
Unified Modeling Language
design
high-level picture
communication
vocabulary
teaching
65
classes of UML diagrams
Behavior
- activity, sequence, state machine
Structure
- elements irrespective of time
66
Activity Diagram
start with black circle
rounded rectangle = action
diamond = decision
black bar = concurrent activities
end with black circle with ring
67
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
68
State Diagram
states of an object
normal state
start/initial state
stop/accepting/final state
transition
69
actions vs activities
actions quick and not interruptible
associated with transitions
activities associated with states, take longer, and can be interrupted
70
Use Case Diagrams
user interaction
summary of usage requirements from user's point of view
71
Class Diagrams***
Name
Attributes (fields)
Operations (methods)
fixed numbers on lines or ranges with a ".." including * for "any"
72
Dotted line to an arrow
Association class
73
Filled Arrow
Employee works in => Office
most common
74
Empty Arrow
Inheritance
75
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
```
76
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"
77
Four elements that describe a design pattern
Name
Purpose (problem it solves)
Solution
Constraints (that we consider in our solution)
78
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
79
Singleton
| Creational
ensure one instance and provide global point of access to it
make the constructor private
```
if (s == null)
s = new Singleton()
```
80
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
81
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
82
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
83
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
```
84
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
85
Command
| Behavioral
encapsulate a command request as an object
86
State
| Behavioral
Alter an object's behavior when its state changes
87
Chain of responsibility
| Behavioral
Pass a request between a chain of objects
88
Visitor
| Behavioral
Define a new operation to a class without change
89
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
90
Monolith Architecture
single-tier software application
components in a single application
91
Client-server Architecture
distributes functionality of a system into services
92
Micro-service Architecture
extreme generalization of client-server architecture
93
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
94
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
95
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
96
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
