[讨论]软件架构类书籍推荐

Patterns of Enterprise Application Architecture这本书似乎还可以，因为我只是草草的看了一下。不过我觉得现在很难有什么真正有深度的书，毕竟这个东西出现太晚了，而且国际上对于architecture的定义都不是很统一。虽然IEEE有了一个所谓的标准，但是你们看看RUP，就会明白这么注明的公司的定义都是把architecture和framework混淆的嫌疑。所以这个事情还是自己想办法吧。
不过我在随后的介绍RUP的文章中会涉及这个方面的事情，希望大家到时候多替意见。

做架构是如此之难，又是如此之容易。呵呵~~~
架构的设计者是否应该看重开发人员本身的体验呢？我觉得架构就象一栋的大楼的条条框框一样，拥有这样和那样的规则，如果这些规则没有能给开发人员带来发自内心的愉悦之感，那么开发人员作为这栋大楼的装修者也没有办法将大楼弄得更漂亮。

作为第一线的开发人员，看到architecture,framework就有一种被愚弄的感觉。
或许我还是微软的追随者，我觉得微软的做的软件都很看重开发者的体验，这一点，Java这边还是要学习啊。
还记得《Java深度历险》一书中讲到的java领域重架构，重设计模式，而微软的追随者则重底层实现，重技术本身。说实在的，后者更让人觉得踏实。

MS的技术实现从来都是一种粗糙的，从MFC到COM，现在的dotNET算是有些长进，不过这样的进步似乎只是个人的胜利，而不是MS的进步。
而说到MS的追随者注重的所谓底层，根本就是小儿科的把戏。从dos的未公开的int，到win下的秘密api，到现在的所谓绕过net直接去操作硬件，无不是一些垃圾未清楚干净，而留下的后遗症。这些东西本身就是不稳定和不兼容的另外一种说法，除非是非常个别的应用，根本就不值得去研究。记得当初我一个朋友写vxd，因为其无版权，所以根本就没有去ms申请id。结果在使用一段时间后出现了非常奇怪的不定时错误，而谁也搞不清到底是怎么回事。好在他们的产品已经没有什么市场，所以维护和升级工作就不是那么必须，才逃过一场灾难。
其实我觉得如果JAVA不能做到更加公开，早晚随着系统的复杂性和规范的交差性的增加，类似情况一样可能出现。好在是IBM也参与到JAVA的规范工作，而同时一大批开源社区的人也不断对这些规范作出自己的建议。
我从来就反对大家研究底层和细节，这些东西经常改变，针对他们去编程根本就不是一个经济的做法。而框架和架构则可以在某种程度上超脱于具体的实现平台之上，可以给人一种总体把握的能力。就好像下围棋，框架可以算是中国流这样的布局，而定式可以算做架构的基本粒子，而那些具体的细节则只是特殊情况下出现的一些不稳定场景。

to o6z：
呵呵，建造框架是需要非常深厚的基础知识（数据结构、算法、数据库实现、编译原理、操作系统、OOP、设计模式）的，不具备一些低层的知识纯粹采用 OOAD 是很难把框架做好的。我们的框架包含几十万行代码，虽然我只开发了其中的一部分，但是多少还有点发言权。

我们的思路正好与您相反。正是因为要做框架的开发，所以更应该搞清楚一些底层的细节，例如不同算法间的性能差别。

我为什么经常强调基础知识的重要性，就是因为如果基础不好，很容易做墙头草，随风倒（今天 J2EE、明天 WebService、后天 .Net），不会有自己的判断能力。而且正是因为基础差所以才限制了很多人的想象力，让他们只知道等、靠、要，从来不肯思考如何自己去解决复杂的问题。

还是就事论事吧，不要认为 M$ 一切都做得不好。其实在表示层，M$ 还是有值得 Java 程序员借鉴的地方。

嘿嘿，ms的那些所谓的底层，我想你们研究的不多，所以才会认为那些是技术。那些细节根本就是不被ms承认的，而大家还乐此不疲的去研究。
MS的优势在于其把编程的门槛放到的足够的低，而且关心程序员的需要。而其框架和结构设计还是一个问题。

框架<>构架，这一点需要注意，请参阅RUP的《软件构架文档》

我明白你说的 M$ 的底层了，就是那些 undocumented 的东西。这些东西是坚决不能用的，就算会用也算不了什么高手。
我以前有个做楼宇监控的朋友最早是用 VC++ 和 MFC 的。他说用 MFC 实现一些功能总是很复杂，要捕捉几个事件才能做到，后来他们找到了一些 undocumented 的事件，用了以后只需要捕捉一个事件就可以了。程序性能也有了提高。后来他用了 Delphi 和 VCL，就再也不愿意用 VC++ 了。

其实很多人都怀疑 M$ 自己的软件肯定不是用这套东西（VC++ & MFC）开发的，所以故意把这套东西搞得很难用。M$ 这种事情不是没有做过而是做得太多。软件专家早已经在名著《Undocumented Windows API》中检举揭发过了。美国司法部的呈堂证供里也写得很清楚。M$ 的罪状以前我列举过很多，现在不想再浪费口舌了。

BTW，唐骏跑到盛大去了，M$ 中国这次又要大地震了。

嘿嘿，记得当初《未公开－－》系列是最热的，但是也是最害人的，病毒高手无不是从此入门。实际上我觉得走这些旁门左道，虽然暂时很有效，但是长期来说绝对是害人不浅。而去研究MS真的难于分清除什么是旁门，什么是正道。
muziq
请仔细研究RUP的architecture文档和对于framework的说明，就会明白他们自己也不能说清除很多事情。这就好像，jacobson自己也不能很好的告诉别人怎么去寻找usecase，最后还是cockburn用一个目标来解决了这个难题。

一个项目是否成败的一个极其关键的表现因素就是《软件构架文档》的质量，换句话说，除了项目经理的能力以外，架构师对项目的影响也是决定性的。为什么架构不等同于框架，最简单的例子就是你的系统可能会用到多个框架（在不同层面上），但即使是这些框架集合在一起也不能算是构架。从RUP的文档模板就可以看出，构架就是目标系统的总览（或者说高层视图），《软件构架文档》的大部分内容是可以从Rose里面导出来的，因为Rose模型已经概括了需求、设计、部署等方面的问题。
构架师的重要的工作就是为其它开发人员提供基础的框架、调试环境、目录结构。构架师除了确定技术路线、选择框架产品以外，还要创建基本的目录结构，不要小看这一点，这不是一般的程序员能够做的好的。
还有，就是架构师要做设计的先锋，在其它设计人员开始设计之前，拿一个或几个典型的用例，进行完整的设计，设计人员以此作为范例（除了像文档、模型这样的成果以外，还包括设计的过程、方法）。架构师甚至可以写出代码的范本以供设计、实现人员参考。
上面的这些工作成果都是可以写到《软件构架文档》里面的，这些内容组成了一个项目的最最重要的文档。

见识不广，请各位批评！