Working Effectively With Legacy Code 
Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science)  |
Wednesday, June 9, 2010
Books
Working Effectively With Legacy Code Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science) 
Performance & Security Testing in Agile Development
6/9/2010
Tracy DeDore (HP)
Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint
automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time
static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts
Tracy DeDore (HP)
Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint
automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time
static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts
Manifesto for Agile Software Development
First principles of Agile, from http://agilemanifesto.org/
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Tutorial: Agile Use Cases
Instructor: Rebecca Wirfs-Brock
Rebecca is the inventor of the two column use case. She has been doing use cases since 1992. It was in a Smalltalk magazine that she published a use case with two columns. The side-by-side use case was born... no, No, NO.
Agile core values
Actor = a user or another system
Use case body forms
User stories are a similar to use cases.
From wikipedia: "A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software."
Rebecca is the inventor of the two column use case. She has been doing use cases since 1992. It was in a Smalltalk magazine that she published a use case with two columns. The side-by-side use case was born... no, No, NO.
Agile core values
- Design simplicity (use case application: simple writing leads to simple coding)
- Interpersonal communication
- High degree of trust
- Satisfying stakeholders
- Constant learning
- Decision making spread across project duration
- Information when needed ... just in time (often through conversations and additional tests)
- Functionality from a particular point of view
- ... describes a chunk of the system
- Can be a various levels: In the clouds (scope) and at sea level (code)
- Agile use cases are not so detailed
Actor = a user or another system
Use case body forms
- Narritive form
- Step-by-step form
- Side-by-side form (Conversational)
User stories are a similar to use cases.
From wikipedia: "A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software."
Tuesday, June 8, 2010
Quality Assurance: Moving Your Organization Beyond Testing
6/8/2010
Instructor: Jeff Payne
Why Software Fails
Connectivity/Extensibility/Complexity
Software is different from everything we create in the physical world
Software quality is poorly measured and managed
What is real QA?
Some traditional methods dont mention quality, software, value to the customer
Verification - Old school QA - have we built the product right?
Conforming with standards, following the process, tracing back artifacts to requirements
Process oriented/process centric
Only do the parts that you think have value
dont require much software knowledge
Validation - have we built the right product?
validate against requirements document
require much more software expertise than verification (you have to be technical)
Risk Management & QA
Focus on critical components
Risk Matrix: consequence vs. likelihood
Metrics
What is the purpose of collecting metrics?
Goal Question Metric (GQM) (google it)
Defect Metrics: defects produced, corrected, rates
good because they get to the heart of the matter: does the software work
how close are we to being done
Risk Metrics: how many risks have been identified/mitigated etc, code coverage
Productivity/rework metrics
velocity: how much did we get done in an iteration (measure per team not person)
rework: time & effort spent fixing defects
time spent building new things vs fixing old things
Relative metrics and trends better than absolute and individual numbers
Instructor: Jeff Payne
Why Software Fails
Connectivity/Extensibility/Complexity
Software is different from everything we create in the physical world
Software quality is poorly measured and managed
What is real QA?
Some traditional methods dont mention quality, software, value to the customer
Verification - Old school QA - have we built the product right?
Conforming with standards, following the process, tracing back artifacts to requirements
Process oriented/process centric
Only do the parts that you think have value
dont require much software knowledge
Validation - have we built the right product?
validate against requirements document
require much more software expertise than verification (you have to be technical)
Risk Management & QA
Focus on critical components
Risk Matrix: consequence vs. likelihood
Metrics
What is the purpose of collecting metrics?
Goal Question Metric (GQM) (google it)
Defect Metrics: defects produced, corrected, rates
good because they get to the heart of the matter: does the software work
how close are we to being done
Risk Metrics: how many risks have been identified/mitigated etc, code coverage
Productivity/rework metrics
velocity: how much did we get done in an iteration (measure per team not person)
rework: time & effort spent fixing defects
time spent building new things vs fixing old things
Relative metrics and trends better than absolute and individual numbers
Mastering Design Patterns
6/8/2010
Instructor: Robert Martin
...A discussion on Hubble and the expansion and age of the universe
Design Patterns book 1995 "Gang of Four" GoF95
Design patterns are encoded knowledge given a name and a canonical form: once you know/recognize it you can stop thinking about it
A design pattern is a solution to a recurring problem
Abstract Server pattern: so simple it's not in the books
or polymorphism pattern
Clients and the interfaces they used get grouped together, NOT grouped by hierarchies
Adapted Server pattern
Adapter allows you to "adapt" a class you dont own the source code of
Can combine incompatible interfaces/convert one interface to another
A delegation relationship is when the Adapter simply passes on the call to the connected interface
Class form of the adapter pattern: the adapter inherits from both the interface and the server
Template Method Pattern (or write a loop once)
Strategy Pattern
It is polite to change the name of the class to include the design pattern name to aid recognition for the reader
Data structures have well known data and very little behavior (methods)
Objects have well known behaviors and very little known data
...a discussion on the early expansion of the universe shortly after the big bang
State Pattern
How do we implement finite state machines?
Implementing in a huge nested switch statement is very hard to maintain
SMC (google it): implementation of state machine classes is generateble if you know the state event/action table
Parsers, network protocols, GUIs, are FSMs
Command Pattern
Remarkably simple but the repercussions are enormous
A way to decouple what gets done from who does it
A sensor can be decoupled from the command it calls
Can also be used to store a list of commands and "undo" them as necessary
Or transaction commands in a DB which can be executed later during downtime
Decoupling what gets done from WHEN it gets done
A list of commands (some of which add new commands to the list) can be used for multitasking/task switching on a single stack (called run to completion) There's no blocking: if a command needs to wait for an event, it must clone itself and put it on the list
...a discussion on stars and supernovas/hypernovas
Composite Pattern
Similar to the command pattern & very simple
A way to take many objects and treat them as one
The composite exists at a lower level so the higher level model is not affected
"take all details and shove them down as far as you can"
dont expose details at the highest levels
If you're doing to treat a composite of objects identically, then a composite is useful. If you're going to scan the objects and treat them different, the composite pattern cannot be used
Proxy Pattern
Can be used to create a "proxy" class that hides dependencies and isolates an application from (for instance) a DB. The proxy database interface layer depends on the app and the DB: the app does not depend on the DB because the dependencies have been inverted
Can also be used for cross-process communication
However: the proxy objects are complicated & difficult to maintain (but at least all your complications are isolated in the proxy)
Observer Pattern
(...a discussion on leap years and leap seconds and the changing rotation of the earth)
Allows an object to notify multiple dependent objects every time it changes state
small changes can be pushed thru the notify() function
larger changes need to be pulled from the dependent object when they are needed
sometimes hints can be passed to narrow down where the change occurred
Can build systems that watch & react to other objects as they change: a cool form of indirection until you have to debug it.
Comes up a lot in GUI's, callbacks, listeners, MVC
MVC was probably the first design pattern to get a name (70s)
The input/process/output split is the same, but the object/observer relation is not the same as the original smalltalk version of MVC
What does MVC mean anymore? not much
Document View Pattern is similar to MVC
merges the view/controller
Model View Presenter
How do you write tests against a GUI?
Move complexity out of the view into a presenter
Presenter observes the model
View queries the presenter
Presenter restructures the data from the model so it is presentable
View is stupid
Presenter knows nothing about the GUI: it is creating data structures
Now you can test the presenter! And the view is so stupid you don't need to test it, or the test is trivial
Instructor: Robert Martin
...A discussion on Hubble and the expansion and age of the universe
Design Patterns book 1995 "Gang of Four" GoF95
Design patterns are encoded knowledge given a name and a canonical form: once you know/recognize it you can stop thinking about it
A design pattern is a solution to a recurring problem
Abstract Server pattern: so simple it's not in the books
or polymorphism pattern
Clients and the interfaces they used get grouped together, NOT grouped by hierarchies
Adapted Server pattern
Adapter allows you to "adapt" a class you dont own the source code of
Can combine incompatible interfaces/convert one interface to another
A delegation relationship is when the Adapter simply passes on the call to the connected interface
Class form of the adapter pattern: the adapter inherits from both the interface and the server
Template Method Pattern (or write a loop once)
Strategy Pattern
It is polite to change the name of the class to include the design pattern name to aid recognition for the reader
Data structures have well known data and very little behavior (methods)
Objects have well known behaviors and very little known data
...a discussion on the early expansion of the universe shortly after the big bang
State Pattern
How do we implement finite state machines?
Implementing in a huge nested switch statement is very hard to maintain
SMC (google it): implementation of state machine classes is generateble if you know the state event/action table
Parsers, network protocols, GUIs, are FSMs
Command Pattern
Remarkably simple but the repercussions are enormous
A way to decouple what gets done from who does it
A sensor can be decoupled from the command it calls
Can also be used to store a list of commands and "undo" them as necessary
Or transaction commands in a DB which can be executed later during downtime
Decoupling what gets done from WHEN it gets done
A list of commands (some of which add new commands to the list) can be used for multitasking/task switching on a single stack (called run to completion) There's no blocking: if a command needs to wait for an event, it must clone itself and put it on the list
...a discussion on stars and supernovas/hypernovas
Composite Pattern
Similar to the command pattern & very simple
A way to take many objects and treat them as one
The composite exists at a lower level so the higher level model is not affected
"take all details and shove them down as far as you can"
dont expose details at the highest levels
If you're doing to treat a composite of objects identically, then a composite is useful. If you're going to scan the objects and treat them different, the composite pattern cannot be used
Proxy Pattern
Can be used to create a "proxy" class that hides dependencies and isolates an application from (for instance) a DB. The proxy database interface layer depends on the app and the DB: the app does not depend on the DB because the dependencies have been inverted
Can also be used for cross-process communication
However: the proxy objects are complicated & difficult to maintain (but at least all your complications are isolated in the proxy)
Observer Pattern
(...a discussion on leap years and leap seconds and the changing rotation of the earth)
Allows an object to notify multiple dependent objects every time it changes state
small changes can be pushed thru the notify() function
larger changes need to be pulled from the dependent object when they are needed
sometimes hints can be passed to narrow down where the change occurred
Can build systems that watch & react to other objects as they change: a cool form of indirection until you have to debug it.
Comes up a lot in GUI's, callbacks, listeners, MVC
MVC was probably the first design pattern to get a name (70s)
The input/process/output split is the same, but the object/observer relation is not the same as the original smalltalk version of MVC
What does MVC mean anymore? not much
Document View Pattern is similar to MVC
merges the view/controller
Model View Presenter
How do you write tests against a GUI?
Move complexity out of the view into a presenter
Presenter observes the model
View queries the presenter
Presenter restructures the data from the model so it is presentable
View is stupid
Presenter knows nothing about the GUI: it is creating data structures
Now you can test the presenter! And the view is so stupid you don't need to test it, or the test is trivial
Subscribe to:
Posts (Atom)