-
Notifications
You must be signed in to change notification settings - Fork 0
Software Craftsmanship
jefferydutra edited this page Nov 15, 2014
·
3 revisions
- Review only 200 to 400 lines of code per session
- Keep under 90 minutes
- Code authors should prepare the code that wil be prepared by doucmenting the flow, reasons and methods behind each code modification
- Establish quantifiable goals for code review and capture metrics to help imporve the process.
- Track the bugs as you find them
- Remember its okay for people to find bugs in your code; its better than a user finding it.
- The code belongs to the whole development team. It does not matter who created the bug, it only matters that we stopped the bug from being released
- Code reviews help write better code because you know your peers will be looking at your work
http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf 11 Best Practices for Peer Code Review
"Going from a state of unknown to a state of known, in manageable pieces"
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
- Tests should help us improve quality
- Tests as Specification
- Bug Repellant
- Defect Localization
- Tests should help us understand the SUT (System Under Test)
- Tests as documentation
- Tests should reduce (and not introduce) risk
- Tests as a Safety Net
- Do no harm
- Tests should be easy to run
- Fully Automated Tests
- Self-Checking Test
- Repeatable Test
- Tests should be easy to write and maintain
- Simple Tests
- Expressive Tests
- Separation of concerns
- Tests should require minimal maintenance as the system evolves around them
- Robust Test
- It produces more lines of code with less bugs than individual programming
- Increases
- Focused Energy
- Brain Storming
- Levels of problem solving
- Motivation
- It allows for continuous design and mentoring
- Many mistakes get caight as they are being typed, rather thatn in QA or in productio
- Code quality has less variance than individual programming
- More likely to complete work on time
- Pair Pressure has a significant impact on all these factors
- Code in programs can be 20 per cent shorter
- Passes more tests
- Better adherence to preferred object oriented design
- More maintainable code
- Improve engineer's job satisfaction
- Seven independent surveys over 90 per cent of pair-programmers say they enjoy their jobs more when they are pairing.
- 96 per cent indicated that pair programming made them more confident
- Reduces time need by senior staff to train new people
- Allows the trainer to teach by doing instead of showing
- Code contributions are made during training time
- It helps team members better understand each other
- Removes communication barriers
- Much easier for team members to ask each other for assistance
- Trust will build and team members will be able to easily ask each other for advice and guidance without feeling vulnerable and insufficient.
- when pairs work together they make decisions without co-ordination meetings on
- dependencies
- technical aspects
- interfaces
- if pairs rotate and work with a developer whom their code is interdependent that greatly reduces friction in being able to work with other code.
http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF Strengthening the Case for Pair-Programming http://www.aw-bc.com/samplechapter/0201745763.pdf Overcoming Management Resistance to Pair Programming
back home