Effective feedback from quality tools during development

Transcription

1 Effective feedback from quality tools during development EuroSTAR 2004 Daniel Grenner Enea Systems

2 Current state Project summary of known code issues Individual list of known code issues Views targeted at individuals / roles Information updated daily (at least) Well known project status This presentation will show you how this is done!

3 Original state 20+ developers Not much Java/J2EE experience Varying OO experience New language, tools, processes How should quality be ensured?

4 Initial development practices Coding standards Nightly build Unit tests Code reviews Automated code checks Support from mentors

5 Coding standards Improves maintainability Makes it easier to find strange code Use tool to format code

6 Nightly build Build the system Create documentation Generate reports

7 Unit tests JUnit obvious choice Cactus chosen for in-container tests Fit well into environment Ant tasks useful Unit testing course for all developers

8 Code reviews All code should be reviewed by a mentor tag used To find unreviewed code Work intensive but effective

9 Automated code checks Let a tool do repetitive tasks Reduces review work Allows reviews to focus on difficult problems Small amount of work large payoff

10 Selecting tool for automated checks Useful initial checks Configurable (modify existing checks) Extensible (add new checks) Integration with environment Easy to use License & price Possibility to use several tools

11 Checkstyle Checks for: Coding standards Potential bugs Common problems And much more (100+ checks) Easy to configure Extensible Integrates with Ant & several IDEs Open source

12 Mentoring 4 7 consultants during project Experts in different areas Java / J2EE / Swing / UML / Tasks Teach Answer questions Create project standards Development support

13 Tuning the process Continuous integration Better feedback Continuous follow-up

14 Continuous integration Build when new code is checked in Avoid problems during nightly build Faster feedback

15 Feedback from nightly build Build / compile warnings JavaDoc warnings Checkstyle findings JUnit results All organized differently e.g. by file, subproject, project Findings increased, due to lack of responsibility. Need to simplify daily work Find all information needed daily in a single location

16 Individual feedback Use Checkstyle as base, but group findings based on responsible person instead of file. Added Checkstyle task to into results Sort results with XSLT Immediate decrease in Checkstyle findings Most people wanted good statistics. Some individuals did not improve their results, but follow up became easier.

17 Project summary Individual summary Details ordered by individual

18 Integration of other tools Integrate all results into a single report Checkstyle report JUnit reports (based of test case) Results from build process JavaDoc Javac Code reviews

19 Code review Checkstyle JUnit Javac JavaDoc

20 Separate reports Code review information Optimizeit CodeCoverage

21 Project summary Individual summary Details ordered by individual

22 Technical solution XSLT Ant XML XSLT XML

23 XSLT tasks Merge different information sources Summarize information E.g. calculate statistics Extract missing information E.g. assign author if it is missing Produce readable reports (HTML)

24 XSLT setup One style sheet for each task Simplifies development Decorator pattern More information added each step Merge all / most XML files into one Use Ant s style task

25 Report generation Java source Checkstyle XML XSLT XML Build XML XSLT XML Unit test XML XSLT XML XML XSLT XML XSLT XSLT XSLT HTML HTML HTML

26 Tool requirements Automation Ant (first choice) Command-line (if Ant interface is not available) Assigned person (possible for e.g. weekly task) Output format XML directly Possible to convert to XML Output content Preferably with file reference (enables merging)

27 Technical details More information is provided in the paper

28 Continuous follow-up Set up goals / limits in project E.g. 80% code coverage during unit test E.g. < 20 Checkstyle findings / developer 0 issues / person not always possible during dev. Update tool settings to allow or disallow new things E.g. when common coding error found When exceptions to rules are needed

29 Who should perform follow-up? First solution Follow up by QA responsible Discussion about standards Second solution Non-technical person. Discussions pointless Special cases Report to management Use results e.g. as input to salary review

30 Summary Automate as much as possible Most cost-effective solution Simplify for developers Target report to recipients Follow-up of results

31 More information me: Tools:

32 Questions?