Housekeeping SVN Mandatory for project Will be a spot check in the next couple of weeks to...
-
Upload
donald-holland -
Category
Documents
-
view
214 -
download
0
Transcript of Housekeeping SVN Mandatory for project Will be a spot check in the next couple of weeks to...
Housekeeping
SVN Mandatory for project Will be a spot check in the next couple
of weeks to identify whether “software craftmanship” is being practiced
Individual design reviews due by Monday at 3pm (can submit earlier) All groups have provided access
Milestone 5 will be out tomorrow
Assessing the quality of implementationsVerification Validation Code inspection Pair programming
Testing
Implementation Quality AttributesDegree
of…0… …10
Sufficiency Fails to implement the corresponding design implementation
Satisfies all the design specifications for this element
Robustness
Will cause crash on any anomalous event
Recovers from all anomalous events as well as can be expected
Flexibility Will have to be replaced entirely if the design or requirements change
As easily adaptable to reasonable changes as can be expected
Reusability Cannot be used in other applications
Usable in all reasonably related applications without modification
Efficiency Fails to satisfy speed or data storage requirement
Satisfies speed or data storage requirement with reasonable margin
Reliability Obviously won’t achieve required mean time between failure
Obviously will achieve required mean time between failure
Scalability Can’t be used as the basis of a larger version
Is an outstanding basis for a version with a much larger scope
Security Security not accounted for at all No known manner of breaching security
Supporting and Competing RelationshipsSupporting Competing
Security/reliability Scalability/flexibility Security/robustness Robustness/reliability
Efficiency/security Efficiency/robustness Efficiency/scalability Efficiency/reliability Efficiency/flexibility Efficiency/reusability Reliability/flexibility
Sufficiency
Measures the percentage of the requirements and design specifications actually implemented Expect to implement all, but generally prioritize
in importance due to time constraints Can calculate with a completely specified
list of detailed requirements Percentage of detailed requirements that are
implemented Percentage of methods specified in the design
that are implemented Percentage of classes specified in the design that
are implemented
Robustness Extent to which it handles anomalous input
(unexpected form or content) Assessment process:
1. Assess input to the method1. Anomalous parameter values2. Anomalous global variables3. Anomalous event variables
2. Assess dependent methods: Measure the extent of compromise
Investigate the pre-conditions (complete?) Investigate whether the method defends
against violations of the pre-conditions Note: we have a need for documented pre-
conditions!
Flexibility How well does it easily accommodate
new or changed requirements? Methods of increasing flexibility:
1. Document precisely and thoroughly2. Name constants3. Hide where possible (variables, methods)4. Collect common code (as helper methods
and classes)5. Reduce dependency on global/external
variables (parameterize methods)6. Program at a general level7. Use understandable variable and function
names
Reusability Capacity for its use in other applications Making a component more flexible
usually makes it more reusable Possible at the level of method, class, or
package Method of increasing reusability:
1. Match classes to a real-world concept2. Make level of abstraction high enough to
cover many applications, but low enough to allow substance
3. Increase the degree of the description. Reliability of the code promotes reusability – should contain complete error checking
Efficiency
Two kinds: process speed & storage use Requirements should be specified in SRS
If not, use common sense limits (space & time are not unlimited in practice)
Metrics: Speed efficiency: fraction of the speed required
Required: 0.5 sec., actual: 2, efficency = 0.5/2=25% 100% is success baseline
Similar for space efficiency: req/actual = %
Reliability Goes further than sufficiency and robustness
Need to be sure that it does what it is supposed to (sufficiency) and also behave appropriately in the presence of anomalous input (robustness)
Even sufficient and robust applications may have defects and be less reliable than required
Example: app to add any pair of integers between +/- 100K Sufficient: it adds them Robust: displays an error if outside the range Unreliable: has a memory leak that causes it to crash after
running for an hour MT to failure = total time running/# of failures in that
time
Scalability
It is scalable if it is sufficient for all reasonably anticipated homogenous growth (in line with current capability) Works for 1 record/second, will it work for 1K
records per second (max anticipated data rate)? Can be difficult to assess through inspections Early testing can be expensive/impractical
(difficult to create the scaled up environment)
Metrics measure speeds and data storage in simulated/accelerated environments
Security Important when connected to networked
parts, dealing with confidential data E.g., Login security challenges:
Store ID/passwords w/o allowing unauthorized access
Ensure that data go only to authorized requesters Design so that security is easily maintained as
application evolves Isolate security-affecting classes?
Metrics for security: confidentiality, non-repudiation, integrity, authentication, authorization
Code inspections
Tool for producing high quality code Code is reviewed by team of peers with
the goal of identifying as many defects as possible of as high a severity as possible
Typically conducted after code is written, but before it is unit tested
Should first be desk-checked by author Should compile with no errors or
warnings
Inspection process Author distributes code to group of reviewers Sometimes and overview meeting to present
an overview of the code, its layout, the overall design – provides perspective for review
Individual review Inspection meeting:
Facilitator leads the group through the code For each block, inspectors raise issues If issue is agreed to be a defect, noted Faults are recorded, but not solved (that is the
author’s job)
Code Inspection Checklist A1. Variables
1. Meaningful names2. Named constants3. Read-only variables declared const or
final4. All variables used?
2. Functions1. Meaningful names?2. Are all parameters used?
Code Inspection Checklist B3. Correctness
Are all parentheses & brackets properly matched?
Do all switch statements terminate with a break? Is there a default case?
4. Initialization Are variables initialized before their first
use?
5. Dynamic Allocation Is every dynamically allocated piece of
memory properly de-allocated?
Code Inspection Checklist C6. Loops
Do all loops successfully terminate? If used, do break and continue
statements work correctly? Does the body of the loop modify the
loop variables?
7. Pointers Can a null pointer be de-referenced?
Code Inspection Checklist D 8. Comments
Is the code properly commented? Do the comments accurately describe
the corresponding code? 9. Defensive Programming
Are checks made to prevent errors such as divide by zero or illegal data?
Summary To assess quality of implementation,
useful to categorize its qualities Consider its sufficiency, robustness,
flexibility, reusability, efficiency, reliability, scalability, and security
Various metrics to measure the extent of each of these in the application
Code inspections are used to detect and fix defects in the code as close to their injection point as possible
Checklists guide reviewers
Acknowledgements
Material in this presentation was drawn from
Martin Fowler, Refactoring: Improving the Design of Existing Code
Definition
Process of altering source code so as to leave its functionality unchanged
Why refactor? Improve maintainability, especially
enhancement When to refactor?
Considered as soon as code writing begins Essential part of most agile approaches Refactor only with valid unit tests in place –
need to ensure that refactoring does not break working code
Refactoring is… Refactoring is NOT…
Small, behaviour-preserving, incremental and safe steps
Improving the design of existing code
Making it more understandable and/or flexible
Breaking a large method into smaller, more focused methods
Renaming variables and parameters to be meaningful
Moving a responsibility from one class to a more appropriate one
Creating an interface, based on the methods in one class, and making that class implement the new interface
An excuse to go back and “fill in the blanks” in your application
Improving (adding) error handling
Adding logging Cramming in
another feature
Enhancing the test coverage
http://twasink.net/blog/2004/05/refactoring-vs-re-architecting-vs-redesign-vs-rewriting/
Code smells
A code smell is a hint that something is wrong in your code
Use the smell to track down the problem
Differing view points: Pragmatist: consider code smells on a
case by case basis Purist: all code smells should be avoided
without exception http://c2.com/xp/CodeSmell.html
How to identify code smells? Experience Regular code review Code metrics:
E.g., cyclomatic complexity (# of decision points + 1)
http://www.codeproject.com/KB/architecture/practicalexp.aspx?display=Print
Tools: http://multiview.cs.pdx.edu/refactoring/s
mells/
Last class: code smells How to recognize them?
Experience Taxonomy (handout)
Helps provide an understanding of the smells and to recognize the relationships between then
Tools: http://multiview.cs.pdx.edu/refactoring/s
mells/
Refactoring Catalog
http://www.refactoring.com/catalog/ List of factorings from Fowlers
original book and later sources
How do you get from code smells to refactoring? Java.net SmellsToRefactorings
(handout)
Exercise From Fowler’s book Handouts
http://david.koontz.name/home/Projects/Entries/2008/4/13_Photo_of_the_Day_files/Refactoring_FirstExample.zip
Step 1: Familiarize yourself with the classes for a movie rental store (Movie, Rental, Customer)
Step 2: Review the tests that have been set up. Think about why they are important
Exercise
Step 3: Can you identify any code smells?
Consolidate Conditional Expression Multiple conditionals can be extracted into
method Don’t do if conditions are really independent Example
BEFORE
double diasabilityAmount() {
if (_seniority < 2) return 0;
if (_monthsDisabled > 12) return 0;
if (_isPartTime) return 0;
if (_isVeteran) return 50;
// Calculate disability amount
AFTER
double diasabilityAmount() {
if (isNotEligibleForDisability) return 0;
if (_isVeteran) return 50;
// Calculate disability amount
Duplicate Observed Data
Problem: You have data stored in a GUI component and domain methods need access
Solution: Copy the data into a domain object (so the methods can access it) and use an Observer to keep the two locations synchronized
Extract Class
Remove a piece of a class and make it a separate class
Done when class is too big to understand easily or behavior is not narrowly defined enough
Indicated by having subsets of data & methods that go together, are changed together, or are dependent on each other
Ask “What if I removed this? What would become useless?”
Extract Interface
Define an interface to move away from a concrete implementation
Allows easier use of differing databases or MockObjects
Extract Method
Pull code out into a separate method when the original method is long or complex
Name the new method so as to make the original method clearer
Each method should have just one task
http://www.refactoring.com/catalog/extractMethod.html
Extract Subclass
Used when a class has some behavior used for some instances and not for others
Make a subclass that inherits the common functionality
Introduce Assertion
Make implicit assumptions in the code explicit
http://www.refactoring.com/catalog/introduceAssertion.html
Introduce Explaining Variable Break up complex expressions into
chunks with clarifying names http://www.refactoring.com/catalog/
introduceExplainingVariable.html
Introduce Parameter Object Replace a group of parameters that
go together with an object Makes long parameter lists shorter &
easier to understand Can indicate functionality to move to
new class http://www.refactoring.com/catalog/
introduceParameterObject.html
Preserve Whole Object
Send the whole object rather than long lists of values obtained from the object
May increase dependency A method that uses multiple values
from another class should be examined to determine if the method should be moved instead
http://www.refactoring.com/catalog/preserveWholeObject.html
Rename Method
Method names should clearly communicate the one task that the method performs
If you are having trouble naming the method, it might be doing too much. Try extracting other methods first
Replace Conditional with Polymorphism
Replace switch statements with polymorphic subclasses (or push case behavior down to existing subclasses)
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
Replace Magic Number with Symbolic Constant
Replace hard-coded literal values with constants
Avoids duplication and shotgun surgery
http://www.refactoring.com/catalog/replaceMagicNumberWithSymbolicConstant.html
Replace Nested Conditional with Guard Clauses In some conditionals, both paths are
normal behavior & the code just needs to pick one
Other conditionals represent uncommon behavior
Use if/else with the normal behavior paths & guard clauses with uncommon behavior
http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
Replace Parameter with Method A routine invokes a method just to
pass the result of that method on to another method
Let the 2nd method call the first method directly (if it can)
http://www.refactoring.com/catalog/replaceParameterWithMethod.html
DeMorgan’s Law
Used for simplifying boolean expressions
!(a && b) => (!a) || (!b) !(a || b) => (!a) && (!b)
Further resources
http://www.refactoring.com http://c2.com/cgi/wiki?CodeSmell