用微软.NET架构企业解决方案 学习笔记（三）设计原则

　　原版书名《Architecting Microsoft .NET Solutions for the Enterprise》

　　前言

　　设计软件系统是非常有挑战性的，因为一方面需要你集中在今天的需求，同时要求可以适应未来对功能的修改和增加。

　　尤其是在过去的二十年，在IT行业中，使得软件开发过程系统化，已经做了很多的工作。方法论，设计原则，设计模式，都是用来帮助指导架构和构建系统，以一种规范的方式构建复杂的系统。

　　本章的目标是给你提供一个软件工程的速成教程。首先是一些设计原则，激发现代软件系统的设计。然后，我们讨论面向对象设计的原则。在整个过程中，还会介绍设计模式、语言特点、面向方面、需求驱动的设计，和影响设计的关键因素，例如：可测试性、安全性、运行性能、

　　基本设计原则

　　编写可以运行的代码是一回事，编写可以运行的好代码又是另外一回事。接受一种特性“编写可以工作的好代码”，从更广的视野看系统的能力。最后，最好的系统不仅仅是一个实现功能的产品。更多的是相关的、直接的、间接的设计。

　　“编写可以运行的好代码”这种这种特性可以指导你，例如：用一些标准来评估代码的可维护性，例如International Organization for Standardization（ISO）和nternational Electrotechnical Commission（IEC）。你引入这些标准是因为可维护性要比扩展性和伸缩性重要，因为维护的代价很高，更容易使开发者沮丧和有挫折感。

　　代码应该很容易查找bug，修复bug是毫无疑问的，应该排在扩展性和伸缩性前面。因此，在设计系统的时候，对于维护性设计应该给与最高的优先级。

　　为什么软件维护的代价这么高呢？

　　从根本上来讲，如果你生产了不满足要求的软件，没有进行足够的测试，或者是两者都存在的话，这时候维护代价会很高。什么样的特殊可以使软件容易维护和进化呢？从一开始就进行进行结构化的设计，是达到正确编程技术的最实用办法。代码的可读性是另外一个基础点，如果代码既有内部文档，又有对于变化的跟踪系统，是最好的。但是，这好像只存在于完美的世界。

　　不满足要求的软件通常是由于设计较差。但是，是什么导致设计较差呢？

　　通常有两个原因会导致出现差的设计：

• 　　架构师技术不足
• 　　需求的不精确，或者是需求之间的相互矛盾性

　　那么需求的问题是什么呢？矛盾的需求通常产生自沟通问题。沟通时王道，对于架构师的培养和提高来说，沟通是最重要的技术之一。

　　没有疑问，解决沟通问题驱使我们引入敏捷方法论。有多少人对于敏捷运动有错误的认识，它带来的最大好处不是理论本身，而是持续的沟通提升了团队内部、团队和客户之间的效率。无论你在第一次反复的过程中得到多么错误的认识，都会在下一次的反复过程中修正它，因为沟通对于进步来说是必要的，澄清对于需求的错误理解，修复错误的理解。这种反复的方法减少了产生导致软件维护代价高的可能性—差的沟通。这也是有一天，一组开发者和架构师决定建立敏捷运动的主要原因。实用主义是有积极性的，幻想主义的是没有积极性的。

　　这么说的意思是让你记住，敏捷方法论的趋向是增加开发代价的。你必须让参与的每个人都清楚这些。如果参与者不理解他们自己的角色，或者是不赞同这么做，或者是在反复的过程中不能重新检查、检讨工作，敏捷就失败了。因此，底线就是敏捷不是每个人用来工作的魔术棒。但是当它工作的时候，通常会工作的不错。

　　

　　未完待续。。。。。。。。。。。。。。。。。。。。。。