ROBUST SOFTWARE HOW TO ADD QUALITY INTO YOUR SOFTWARE PROJECTS
Fabian Meier, G-Lab GmbH / GENEVA
16. Sept. 2014
Bio Fabian Meier
• Physiklaborant, Festkörper-Physik, 1988
• B.S. Elektrotechnik, HSR Rapperswil, 1995
• M.S. Electrical Engineering, Northwestern University, USA, 1997
• 7 Jahre als Entwickler: Video compression, Embedded software,
Streaming
• 4 Jahre Silicon Valley (Silicon Graphics, Burst.com, Verb Inc)
• 3 Jahre BridgeCo AG, Dübendorf
• Seit 2005 G-Lab GmbH, Product Management & Entwicklungsleitung
• 2009/2010 Aizo AG (DigitalStrom) – Patents
• 3 US patents in Image compression
• Software: C, C++, Java, C#, Assembler, Perl, Python
Some past software projects
Programming
• Video and image compression validation for chip (Perl)
• Video decoder – embedded on chip (assembler)
• Streaming server, Java
• Internet radio, C embedded
• Fully automated product test framework (Perl)
Manage development:
• Model XXL – 5 software (C embedded)
• AeroSphère Product line – Networked, Streaming: 3 systems, 2 Apps
• Distributed teams in different locations
Why does robust & high quality software matter?
• Target audience: “normal” scientists & engineers
Reasons
• Correctness
• Save development time
• Cost
• Pride
Pic Sailboat
Why robust software matters
Actual coding time: 70% - 30%
Fig 22-1 [1]
Bag of Tricks (Selected Best Practices) Systematic approach – learn from the past & other people
Defensive Programming
I. Architecture
II. Craft
III. Automatic error detection
IV. Add Robustness
Dealing with the real-world
I. Debug help
II. Process
III. Automatic Testing
IV. Tools
Selected Advanced Topics
Optimizing
Embedded programming tips
When does this matter? For which projects should I apply these best practices?
• 1 day: NO
• 1 week: NO
• 1 month: SOMEWHAT
• 2+ months: YES
• 2+ people: YES
Pic ARCHITECTURE
Architecture
I. Architecture Defensive Programming
• A4
• Use different views
• Avoid “clever” design
Pic Craft
Craft
II. Craft Defensive Programming
• What is the “art of software craft”?
• For example: Good naming: files, functions, classes,
variables
• calculateVelocity() vs. F1() or calculate()
• int averageVelocity , Vave vs. v1, avVel
Functions & Methods
• Size: Max size of function - 1 page, 50 - 150 lines + a few
longer ones
• Naming: verb + object, or describe return value:
• Good: printDocument()
• Bad: processInput(), f1(),
• Good: readMagnetSensors()
• Structure: split functions into a few blocks - mark with
comments (Step 1: do - xx....)
• Comments: why and what (step), not how
• Macros: minimize use, use functions. Debugger friendly,
compiler checks.
Variables
• Initialization: always, meaningful values.
• Naming: noun, 6-14char. Keep changing (IDE helps),
• Integers: check for division with zero & overflow
• Floats/double: don't use x == x (accuracy!!!)
• Strings: • NULL / 0 (terminator)
• Strcmp -> strncmp
• Size = L + 1 (null)
• Init with NULL
• Pointers: avoid (C#, Java, Python…) • always check for NULL
• always initialize to null
• embedded & drivers - worse effects
• Globals: OK, use them cleverly
• - naming, gA
• - add access routines/functions: getA(), setA()
Pic Mausfalle
Automatic Error Detection
III. Automatic Error Detection Defensive Programming
• Compiler
• Add tools to catch bugs: range check macros
CHECK_RANGE(a, 0, 254, MOTOR, “var a”)
• Strategies:
A) Stop execution
B) Report only
C) Report and recover
• Exception handlers
Error Detection - advanced
• Periodic health checks
Pic Man with many helmets, overprotected
Adding Robustness
IV. Adding Robustness Defensive Programming
• Expect the unexpected
• State machines: handle „impossible“ cases
• Exit gracefully
• Error handling concept (exception handler)
Pic – hunter hunting snakes or bugs, black and white.
butterlfly
Debugging help
I. Debugging help – finding errors more easily Dealing with the real-world
• Add logging facility • Print out: console or/and logfiles
• - One line with:
• (Time)(Error/warning/-)(intention/space)(Module)(details)(parameters) 12:01.234 ERROR Motor:StateMachine: invalid value A=34
12:01.238 Motor:Driver: state=start
12:01.674 WARN Heartbeat: overload v=45
•
LOG(LEVEL2, MOTOR_STATEM, (“invalid value A =%d“, A))
• Option: select verbose levels (0=off, 1=some, 2=more, 3=a lot of details)
• Option: select Module
• Statistics: error count
• Use #defines and Macros
• Interactive shell (terminal)
Pic process
Process
II. Process Dealing with the real-world
• Reviews
• Rule 1: find bugs
• Rule 2: reviewer accepts current design
• Concept of the two Hats [2] (Refactoring)
• Hat 1: Add features
• Hat 2: Fix bugs / change existing code
Pic automated testing
Automated Testing
III. Automated Testing Dealing with the real-world
• Essential part from „Software refactoring“
• Ideal world vs. Real world
• How to do it in small projects
• If?
• What?
• When: From the beginning
• Why?
• Possible approaches
• A) Input, process, compare output
• B) API, more complex testcases
• C) GUI
• D) Integrated
Pic tools
Tools
IV. Tools – your friends Dealing with the real-world
• Compiler
• Debugger
• Diff (Araxis merge)
• Git / revision control (github, bitbucket)
• Bug tracking
Pic optimizing
Optimizing Code for Speed
Optimizing Code for Speed Advanced Topics
• Compiler: -o, -o2
• Measure with a profiler – don‘t speculate
• 20/80 rule (5/95 rule)
• No fancy tricks
Pic embedded
Embedded Software
Embedded Software Tips Advanced Topics
• Automatic state machine generation
• Debug: Logging
• Debug: Use scope: use LED / GPIO’s
• Debug: Debugger
• Init/shutdown
• Memory: allocate static, at beginning
• malloc: Allocate memory at beginning (Memory overwrites with pointers)
• Classic model: main loop, state machine(s), interrupt handler
• ”volatile" for state variables
• Add robustness: expect unexpected timings, broken sensor, not possible states.
• Watchdog
Recommended Reading
• [1] Code Complete 2nd Edition, Steve McConnel
• [2] Refactoring, by Martin Fowler (Improving the design of existing code)
• [3] O‘Reilly Cookbook Series: Arduino, Python, Java...
• [4] The art of software testing, Glenford Myers (first 100 pages)
Pic magic tricks
Summary
Checklist for Software Project Mix and match! Use from the beginning.
• Architecture (1 page, different views, overview)
• Craft (naming)
• Craft – functions: naming, size, structure, few macros
• Craft – variables: init, naming, int, floats, pointers
• Craft - globals
• Automatic error detection (input/ouput checks)
• Compiler warnings
• Automatic health checks
• Error handling concept (report, stop, report+continue)
• Logging
• Interactive console/shell
• Process: reviews
• Process: two hats
• Automated testing
• Tools: diff, debugger, git, bugtracking
• Optimizing at the end
Questions?
Picture References
• Figure 22-1: Code Complete 2
• Sailboat: Robert Durfee, flickr.com
• Arduino: designSpark, flickr.com
• Architecture: Thomas Guignard, flickr.com
• Butterfly: Woodley Wonderworks, flickr.com
• Charlin Chaplin, Modern Times, flickr.com
• Optimizing: Michael Raby, flickr.com
• Mouse trap: Mark Louden, flickr.com
• Boat: UK Ministry of Defence, flickr.com
• Tools: Dan Thompson, flickr.com
• Magician: Pascal (pasukaru76), flickr.com