1 / 40

Best Practices in Java Development

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

eshe
Download Presentation

Best Practices in Java Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. JA-SIG Summer Conference Denver, CO June 24 – 27, 2007 Best Practices in Java Development

  2. 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

  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.TheThreeRulesOfTdd

  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 person’s 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 can’t 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 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

  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 Don’t let the tests become out of date Don’t 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?”

More Related