Java Development Best Practices
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Java Development Best Practices as PDF for free.
More details
- Words: 2,064
- Pages: 39
Java Development Best Practices Simon Brown, Senior Consultant
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 2
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 3
Presentation Objectives Provide an overview of the following Cormorant MFE development practices, how to implement them and how they provide real benefit – – –
Automated unit testing Continuous integration Project blogs
To discuss other best practices that we have used in the past and/or should be using in the future
Ref:
www.evolution.net
Page 4
A quote from a blog entry… On August 4 we had a session on software engineering. The aim of the session was to share knowledge and experience about the way we develop software and to discuss the importance of doing it a certain way. After the break we had a workshop that briefly touched the different parts of the software development process. The quiz on current real-life practices raised a lot of discussion. While we all recognize the importance of source control, automation of manual tasks, testing, documentation and proper incident management many of us fail in a proper implementation of these practices. AMIS Technology Corner : On Software Engineering http://technology.amis.nl/blog/index.php?p=695
Ref:
www.evolution.net
Page 5
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 6
Automated unit testing Automated unit testing now an established technique – –
You write some code Then you write more code to test it
Many frameworks exist for automated unit testing with Java – –
Ref:
Most popular is Junit 3.8.x Others include TestNG and JUnit 4.0
www.evolution.net
Page 7
Automated unit testing
Ref:
method1
testMethod1
method2
testMethod2
methodN
testMethodN
Real class
Test class
www.evolution.net
Page 8
Automated unit testing Yes… – – – –
More code needs to be written Estimates will increase It’s a new way of working It feels weird, perhaps pointless initially
But… – – – – – – Ref:
Automated unit testing is very powerful Lets you regression test code for free! Helps you write cleaner code Provides a good milestone for completion Provides confidence when changing, fixing or refactoring code If you can write code, you can write a unit test! www.evolution.net
Page 9
Adoption of automated unit testing New code –
Write tests for new code
Existing code that needs to be modified… – – – –
Look at the unit tests If tests exist, they will help ensure you don’t break anything through unknown side effects If tests don’t exist, write some to cover the area of the code you are changing No need to retrofit the entire code base with unit tests at once • •
Ref:
Too expensive! Take an iterative approach
www.evolution.net
Page 10
Adoption of automated unit testing A defect is raised… – – – – – –
Ref:
Look at the unit tests Write a unit test to prove the bug - make sure its reproducible Fix the bug The new test will pass Check-in the fix and new test Chances of reoccurrence are greatly reduced
www.evolution.net
Page 11
Adoption of automated unit testing Don’t mandate 100% unit test coverage - it’s too hard and too expensive Do use a code coverage tool (more on this later) Do add tests when you see they don’t already exist Do write tests to prove bugs Do run your tests frequently Do make sure the tests execute quickly Don’t let the tests become out of date Don’t throw them away when they stop passing - fix them! Do treat them as an important deliverable Do include them in code reviews
Ref:
www.evolution.net
Page 12
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 13
Cormorant development environment
Developer PC Developer PC Commit code
Developer PC
Developer PC
Weblog
Source code Control (Subversion)
Continuous Integration Server Check-out code
Server
Ref:
www.evolution.net
Page 14
Manual build process Manual builds performed using Eclipse and command line tools Scripted builds performed using Ant and existing script – – –
Ref:
Compile Java code Build EAR file Generate distribution for release to system test
www.evolution.net
Page 15
Scheduled, scripted builds Scheduled, scripted builds performed by CruiseControl and Ant – – – – –
Build scheduled every hour/30 minutes Clean copy of code checked out from Subversion Compile, build EAR file and run unit (JUnit) tests Build results published to CruiseControl web application Build results also published to build blog
CruiseControl was our sixth team member!
Ref:
www.evolution.net
Page 16
Benefits of scheduled, scripted builds Forces more frequent, iterative integration rather than bigbang approach – –
–
Forces compilation of clean codebase Finds compilation problems where developers have not updated their local copy of code before checking in changes Frequent (continuous) integration is easier and quicker to perform, reducing risk of slippage
Forces execution of unit tests – –
–
Ref:
Automatically runs all unit tests whenever the codebase changes Finds problems when developers have not run tests before checking in changes Provides a level of continuous quality assurance www.evolution.net
Page 17
Setting up continuous integration CruiseControl installed on a PC (can be developer PC) – –
Configured to look at the repository every hour for changes If changes are found, code is checked out and build executed
CruiseControl provides native integration with CVS, Subversion, ClearCase, etc Also look at other continuous integration servers such as Anthill
Ref:
www.evolution.net
Page 18
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 19
What is a blog? Blog, short for weblog : a web-based log or diary Less formal than static project websites or wikis Information stored on a temporal basis Useful for recording snippets of information as they are encountered –
–
Project information, development tips, environment gotchas, login information, links to documents, documents, instructions, guidelines, links to external resources, status reports, etc Also build information and test results
An alternative to sending out short e-mail memos Can be searched, archived and exported Web-based access means easy distribution of information Low maintenance
Ref:
www.evolution.net
Page 20
Project blogs R athe r than have a single blog for the proje ct, the re are two: • Te am blog (use d for proje ct inform ation). • Build blog (use d for build re ports).
Ref:
www.evolution.net
Page 21
Team blog This is the proje ct te am blog and is use d for sharing inform ation about any aspe ct of the proje ct. • All Evolution te am m e m be rs can contribute to this and have acce ss to do so. • Anybody in the e x te nde d te am can le ave com m e nts, but only the Evolution te am can add conte nt. • Inste ad of writing e m ail m e m os, conte nt is publishe d to the blog and a link se nt to the te am . • Since blog conte nt is HTML, it’s e asy to e m be d im age s and link to proje ct arte facts. • W ith an R SS re ade r installe d on e ach de sk top, the te am is autom atically notifie d of ne w conte nt.
Ref:
www.evolution.net
Page 22
Build blog This is the proje ct build blog and is use d to publish build sum m arie s. • C ruise C ontrol pe rform s a che ck out/build e ach hour and publishe s the re sults. • W ith an R SS re ade r, the te am is autom atically notifie d afte r builds occur. • Anybody can le ave com m e nts, but this blog has be e n configure d so that only C ruise C ontrol can publish conte nt.
Ref:
www.evolution.net
Page 23
Summary page This is the sum m ary page for both blogs, showing the last thre e e ntrie s that have be e n poste d to e ach. • Navigation is the sam e for the othe r blogs and click ing on link s in the cale ndar shows all conte nt for that pe riod. • The Today link (top) shows all conte nt publishe d today across both blogs. • The R SS/R DF/Atom link s (top) allow a ne wsre ade r application to subscribe to both blogs via a single fe e d.
Ref:
www.evolution.net
Page 24
Blog is green, build is clean! Through som e custom ization, the blog is use d as a form of e x tre m e fe e dback de vice : • Gre e n m e ans the last build was succe ssful. • R e d m e ans the last build faile d. • The m ain page of the blog is se t to autom atically re fre sh e ve ry fe w m inute s.
Ref:
www.evolution.net
Page 25
Blog is green, build is clean! Through som e custom ization, the blog is use d as a form of e x tre m e fe e dback de vice : • Gre e n m e ans the last build was succe ssful. • R e d m e ans the last build faile d. • The m ain page of the blog is se t to autom atically re fre sh e ve ry fe w m inute s.
Ref:
www.evolution.net
Page 26
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 27
Roundtable discussion about other best practices Code coverage –
Clover, jcoverage, etc
Automatic conformance to standards –
Checkstyle, PMD, etc
Tracking metrics over time –
QALab
Automated acceptance testing –
HttpUnit, Canoo WebTest, etc
Demos of Clover and Canoo WebTest
Ref:
www.evolution.net
Page 28
Clover in IntelliJ IDEA
Ref:
www.evolution.net
Page 29
Clover HTML reports
Ref:
www.evolution.net
Page 30
Canoo WebTest script ]> <project name="test" basedir="." default="main"> &definition; <webtest name="login"> &config; <steps>
Ref:
www.evolution.net
Page 31
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 32
Automated unit testing summary Easy to setup Easy to get to grips with Increases confidence that a solution/fixes/changes work Ensures a certain level of continuous quality assurance
Ref:
www.evolution.net
Page 33
Automated unit testing software JUnit – – – –
–
Ref:
Open source Easy to install and configure Integrates with Ant for scripted builds Integrated with Eclipse allowing tests to be written and run very quickly http://www.junit.org
www.evolution.net
Page 34
Continuous integration summary Easy to setup Doesn’t require much processing power Doesn’t require a dedicated box Doesn’t require expensive software –
Open source software used in MFE development environment
Provides early warning signs to integration problems – –
Code not compiling Unit tests failing
Helps developers integrate more smoothly Ensures a certain level of continuous quality assurance
Ref:
www.evolution.net
Page 35
Continuous integration software CruiseControl – – –
– – –
Ref:
Open source Easy to install and configure Native integration with all leading/standard source code control interfaces Can publish build reports via e-mail, XML, HTML, blogs, etc Only performs builds when code in repository has changed http://cruisecontrol.sourceforge.net
www.evolution.net
Page 36
Project blog summary Also don’t require much processing power, a dedicated box or expensive software Provides a way to easily publish information to the project team – –
Can be searched, archived and exported Easily distributed to extended project team
Team members can subscribe to the information they want to receive A useful feedback mechanism when combined with continuous integration
Ref:
www.evolution.net
Page 37
Project blog software Pebble – – – – – –
–
Ref:
Open source Easy to install and configure Runs on most J2EE web/application servers (e.g. Tomcat) Flexible security roles Integrates with enterprise authentication mechanisms Supports standard interfaces such as Atom/RSS newsfeed formats and XML-RPC http://pebble.sourceforge.net
www.evolution.net
Page 38
Questions? [email protected]
Ref:
www.evolution.net
Page 39
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 2
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 3
Presentation Objectives Provide an overview of the following Cormorant MFE development practices, how to implement them and how they provide real benefit – – –
Automated unit testing Continuous integration Project blogs
To discuss other best practices that we have used in the past and/or should be using in the future
Ref:
www.evolution.net
Page 4
A quote from a blog entry… On August 4 we had a session on software engineering. The aim of the session was to share knowledge and experience about the way we develop software and to discuss the importance of doing it a certain way. After the break we had a workshop that briefly touched the different parts of the software development process. The quiz on current real-life practices raised a lot of discussion. While we all recognize the importance of source control, automation of manual tasks, testing, documentation and proper incident management many of us fail in a proper implementation of these practices. AMIS Technology Corner : On Software Engineering http://technology.amis.nl/blog/index.php?p=695
Ref:
www.evolution.net
Page 5
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 6
Automated unit testing Automated unit testing now an established technique – –
You write some code Then you write more code to test it
Many frameworks exist for automated unit testing with Java – –
Ref:
Most popular is Junit 3.8.x Others include TestNG and JUnit 4.0
www.evolution.net
Page 7
Automated unit testing
Ref:
method1
testMethod1
method2
testMethod2
methodN
testMethodN
Real class
Test class
www.evolution.net
Page 8
Automated unit testing Yes… – – – –
More code needs to be written Estimates will increase It’s a new way of working It feels weird, perhaps pointless initially
But… – – – – – – Ref:
Automated unit testing is very powerful Lets you regression test code for free! Helps you write cleaner code Provides a good milestone for completion Provides confidence when changing, fixing or refactoring code If you can write code, you can write a unit test! www.evolution.net
Page 9
Adoption of automated unit testing New code –
Write tests for new code
Existing code that needs to be modified… – – – –
Look at the unit tests If tests exist, they will help ensure you don’t break anything through unknown side effects If tests don’t exist, write some to cover the area of the code you are changing No need to retrofit the entire code base with unit tests at once • •
Ref:
Too expensive! Take an iterative approach
www.evolution.net
Page 10
Adoption of automated unit testing A defect is raised… – – – – – –
Ref:
Look at the unit tests Write a unit test to prove the bug - make sure its reproducible Fix the bug The new test will pass Check-in the fix and new test Chances of reoccurrence are greatly reduced
www.evolution.net
Page 11
Adoption of automated unit testing Don’t mandate 100% unit test coverage - it’s too hard and too expensive Do use a code coverage tool (more on this later) Do add tests when you see they don’t already exist Do write tests to prove bugs Do run your tests frequently Do make sure the tests execute quickly Don’t let the tests become out of date Don’t throw them away when they stop passing - fix them! Do treat them as an important deliverable Do include them in code reviews
Ref:
www.evolution.net
Page 12
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 13
Cormorant development environment
Developer PC Developer PC Commit code
Developer PC
Developer PC
Weblog
Source code Control (Subversion)
Continuous Integration Server Check-out code
Server
Ref:
www.evolution.net
Page 14
Manual build process Manual builds performed using Eclipse and command line tools Scripted builds performed using Ant and existing script – – –
Ref:
Compile Java code Build EAR file Generate distribution for release to system test
www.evolution.net
Page 15
Scheduled, scripted builds Scheduled, scripted builds performed by CruiseControl and Ant – – – – –
Build scheduled every hour/30 minutes Clean copy of code checked out from Subversion Compile, build EAR file and run unit (JUnit) tests Build results published to CruiseControl web application Build results also published to build blog
CruiseControl was our sixth team member!
Ref:
www.evolution.net
Page 16
Benefits of scheduled, scripted builds Forces more frequent, iterative integration rather than bigbang approach – –
–
Forces compilation of clean codebase Finds compilation problems where developers have not updated their local copy of code before checking in changes Frequent (continuous) integration is easier and quicker to perform, reducing risk of slippage
Forces execution of unit tests – –
–
Ref:
Automatically runs all unit tests whenever the codebase changes Finds problems when developers have not run tests before checking in changes Provides a level of continuous quality assurance www.evolution.net
Page 17
Setting up continuous integration CruiseControl installed on a PC (can be developer PC) – –
Configured to look at the repository every hour for changes If changes are found, code is checked out and build executed
CruiseControl provides native integration with CVS, Subversion, ClearCase, etc Also look at other continuous integration servers such as Anthill
Ref:
www.evolution.net
Page 18
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 19
What is a blog? Blog, short for weblog : a web-based log or diary Less formal than static project websites or wikis Information stored on a temporal basis Useful for recording snippets of information as they are encountered –
–
Project information, development tips, environment gotchas, login information, links to documents, documents, instructions, guidelines, links to external resources, status reports, etc Also build information and test results
An alternative to sending out short e-mail memos Can be searched, archived and exported Web-based access means easy distribution of information Low maintenance
Ref:
www.evolution.net
Page 20
Project blogs R athe r than have a single blog for the proje ct, the re are two: • Te am blog (use d for proje ct inform ation). • Build blog (use d for build re ports).
Ref:
www.evolution.net
Page 21
Team blog This is the proje ct te am blog and is use d for sharing inform ation about any aspe ct of the proje ct. • All Evolution te am m e m be rs can contribute to this and have acce ss to do so. • Anybody in the e x te nde d te am can le ave com m e nts, but only the Evolution te am can add conte nt. • Inste ad of writing e m ail m e m os, conte nt is publishe d to the blog and a link se nt to the te am . • Since blog conte nt is HTML, it’s e asy to e m be d im age s and link to proje ct arte facts. • W ith an R SS re ade r installe d on e ach de sk top, the te am is autom atically notifie d of ne w conte nt.
Ref:
www.evolution.net
Page 22
Build blog This is the proje ct build blog and is use d to publish build sum m arie s. • C ruise C ontrol pe rform s a che ck out/build e ach hour and publishe s the re sults. • W ith an R SS re ade r, the te am is autom atically notifie d afte r builds occur. • Anybody can le ave com m e nts, but this blog has be e n configure d so that only C ruise C ontrol can publish conte nt.
Ref:
www.evolution.net
Page 23
Summary page This is the sum m ary page for both blogs, showing the last thre e e ntrie s that have be e n poste d to e ach. • Navigation is the sam e for the othe r blogs and click ing on link s in the cale ndar shows all conte nt for that pe riod. • The Today link (top) shows all conte nt publishe d today across both blogs. • The R SS/R DF/Atom link s (top) allow a ne wsre ade r application to subscribe to both blogs via a single fe e d.
Ref:
www.evolution.net
Page 24
Blog is green, build is clean! Through som e custom ization, the blog is use d as a form of e x tre m e fe e dback de vice : • Gre e n m e ans the last build was succe ssful. • R e d m e ans the last build faile d. • The m ain page of the blog is se t to autom atically re fre sh e ve ry fe w m inute s.
Ref:
www.evolution.net
Page 25
Blog is green, build is clean! Through som e custom ization, the blog is use d as a form of e x tre m e fe e dback de vice : • Gre e n m e ans the last build was succe ssful. • R e d m e ans the last build faile d. • The m ain page of the blog is se t to autom atically re fre sh e ve ry fe w m inute s.
Ref:
www.evolution.net
Page 26
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 27
Roundtable discussion about other best practices Code coverage –
Clover, jcoverage, etc
Automatic conformance to standards –
Checkstyle, PMD, etc
Tracking metrics over time –
QALab
Automated acceptance testing –
HttpUnit, Canoo WebTest, etc
Demos of Clover and Canoo WebTest
Ref:
www.evolution.net
Page 28
Clover in IntelliJ IDEA
Ref:
www.evolution.net
Page 29
Clover HTML reports
Ref:
www.evolution.net
Page 30
Canoo WebTest script ]> <project name="test" basedir="." default="main"> &definition;
Ref:
www.evolution.net
Page 31
Contents Presentation Objectives Automated unit testing Continuous integration Project blogs Other best practices Summary
Ref:
www.evolution.net
Page 32
Automated unit testing summary Easy to setup Easy to get to grips with Increases confidence that a solution/fixes/changes work Ensures a certain level of continuous quality assurance
Ref:
www.evolution.net
Page 33
Automated unit testing software JUnit – – – –
–
Ref:
Open source Easy to install and configure Integrates with Ant for scripted builds Integrated with Eclipse allowing tests to be written and run very quickly http://www.junit.org
www.evolution.net
Page 34
Continuous integration summary Easy to setup Doesn’t require much processing power Doesn’t require a dedicated box Doesn’t require expensive software –
Open source software used in MFE development environment
Provides early warning signs to integration problems – –
Code not compiling Unit tests failing
Helps developers integrate more smoothly Ensures a certain level of continuous quality assurance
Ref:
www.evolution.net
Page 35
Continuous integration software CruiseControl – – –
– – –
Ref:
Open source Easy to install and configure Native integration with all leading/standard source code control interfaces Can publish build reports via e-mail, XML, HTML, blogs, etc Only performs builds when code in repository has changed http://cruisecontrol.sourceforge.net
www.evolution.net
Page 36
Project blog summary Also don’t require much processing power, a dedicated box or expensive software Provides a way to easily publish information to the project team – –
Can be searched, archived and exported Easily distributed to extended project team
Team members can subscribe to the information they want to receive A useful feedback mechanism when combined with continuous integration
Ref:
www.evolution.net
Page 37
Project blog software Pebble – – – – – –
–
Ref:
Open source Easy to install and configure Runs on most J2EE web/application servers (e.g. Tomcat) Flexible security roles Integrates with enterprise authentication mechanisms Supports standard interfaces such as Atom/RSS newsfeed formats and XML-RPC http://pebble.sourceforge.net
www.evolution.net
Page 38
Questions? [email protected]
Ref:
www.evolution.net
Page 39
Related Documents
Java Development Best Practices
October 2019 21
Best-practices For Development
November 2019 37
Php Development Best Practices
October 2019 22
Offerings Development Best Practices
August 2019 27
Best-practices
July 2020 22