At the development team level every team needs to have a definition of DONE which everyone needs to abide by. When someone says a task is "done" before checking in code the following points should be met for it to be really done:
10 Commandments of DONE:
1. Though shalt follow use cases, user stories or other requirement document
2. Though shalt use follow editorial document for any content ( content is the king)
3. Though shalt follow design
4. Though shalt comment your code
5. Though shalt follow naming conventions and coding guidelines
6. Though shalt unit test
7. Though shalt get your code reviewed
8. Though shalt properly test your code’s functionality. Though shalt really not wait for only QA’s to test for you
9. Though shalt consider performance and security while coding
10. Though shalt attach your code to proper work item and add comments while checking in
Detail:
1. The code is providing functionality as documented in requirement documents like use cases, change requests, user stories etc.
2. If there is any content/text to be displayed it need to be properly added especially if your site is multilingual make sure you add all resource keys.
3. The code is following the approved design for the module/project.
4. The code is properly commented if required. Some methods, classes are self-explanatory. Commenting just for the sake of it is not required.
5. The naming conventions and coding guidelines are followed.
6. A minimum accepted level of unit/integration testing is there.
7. Code is reviewed by another member in your team. This also lets people explore each other's code and can provide support if required (a member leaving the team, absence etc.) It’s also a great learning process.
8. Do at least some basic testing. It is not just QA's job to properly test functionality. Developers should test their code with all possible scenarios etc. before checking in. Also if the code touches or modifies existing functionality a minimum regression testing should be done. This would avoid lot of back and forth between development and QA team and save us lot of time.
9. Performance and security is not something to be pushed at the end and should be considered during development and code review.
10. While checking in attach it to the proper work item and add comments while checking in.
Subscribe to:
Post Comments (Atom)
2 comments:
Good stuff here.
Though, I tend not to agree with the fact that the code must be commented. I rather think that when we feel the need to comment a piece of code, it means that it must be refactored because, usually, a comment is intended to clafify a confusion in the code... removing javascript:void(0)the confusion is better than explaining it.
There are certain exceptions (rare) where we may add some comments. For instance, when we develop an API or a library. In this case, we can comment entry points for the sake of external users (customers who will use this library or API).
Good stuff here.
Though, I tend not to agree with the fact that the code must be commented. I rather think that when we feel the need to comment a piece of code, it means that it must be refactored because, usually, a comment is intended to clafify a confusion in the code... removing javascript:void(0)the confusion is better than explaining it.
There are certain exceptions (rare) where we may add some comments. For instance, when we develop an API or a library. In this case, we can comment entry points for the sake of external users (customers who will use this library or API).
Post a Comment