Best Practices in Java Development

1
Best Practices in Java Development

• JA-SIG Summer Conference
• Denver, CO
• June 24 27, 2007

2
Who am I?

• Im Scott Battaglia!
• Application Developer _at_ Rutgers
• Java Developer for 5 Years
• Lead Developer/Architect on JA-SIG CAS
• Committer to Acegi Security

3
Agenda

• Methodologies
• Language Features
• Non Language Specific
• Tool Chest
• Discussion

4
1.
Methodologies
5
Test Driven Development

• Writing a test case and implementing only code
  necessary to pass test
• A method of designing software, not merely a
  method of testing
• Can still produce crappy code
• Unit vs. Integration Tests
• Useful when used judiciously

6
Test Driven Development

• Three rules from Uncle Bob
• 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.
• http//butunclebob.com/ArticleS.UncleBob.TheThreeR
  ulesOfTdd

7
Test Driven Development

• What makes a good unit test?
• Run fast (they have short setups, run times, and
  break downs).
• Run in isolation (you should be able to reorder
  them).
• Use data that makes them easy to read and to
  understand.
• Use real data (e.g. copies of production data)
  when they need to.
• Represent one step towards your overall goal.

8
Domain Driven Design

• The premise of domain-driven design is two-fold
• For most software projects, the primary focus
  should be on the domain and domain logic and
• Complex domain designs should be based on a
  model.

9
Domain Driven Design

• Business people talk naturally in Business terms
  (using ubiquitous language)
• - Open grading period, Pending class roster,
  Student eligible for grading, Course grading
  policy, etc.
• Objects shift language from data to behavior
• - Away from flags and if conditions
• - Toward responsibilities and naming

10
Domain Driven Design

• Models the business domain concepts
• Maps to Screens and DB
• Easier to test, and change
• Reusable (different application clients)?

11
Domain Driven Design

• Business logic can be complex
• - Rules in Domain Model (DM) describe the many
  cases variations
• DM creates a web of interconnected objects where
  each represents a meaningful concept some as
  large as an entire company or as small as a
  persons name

12
Iterative Development

• Cyclic/incremental
• Milestones, Release Candidates
• Feedback before its too late!
• Allows you to take advantage of previously gained
  knowledge

13
Code Reviews

• Systematic examination of course code
• Goals
• Improve quality of code
• Share knowledge
• Ideally
• Short
• Focused on code
• Many ways of doing it

14
Aspect Oriented Programming

• Deals with the separation of concerns
  (cross-cutting concerns)?
• Breaking down a program into distinct parts that
  overlap in functionality as little as possible
• Examples
• Transactions, logging, security, ContractByDesign

15
2.
Language Features
16
final Keyword

• Used as follows
• final Object o new Object()
• Advantages
• Prevents accidental assigning of variables
• Turns logical errors into compile errors
• JVM can optimize final constants
• Limit Scope of Variables
• Gotchas
• Final primitives and Strings are substituted at
  compile-time
• Final means no variable re-assignment

17
StringBuilder

• Usage
• final StringBuilder builder new
  StringBuilder(50)
• builder.append(myString)
• builder.append(moreOfMyString)
• StringBuilder vs. StringBuffer vs String
• Best Guess StringBuilder size

18
Enumerations

• Traditional Enumerations
• public final int ENUM_VALUE_1 1
• public final int ENUM_VALUE_2 2
• Type Safe Enums
• Implementation of Java classes
• Java 5 Enumerations
• enum COLOR BLACK, WHITE, RED, GREEN, BLUE,
  YELLOW

19
JPA

• JPA is
• Java Persistence API
• -Entities
• Java Persistence Query Language
• Advantages
• Pluggable backend (TopLink, Hibernate, etc.)?
• Database agnostic DAO layer
• No complex mapping files
• Disadvantages
• Difficult to retrofit legacy tables

20
PreparedStatements

• Statements vs. PreparedStatements
• Advantages
• Compiled
• Correctly escape characters
• As of JDBC 3, can be pooled

21
Annotations

• Extra information associated with Class, Method,
  Variables
• Most useful for non-frequently changing
  information
• Keeps meta data and object together
• Examples
• Spring Transactions
• CAS Property Validation

22
3.
Non-Language Specific
23
Design Patterns

• Recurring solutions to common problems
• Solve design problems not computational problems
• Five types of Patterns
• Benefits
• Easy to understand code
• General solutions
• Allow people to communicate using the same
  language

24
Model-View-Controller

• Division of Labor into the following parts
• Those responsible for business logic (the Model
  -- often implemented using Enterprise JavaBeans
  or plain old Java objects).
• Those responsible for presentation of the user
  interface (the View).
• Those responsible for application navigation (the
  Controller -- usually implemented with Java
  servlets or associated classes like Struts
  controllers).

25
Interfaces

• Interface vs. Abstract Class
• Coding to Interfaces
• Examples
• Collections Framework
• CAS

26
Logging

• Makes debugging easier
• Everywhere you would have put a System.out, put a
  logger statement
• log.isXXXXEnabled() vs. log.XXXX(data)?
• Logging via AOP

27
Exception vs. Runtime Exception

• Two types of Exceptions in Java
• Exception (checked)?
• Runtime Exception (unchecked)?
• Checked Exceptions indicate something that can be
  handled.
• Unchecked Exceptions indicate something that
  cant be.

28
Don't Re-Invent the Wheel

• Use Common well know frameworks
• Spring, Hibernate, Web Flow, Acegi...
• Don't fall for not invented here syndrome
• Balance needs of application vs. library

29
Documentation Comments

• Documentation is pretty much the bane of all
  developers existences
• Be sure to place comments in code, but dont put
  too much
• // send the mail message
• javaMailSender.send(message)
• You never know when you need to revisit your code
• Document methods, classes, configuration

30
Unit Testing

• Use a Code Coverage tool
• Don't Mandate 100 test coverage
• Add tests when you see they don't exist
• Add tests to prove a bug
• Run your tests frequently
• Make sure the tests execute quickly
• Dont let the tests become out of date
• Dont throw them away when they stop passing -
  fix them!

31
4.
Tool Chest
32
Build Tools
33
Wiki
34
Issue Tracking
35
Continuous Integration
36
Version Control
37
Integrated Development Environment
38
5.
Discussion
39
Further Reading..

• Thinking in Java by Bruce Eckel
• J2EE Design and Development by Rod Johnson
• Refactoring Improving the Design of Existing
  Code by Martin Fowler
• Effective Java by Joshua Bloch
• Domain Driven Design by Eric Evans

40
?
What are Your Best Practices?