410 likes | 592 Views
JA-SIG Summer Conference Denver, CO June 24 – 27, 2007. Best Practices in Java Development. Who am I?. I’m Scott Battaglia! Application Developer @ Rutgers Java Developer for 5+ Years Lead Developer/Architect on JA-SIG CAS Committer to Acegi Security. Agenda. Methodologies
E N D
JA-SIG Summer Conference Denver, CO June 24 – 27, 2007 Best Practices in Java Development
Who am I? I’m Scott Battaglia! Application Developer @ Rutgers Java Developer for 5+ Years Lead Developer/Architect on JA-SIG CAS Committer to Acegi Security
Agenda Methodologies Language Features Non Language Specific Tool Chest Discussion
1. Methodologies
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
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.TheThreeRulesOfTdd
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.
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.
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
Domain Driven Design Models the business domain concepts Maps to Screens and DB Easier to test, and change Reusable (different application clients)
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 person’s name
Iterative Development • Cyclic/incremental • Milestones, Release Candidates… • Feedback before its too late! • Allows you to take advantage of previously gained knowledge
Code Reviews Systematic examination of course code Goals Improve quality of code Share knowledge Ideally… Short Focused on code Many ways of doing it
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
2. Language Features
“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
StringBuilder Usage: final StringBuilder builder = new StringBuilder(50); builder.append(“myString”); builder.append(“moreOfMyString”); StringBuilder vs. StringBuffer vs String “Best Guess” StringBuilder size
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}
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
PreparedStatements Statements vs. PreparedStatements Advantages: Compiled Correctly escape characters As of JDBC 3, can be pooled
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
3. Non-Language Specific
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
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).
Interfaces Interface vs. Abstract Class Coding to Interfaces Examples Collections Framework CAS
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
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 can’t be.
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
Documentation & Comments Documentation is pretty much the bane of all developer’s existences Be sure to place comments in code, but don’t put too much // send the mail message javaMailSender.send(message); You never know when you need to revisit your code Document methods, classes, configuration
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 Don’t let the tests become out of date Don’t throw them away when they stop passing - fix them!
4. Tool Chest
5. Discussion
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
? What are Your “Best Practices?”