Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Best practices in enterprise applications

2,691 views

Published on

  • Be the first to comment

Best practices in enterprise applications

  1. 1. Best Practices InEnterprise Applications Prepared By Chandra Sekhar
  2. 2. GOAL To Implement Best Practices in the End to End processes of the Software Development Life Cycle (SDLC).
  3. 3. Hierarchical Classification
  4. 4. Performance Tuning Follow an Iterative, Data driven and Top- Down Methodological Approach. Identifying System level, Application Level and Machine (Middle Layer, Platform Layer) Level. Identifying Resource leaks, memory misuse, aggressive caches, and improperly scoped user data
  5. 5. Process Level Classification Best Practices Best Practices Application ApplicationCodingCoding Design Design Architecture Architecture Server Server Methodology Methodology Management Management
  6. 6. Best Practices in Coding  General Guide Lines..  Web Layer.. (JSP, Servlets, Configuration of the various Frameworks..)  Business Layer..(EJB, Business Components, POJOs, Spring..)  Data Access Layer.. (DAOs, Hibernate Framework, ORM Models )  ASP and its Associate Components.
  7. 7. General Guide Lines-I Avoid writing very long methods. A method should typically have 1~25 lines of code. (For more than 25 lines refactor into separate methods ). Method Name and Signature should tell its Usage and scope. Avoid Misleading method names. Look at the method as micro operations . A method should do only one job. Do not combine more than one job in a single method, even if those jobs are very small. Always watch for unexpected values while making certain validations with conditional operators..
  8. 8. General Guide Lines-2 Avoid Hard Coding Constants. Declare constants in a config file or an interface and make them private static and final variables. Avoid Hard coding Strings. Use them from Application Resources( which is a *.properties file). Avoid sharing the class variables between various methods as it would be unknown where it got changed. Use instance variables and return them appropriately. Do not make the member ( class) variables public or protected. Keep them private and expose public/protected Properties.
  9. 9. General Guide Lines-3 The event handler should not contain the code to perform the required action. Rather call another method from the event handler. (ASP.NET, STRUTS solves the problem) Never hardcode a path or drive name in code. Get the application path programmatically and use relative path. In the application start up, do some kind of "self check" and ensure all required files and dependencies are available in the expected locations. Check for database connection in start up, if required. Give a friendly message to the user in case of any problems.
  10. 10. General Guide Lines-4 Error Messages should be user friendly, which makes the user understand to take next step. There should be a Guide line in the Error Message Thrown. Do not have more than one class in a single file. (Avoid Inner Classes - Applies to the Business Components only and not to the Framework Components). Avoid having very large files. If a single file has more than 1000 lines of code, it is a good candidate for refactoring. Split them logically into two or more classes. (Eases the Class Loading Principle..) Avoid passing too many parameters. Try for a collection object ,class or structure if it requires so.
  11. 11. General Guide Lines-5 Allow returning a Empty Collection Instead of Returning null from a method. It eases checking for the count. Use the AssemblyInfo (Declaration Comments) file to fill information like version number, description, company name, copyright notice etc. Proper Organization of the Folder Structure . By maintaining at least a 2 fold Hierarchy. Code to ensure Proper Logging mechanism, which shows you exception messages, traces with date and time Identification.
  12. 12. General Guide Lines-6 Better Usage Of Regular Expressions (java.util.regex ) will enable you to Avoid Iteration on Characters of the String.. This avoids Memory Leaks also.. Code to identify the expression and evaluate to validate the Input.( E.g.: e-mail, panNo, A/c Number, Any kind of Pattern which have Numbers, Special Characters and Characters) Do not write comments for every line of code and every variable declared. Use Check Style Component for having a proper Indentation, proper declaration. Avoid code Synchronization if not necessary, this may lock the Objects under the monitor Control.
  13. 13. General Guide Lines-7 Use try-catch in your data layer to catch all database exceptions. This exception handler should record all exceptions from the database include the name of the command being executed, stored proc name, parameters, connection string used etc. Never do a catch exception and do nothing. Always try to avoid exceptions by checking all the error conditions programmatically. Avoid coding large try catch blocks which, split the code into small try catch blocks, if there are multiple exceptions at a specific place in the code. Code your own Custom Exceptions for the framework. Do not derive Custom Exceptions from Base Exception. Instead Inherit from Application Exception.
  14. 14. Indentation And Spacing-1 Use TAB for indentation. Do not use SPACES. Define the Tab size as 4. Comments should be in the same level as the code (use the same level of indentation). // Format a message and display string fullMessage = "Hello " + name; DateTime currentTime = DateTime.Now; string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString(); messageBox.Show ( message ); Curly braces ( {} ) should be in the same level as the code outside the braces. Use one blank line to separate logical groups of code.
  15. 15. Indentation And Spacing-2 There should be one and only one single blank line between each method inside the class. The curly braces should be on a separate line and not in the same line as if, for etc. Use a single space before and after each operator and brackets. Grouping the related code Will help you read the methods as per their Signatures.
  16. 16. General Guide Lines-8
  17. 17. Code Reviews Code Reviews Peer Review Architect Review Group Review
  18. 18. Code Reviews-2 Peer Review: Adhering to Standards and best Practices in Coding, another Team Member can review the code. Also Includes Unit- Testing cases. Architect Review: Core Modules of Peer Architect the Project should be reviewed by Review Review the Architect to ensure that they adhere to the design Group Review : • Randomly pick up a file • Distribute them to the team and read them for 30 min • Go through every section of the code and get the suggestions Group from the team for better way of Review coding.. • Do not Forget to Appreciate the Developer While Doing So
  19. 19. ConclusionThis Presentation pertains to the General Coding Guide Lines for all Technologies.

×