评价设计好坏标准的重要性

软件设计于软件开发人员就像文章大纲于作家的关系。一个好的设计，是整个项目顺利完成的保障。追求好的设计，也是每一个软件开发人员的追求。为了学习到好的设计，我们发明（发现）了设计模式，将优秀的设计提炼了出来，后来人照猫画虎就可以了。但在实践中，还是有很多时候迷茫，也有一些东施效颦，不知道如何灵活应用，不知道如何取舍。
为什么会这样？本质上是我们对于如何评价一个设计的好坏还没有建立具体的标准。假如，我们评价哪一种握筷子方式更好，而标准就是是否能够夹起来嫩豆腐，那么直接对比一个握法是否能够夹起来豆腐就好了，如果没有标准，那么就会各有各的道理，也许还有人说这种握法是某名人发明的，所以才是更好的，出现很多无意义的争论。只有确定了评价标准，才能进行更量化的设计优劣比较。

软件设计好坏的几个评价标准

1. 是否能够完成预期的功能；
2. 是否能够应对潜在的变更；
3. 是否有很好的可读、可维护性；
4. 是否具有很好的可测试性；
5. 是否具有良好的可移植性；
6. 异常发生后，是否具有良好的追踪、调试性；
7. 是否在问题领域有非常好的抽象性，具备可复用性；

是否能够完成预期的功能

如果一个设计不能做到需求描述的功能或非功能要求，那么要它何用？在实践种，就需要对项目的需求进行确认，如果需求还没有完全确认，那么这个标准也就没了意义。

是否能够应对潜在的变更

变更是软件开发种一定会出现的事情，变更只能通过管理、工具等手段减少，但不会被消灭。所以，设计在一定程度上就要对可能的变更进行预防。为了对变更进行预防，可以将变更分类，有些是很严重的功能变更，有些是视图变更，有些是操作变更，不同的变更可以进行不同的预防设计。

是否有很好的可读、可维护性

设计最终需要被实现，被维护。可读、可维护对于一个长期项目来说是非常重要的一个属性。对于一个一次性的定制项目，也应该尽量保证可读、可维护性，因为实践证明很多一次性的定制项目往往还有后续升级修改要求。

是否具有很好的可测试性

对于软件产品，确保产品的正确性、稳定性是非常重要的，尤其是对于一些安全关键的软件。测试从一定程序上是开发设计的一部分，只有在设计种考虑了最终产品的可测性，才能在设计种对这种可测性进行设计体现。

是否具有良好的可移植性

这个在有些项目中是一个非常重要的标准项，但有些项目对可移植性没有太多要求，但可移植性无论如何都可以作为设计好坏评价的标准之一。

异常发生后，是否具有良好的追踪、调试性

软件产品一定有BUG存在。当产品发布后，可能偶然发生了一个BUG，这个设计是否能够提供一些BUG解决的辅助方式、数据。

是否在问题领域有非常好的抽象性，具备可复用性

一个软件产品，往往涉及很多模块，真正与本项目最为关系密切的算法，也许只有几千行，其余都是围绕该算法来提供支撑，包括文件读写、视图交互、图形展示等等。将不同模块，甚至整个应用进行抽象，脱离了具体领域，就能被更多项目使用。完成同样功能的设计，产生更好可复用模块的设计往往可维护性也会更好。