Justification for Standards
Standards are not created for the sake of keeping people in roles, or for making up work for developers to undertake; they have specific cost and resource benefit when adopted and applied consistently on all software development projects.
The primary goal of the standards is to reduce the diversity in application design and implementation such that disparate teams may successfully work on the delivery of common global systems. The benefits of this approach are huge. By working together with a common approach, resources are able to move between projects, products and teams. At the same time this allows regional centres to leverage the abilities of staff at a global level, while ensuring the quality of that work and the developed artifacts; in short it ensures that the application is always maintainable, wherever it's constructed. Over time this ensures that training costs are reduced, code becomes reusable at a global level and resource management becomes more efficient.
The biggest benefit of using these standards comes from the fact they're based solely on methods and experience that has been proven to work. In other words, they bring together the design principles, practices and patterns, together with the coding standards and guidelines that come with experience. For all development staff, and in particular new developers, the R2 Development Practices and Standards should be the first-stop, one-stop resource on how HSBC applications should be built.
Below, we take the salient points from the above justification and explore each in more detail.
Standards Increase Efficiency
According to industry experts, software developers can spend up to forty percent of project time fixing issues that could have been resolved earlier, or could have been prevented if the right measures where in place (Software Defect Reduction Top 10 List, Software Management Magazine, January 2001). To put this another way: for every 5 days of project work, only around 3 of those days are actually delivering anything new; up to 2 days are spent correcting the work done within the previous 3 days. Does this sound familiar? Perhaps not on a week-by-week basis, but certainly over the lifetime of the project where the period of time spent in testing increases, the number of defects found and raised seems to be excessively large, etc.
Standards therefore aim to prevent problems early. That is by preventing erroneous code to be written, through the promotion of good practices which produce quality deliverables in overall smaller periods of time, and by providing any number of pre-determined solutions that can be "dropped-in" where specific software solutions are required. In some instances time is saved in the initial development, whereas in other instances the development time may increase marginally, however in all cases the amount of time spent in testing and defect resolution decreased thus leasing to an overall increase in productivity across the whole of the project.
Furthermore by promoting a component-based approach to software development which facilitates reuse (see below) it's possible to run projects where many of the software assets have already been created and simply need to be configured and reused in new solutions. Again, development effort is reduced and testing and defect resolution improved.
Standards Reduce Costs and Risk of Failure
According to Information Week, programmers inject around one error for every 10 lines of code they write (The State of Software, Information Week, 21 May 2001). Without any process to ensure that code is constructed correctly, there's a reliance on the developers to ensure that code is error-free. Even experienced developers may introduce flaws into the code base when rushing to meet project deadlines, often with perilous consequences later in the project life-cycle. We all know that the cost of fixing these errors depends on how soon they're found: if found during development, errors are can be up to 100 times cheaper than if found during the delivery or release phases (Software Defect Reduction Top 10 List, Software Management Magazine, January 2001).
It's critical therefore that all software development takes place in an environment that is hostile to errors and coding flaws. The practices and standards aim to provide that environment by attempting to detect poorly written code as soon as it's developed, when it's at the easiest and cheapest point to fix. Without preventative measures in place, without the quality control metrics and QA processes, project costs increase as the excessive number of flaws and defects found during later phases of the project life-cycle result in elements of the development phase being replayed.
Standards Reduce Complexity
For any given software problem, there are usually any number of different ways in which that problem can be solved. Some of those solutions will be fast and highly efficient, others will have a low memory footprint, others still may offer no tangible benefits. The more complex solutions generally speaking will have a higher probability of containing errors, although they may be the only possible way in which the QoS (Quality of Service) parameters may be achieved. The software design and coding standards therefore aim to reduce this complexity where it's not required, thus ensuring a corresponding reduction in the probability of errors being introduced; at the same time, complex solutions where necessary are presented as a set of "drop-in" patterns or solutions that have been previously tested and are known to be free from most common errors. This "drop-in" approach in turn ensures that the complexity of the overall solution being developed is hidden from the developer to a degree, thus allowing the developer to concentrate on ensuring that any code they write is error free.
Standards Highlight Costs
Adopting a standard process by which software projects are executed and by which the software itself is written, enables the creation of supporting standards in the cost analysis space. For example, common estimating calculators can be created which specify all known costs associated with the development process. These standard approaches to project cost assessment generally rely on the fact that the software development phase achieves a certain level of quality which ensures that subsequent test and deployment phases have low number of defects and flaws raised. Likewise period reviews that are integrated into the standard processes ensure that quality control and quality assessment are integral to the software development, ensuring that true costs are known and issues are not hidden. Also, by ensuring that problems are traceable to specific business requirements, it can be seen whether any of the software defects may result in additional business costs (for example, by having to refund customer fees, etc.) as soon as the defects are found.
Standards Facilitate Code Reuse
The development processes and standards promote the creation of component-based designed, with each component being clean and robust such that these modules may be reused in other software solutions. Code written to these standards is also easier to move between platforms and easier to keep up to date as the industry technology standards change. As always, bespoke standards and bespoke solutions to problems generally back developers into a corner when in comes to platform migration or upgrade, often resulting in full redevelopment of the system rather than a simple migration. Enforcing known standards on all code that is created ensures that the cost of undertaking migrations, the cost of extending existing functionality, and the cost of reusing solutions in other products is kept to a minimum.
Standards Enable Staffing Flexibility
Bespoke solutions require in-depth bespoke knowledge of that solution. Conversely, industry standard solutions only require knowledge of that industry standard, and some background information on the overall solution within which it's employed. As more and more software systems adopt the same set of standards, the ability for developers to work on the different systems that adopt those standards becomes greater; it's easier for developers to move between different software solutions that adopt the same standards and design patterns, as little (if any) training is required on bespoke elements of the solution. In short, a standards-driven solution is easier to understand, modify and maintain whether or not the original developers are available.
Furthermore, use of industry standards ensures it's easier to recruit new employees with the appropriate skills, and the cost of training new employees without the necessary skills is reduced.
Standards Enable Automation
There are a number of tools that support the developer: checkstyle that detects coding errors, format on save which applies the syntax standards, copy/paste detection, cyclomatic complexity metrics, etc. All of these tools rely on some analysis that determines the behaviour of the tool, and the standards provide the results of that analysis. The standards therefore not only support the creation of automated tools, but also through those tools support the development of tools which can increase developer productivity, highlight flaws and improve overall quality, and also ensure that the appropriate process and integral check-points or reviews are being undertaken.
Where the standards identify ways in which errors can be prevented, for example by highlighting ways in which code should not be written, those automated tools can then inform the developer at the point code is written or built, that errors exist and must be corrected prior to moving into further test and deployment phases. Likewise, the test driven development approach, included within the standard development processes ensures that system test suites are maintained and up to date; this in turn ensures that any maintenance on the software doesn't break existing functionality. Continuous integration tools can then be employed to automatically generate reports (perhaps simply with Red, Amber, Green status) that show the overall quality of the software solution.
Coding standards document the expected conventions that must be followed by developers writing in the Java language, and cover aspects such as:
filenames and file organisation
indentation and white-space
comments
declarations
statements
naming conventions
These standards are based on Sun's own Java standards, but have been augmented with additional guidelines specific to development with Org
Tooling Support
Format Code Formatting
Checkstyle PMD Find Bugs
Justification
According to Sun's website:
80% of the lifetime cost of a piece of software goes to maintenance.
Hardly any software is maintained for its whole life by the original author.
Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
In other words, the primary motivation is readability of the code. However, coding standards also provide some other benefits such as:
Pre-empting and preventing bugs; finding and fixing bugs during development is much cheaper than fixing issues during testing or after deployment. Some standards are introduced to make the introduction of certain bugs less likely.
Highly commented code is often laborious to follow; hence the age-old philosophy that the "code is the documentation, the code is king". Some of these standards ensure that code becomes self-documenting, reducing the need for spurious comments.
References
http://java.sun.com/docs/codeconv
Sun's Java Code Conventions.
http://pmd.sourceforge.net/
The PMD homepage which provides access to the tool's rule repository, offering descriptions for each of the rules' purpose, cause and acceptable coding solutions.
http://checkstyle.sourceforge.net/
The Checkstyle homepage which offers description for standard checks applicable to coding and design activities.
http://findbugs.sourceforge.net/bugDescriptions.html
The Findbugs' bug description page which provides the list of standard bug patterns.
Standards are not created for the sake of keeping people in roles, or for making up work for developers to undertake; they have specific cost and resource benefit when adopted and applied consistently on all software development projects.
The primary goal of the standards is to reduce the diversity in application design and implementation such that disparate teams may successfully work on the delivery of common global systems. The benefits of this approach are huge. By working together with a common approach, resources are able to move between projects, products and teams. At the same time this allows regional centres to leverage the abilities of staff at a global level, while ensuring the quality of that work and the developed artifacts; in short it ensures that the application is always maintainable, wherever it's constructed. Over time this ensures that training costs are reduced, code becomes reusable at a global level and resource management becomes more efficient.
The biggest benefit of using these standards comes from the fact they're based solely on methods and experience that has been proven to work. In other words, they bring together the design principles, practices and patterns, together with the coding standards and guidelines that come with experience. For all development staff, and in particular new developers, the R2 Development Practices and Standards should be the first-stop, one-stop resource on how HSBC applications should be built.
Below, we take the salient points from the above justification and explore each in more detail.
Standards Increase Efficiency
According to industry experts, software developers can spend up to forty percent of project time fixing issues that could have been resolved earlier, or could have been prevented if the right measures where in place (Software Defect Reduction Top 10 List, Software Management Magazine, January 2001). To put this another way: for every 5 days of project work, only around 3 of those days are actually delivering anything new; up to 2 days are spent correcting the work done within the previous 3 days. Does this sound familiar? Perhaps not on a week-by-week basis, but certainly over the lifetime of the project where the period of time spent in testing increases, the number of defects found and raised seems to be excessively large, etc.
Standards therefore aim to prevent problems early. That is by preventing erroneous code to be written, through the promotion of good practices which produce quality deliverables in overall smaller periods of time, and by providing any number of pre-determined solutions that can be "dropped-in" where specific software solutions are required. In some instances time is saved in the initial development, whereas in other instances the development time may increase marginally, however in all cases the amount of time spent in testing and defect resolution decreased thus leasing to an overall increase in productivity across the whole of the project.
Furthermore by promoting a component-based approach to software development which facilitates reuse (see below) it's possible to run projects where many of the software assets have already been created and simply need to be configured and reused in new solutions. Again, development effort is reduced and testing and defect resolution improved.
Standards Reduce Costs and Risk of Failure
According to Information Week, programmers inject around one error for every 10 lines of code they write (The State of Software, Information Week, 21 May 2001). Without any process to ensure that code is constructed correctly, there's a reliance on the developers to ensure that code is error-free. Even experienced developers may introduce flaws into the code base when rushing to meet project deadlines, often with perilous consequences later in the project life-cycle. We all know that the cost of fixing these errors depends on how soon they're found: if found during development, errors are can be up to 100 times cheaper than if found during the delivery or release phases (Software Defect Reduction Top 10 List, Software Management Magazine, January 2001).
It's critical therefore that all software development takes place in an environment that is hostile to errors and coding flaws. The practices and standards aim to provide that environment by attempting to detect poorly written code as soon as it's developed, when it's at the easiest and cheapest point to fix. Without preventative measures in place, without the quality control metrics and QA processes, project costs increase as the excessive number of flaws and defects found during later phases of the project life-cycle result in elements of the development phase being replayed.
Standards Reduce Complexity
For any given software problem, there are usually any number of different ways in which that problem can be solved. Some of those solutions will be fast and highly efficient, others will have a low memory footprint, others still may offer no tangible benefits. The more complex solutions generally speaking will have a higher probability of containing errors, although they may be the only possible way in which the QoS (Quality of Service) parameters may be achieved. The software design and coding standards therefore aim to reduce this complexity where it's not required, thus ensuring a corresponding reduction in the probability of errors being introduced; at the same time, complex solutions where necessary are presented as a set of "drop-in" patterns or solutions that have been previously tested and are known to be free from most common errors. This "drop-in" approach in turn ensures that the complexity of the overall solution being developed is hidden from the developer to a degree, thus allowing the developer to concentrate on ensuring that any code they write is error free.
Standards Highlight Costs
Adopting a standard process by which software projects are executed and by which the software itself is written, enables the creation of supporting standards in the cost analysis space. For example, common estimating calculators can be created which specify all known costs associated with the development process. These standard approaches to project cost assessment generally rely on the fact that the software development phase achieves a certain level of quality which ensures that subsequent test and deployment phases have low number of defects and flaws raised. Likewise period reviews that are integrated into the standard processes ensure that quality control and quality assessment are integral to the software development, ensuring that true costs are known and issues are not hidden. Also, by ensuring that problems are traceable to specific business requirements, it can be seen whether any of the software defects may result in additional business costs (for example, by having to refund customer fees, etc.) as soon as the defects are found.
Standards Facilitate Code Reuse
The development processes and standards promote the creation of component-based designed, with each component being clean and robust such that these modules may be reused in other software solutions. Code written to these standards is also easier to move between platforms and easier to keep up to date as the industry technology standards change. As always, bespoke standards and bespoke solutions to problems generally back developers into a corner when in comes to platform migration or upgrade, often resulting in full redevelopment of the system rather than a simple migration. Enforcing known standards on all code that is created ensures that the cost of undertaking migrations, the cost of extending existing functionality, and the cost of reusing solutions in other products is kept to a minimum.
Standards Enable Staffing Flexibility
Bespoke solutions require in-depth bespoke knowledge of that solution. Conversely, industry standard solutions only require knowledge of that industry standard, and some background information on the overall solution within which it's employed. As more and more software systems adopt the same set of standards, the ability for developers to work on the different systems that adopt those standards becomes greater; it's easier for developers to move between different software solutions that adopt the same standards and design patterns, as little (if any) training is required on bespoke elements of the solution. In short, a standards-driven solution is easier to understand, modify and maintain whether or not the original developers are available.
Furthermore, use of industry standards ensures it's easier to recruit new employees with the appropriate skills, and the cost of training new employees without the necessary skills is reduced.
Standards Enable Automation
There are a number of tools that support the developer: checkstyle that detects coding errors, format on save which applies the syntax standards, copy/paste detection, cyclomatic complexity metrics, etc. All of these tools rely on some analysis that determines the behaviour of the tool, and the standards provide the results of that analysis. The standards therefore not only support the creation of automated tools, but also through those tools support the development of tools which can increase developer productivity, highlight flaws and improve overall quality, and also ensure that the appropriate process and integral check-points or reviews are being undertaken.
Where the standards identify ways in which errors can be prevented, for example by highlighting ways in which code should not be written, those automated tools can then inform the developer at the point code is written or built, that errors exist and must be corrected prior to moving into further test and deployment phases. Likewise, the test driven development approach, included within the standard development processes ensures that system test suites are maintained and up to date; this in turn ensures that any maintenance on the software doesn't break existing functionality. Continuous integration tools can then be employed to automatically generate reports (perhaps simply with Red, Amber, Green status) that show the overall quality of the software solution.
Coding standards document the expected conventions that must be followed by developers writing in the Java language, and cover aspects such as:
filenames and file organisation
indentation and white-space
comments
declarations
statements
naming conventions
These standards are based on Sun's own Java standards, but have been augmented with additional guidelines specific to development with Org
Tooling Support
Format Code Formatting
Checkstyle PMD Find Bugs
Justification
According to Sun's website:
80% of the lifetime cost of a piece of software goes to maintenance.
Hardly any software is maintained for its whole life by the original author.
Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
In other words, the primary motivation is readability of the code. However, coding standards also provide some other benefits such as:
Pre-empting and preventing bugs; finding and fixing bugs during development is much cheaper than fixing issues during testing or after deployment. Some standards are introduced to make the introduction of certain bugs less likely.
Highly commented code is often laborious to follow; hence the age-old philosophy that the "code is the documentation, the code is king". Some of these standards ensure that code becomes self-documenting, reducing the need for spurious comments.
References
http://java.sun.com/docs/codeconv
Sun's Java Code Conventions.
http://pmd.sourceforge.net/
The PMD homepage which provides access to the tool's rule repository, offering descriptions for each of the rules' purpose, cause and acceptable coding solutions.
http://checkstyle.sourceforge.net/
The Checkstyle homepage which offers description for standard checks applicable to coding and design activities.
http://findbugs.sourceforge.net/bugDescriptions.html
The Findbugs' bug description page which provides the list of standard bug patterns.
扫一扫
860
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
