This document outlines best practices for implementing best practices across the software development life cycle (SDLC). It discusses hierarchical classification of performance tuning at the system, application, and machine levels. It also covers best practices for coding, including general guidelines, guidelines for specific technologies like JSP and EJB, and practices for code reviews like peer reviews and architect reviews. The goal is to apply best practices throughout the end-to-end processes of the SDLC.
This presentation was created as part of the module Enterprise Systems Development. In this, we compare the packaged software development with custom software development (based on the paper by sawyer)
This presentation was created as part of the module Enterprise Systems Development. In this, we compare the packaged software development with custom software development (based on the paper by sawyer)
object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.
Dear students get fully solved assignments
Send your semester & Specialization name to our mail id :
“ help.mbaassignments@gmail.com ”
or
Call us at : 08263069601
Best coding practices to follow - to write a code, like a bossAvil Porwal
Accurate code is always a good code, but accurate and organized code is the better code. Your program should be quick to scan and easy to understand. Few habits to take care of while writing code, can make your code readable and lovable.
Clean Code - Design Patterns and Best Practices at Silicon Valley Code CampTheo Jungeblut
Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code.
You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012.
However, the demonstrated patterns and practice can be applied to almost every other programming language too.
object oriented analysis and design.
requirement analysis.
what is requirement?
types of requirement.
functional requirements.
nonfunctional requirements.
Dear students get fully solved assignments
Send your semester & Specialization name to our mail id :
“ help.mbaassignments@gmail.com ”
or
Call us at : 08263069601
Best coding practices to follow - to write a code, like a bossAvil Porwal
Accurate code is always a good code, but accurate and organized code is the better code. Your program should be quick to scan and easy to understand. Few habits to take care of while writing code, can make your code readable and lovable.
Clean Code - Design Patterns and Best Practices at Silicon Valley Code CampTheo Jungeblut
Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code.
You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way. You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012.
However, the demonstrated patterns and practice can be applied to almost every other programming language too.
How to do code review and use analysis tool in software developmentMitosis Technology
Code Inspection is a phase of the software development process to find and correct the errors in the functional and non-functional area in the early stage.
Some of the most common and easy-to-calculate/easy-to-measure code metrics. Understanding these can help you make your code better: avoiding code rot and writing maintainable code all starts here. Content is created for C# .net, however, the underlying principles apply to other languages/frameworks as well.
Back-2-Basics: .NET Coding Standards For The Real WorldDavid McCarter
This session will guide any level of programmer to greater productivity by providing the information needed to write consistent, maintainable code. Learn about project setup, assembly layout, code style, defensive programming and much, much more. We will even go over some real in production code and see what the programmer did wrong in "What's Wrong With this Code?". Code tips are included to help you write better, error free applications. Lots of code examples in C# and VB.NET.
Back-2-Basics: .NET Coding Standards For The Real WorldDavid McCarter
This session will guide any level of programmer to greater productivity by providing the information needed to write consistent, maintainable code. Learn about project setup, assembly layout, code style, defensive programming and much, much more. We will even go over some real in production code and see what the programmer did wrong in "What's Wrong With this Code?". Code tips are included to help you write better, error free applications. Lots of code examples in C# and VB.NET.
Best practice adoption (and lack there of)John Pape
This is a short presentation I created some time ago that details some of the developmental, procedural, and infrastructure best practices that I discovered while working with various customers.
Similar to Best practices in enterprise applications (20)
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. Process Level Classification
Best Practices
Best Practices
Application
Application
Coding
Coding Design
Design Architecture
Architecture Server
Server Methodology
Methodology
Management
Management
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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
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