Best Practices for improving Software Quality [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

开发者_开发技巧 Improve this question

We are looking for methods to improve our internal processes when developing software.

We have already adopted TDD contiguous integration and Agile. Any obscure features of visual studio or TFS?

All suggestions welcome.

---

I don't think there can be a magic bullet. Beauty (or in this case quality) is in the eye of the beholder.

With that said, I can give you some suggestions as to some of the ways we ensure code quality.

One suggestion can be to include Code Coverage into your assessment of Software Quality. It is one thing to have unittests written for your code, but code coverage helps you identify what code is actually 'covered' by a test, which can sometimes identify use-cases/scenarios that you may not have considered. I recommend you investigate nCover.

You may also wish to dig deeper and look into using nDepend...

NDepend is a tool that simplifies managing a complex .NET code base. Architects and developers can analyze code structure, specify design rules, plan massive refactoring, do effective code reviews and master evolution by comparing different versions of the code.

I appreciate that these are not TFS features but you can easily 'integrate' them into your visual studio environment using TestDriven.NET

This is of course not an exhaustive list of things - you need to find what suits you and gives you the confidence about your code's quality.

Hope this helps,

---

Here's a helpful list: http://www.joelonsoftware.com/articles/fog0000000043.html ("The Joel Test: 12 Steps to Better Code" by Joel Spolsky)

---

If you really don't have anything to do, and you have the resources you can try code review. This procedure includes double checking the code before every (real) commit. This helps to catch bugs early in the development process. Google is using this technique widely.

Sadly the tools supporting these kind of procedures are pretty basic and hard to use currently. If you do a googling on you'll find one or two simple code review tool for TFS.

Be careful though. These techniques doesn't help you make good software alone. You still need a good architecture, quality code, etc. (Okay, TDD helps code quality, but architecture is still a gray area.) I'm not aware of any techniques that help that currently and doesn't hurt the development process too much. You have to wait till Visual Studio 2010 comes out with all the bling-bling of model validation, automatic uml diagram generation, etc.

---

Personally I believe in code reviews. Some of advantages are:

• Constantly keeping an eye on code quality and coding standards.
• It's easy to notice any unusual/buggy/hard to understand coding structures (i.e. long if conditions, strange type conversions, etc.).
• While reading someone else code it's easier to notice all false assumptions (could be negative false) (i.e. this object is never null), which could introduce bugs.
• It makes familiar with all changes to source code, so it's easy to remember that this piece of code was lastly modified (which could introduce bugs).
• It makes easy to learn (and teach) good habits.

And I do not believe in any tools, which are thread as special kind of silver bullet -- which is not true.

---

read: Code Complete

---

It is good that you have implemented TDD, CI and Agile. Just having ANY process is far better than many places I have seen. Code reviews are probably the single best way to disseminate knowledge and flesh out defects early.

For my money, though, stick to the basics. If you are not doing requirements management, you should consider it. You should know what your customer requirements are when you start your sprint or development cycle. Conduct a review of those and discover your derived requirements, if any. Lastly, you should come up with a way to verify that 1) you built everything you intended 2) you tested everything the customer asked for. There are processes to do this but if you can find a way that's good for you, do it!

RM takes less time than code reviews and catches the "really big" mistakes.

---

You are probably the most happiest guys if you have already adopted TDD, CI and Agile and have nothing to do =) I think you have a very big field of process improvement with TDD and Agile practices.