软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色。
例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。对于程序员来说更关注模块是否清晰，类的功能是否单一等等，对于测试人员来说，关注的是系统的可测试性。对于维护人员来讲，系统的扩展性、可维护性如何？
一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。因此我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：
◆ 功能性
◆ 效率
产品运行的时间效率和利用的硬件资源两方面。
◆ 维护性
包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。
◆ 可移植性
包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、可复用性都是应该考虑的因素。
◆ 可靠性
包括无缺陷性、容错性、可用性。
◆ 使用性
包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此软件的可用性也是非常重要的。
完成了设计之后，接下来就要进行编码了。在编码阶段，应该怎样保证我们的编码质量呢？两个比较有效的方法就是代码走查和单元测试。
代码走查可以以组为单位进行，代码走查可以发现代码是否符合代码规范，是否存在拼写错误，是否具有可读性，类和方法是否过于冗长，类之间是否存在高耦合性。
代码质量的一个很重要的标准就是代码的可读性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。
如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就最容易出现缺陷和错误。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，或者该类的public方法太多都会导致类之间的高耦合性增加。
编码阶段另一个非常重要的手段就是单元测试。单元测试是一个模块的功能及常规错误测试，单元测试是由程序员进行的，一般单元测试能够捕获80% 的bug。因此单元测试对保证代码质量方面占有很重要的地位，由于这方面内容比较多，我们这里就不做具体阐述了。
好了，经过了这样一次质量旅行，我们对软件开发是否增加了很多信心呢？当然软件项目管理还有很多其他的因素，但是如果每个阶段都能够很好的控制质量，就会在产品开发初期减少很多风险，从而使我们的软件开发在一个可以控制的范围内进行，这样我们才能够避免过多的没有必要的人力物力的浪费，从而使我们的产品更快更好的投入市场。
文章来源于领测软件测试网 https://www.ltesting.net/
