怎样才能成为一个优秀的架构师
俺是一个刚接触程序不就的菜鸟,想往架构设计方面发展, 希望大家给提些宝贵的意见,让小弟少走些弯路,先谢谢了^_^
能散的分有限,但我会连续发这个帖子,先奉上100分再说,来者有份,但还是希望能给小弟指点两句.
注:明天下班前结贴.
------解决方案--------------------------------------------------------
能够很早的为自己定位，这很好。
------解决方案--------------------------------------------------------
相信每个CODER开始都有这个梦想，可坚持的少，迷失的多。
也迫切希望能有人指点，让各位观者多少有点受益，关于架构我知之甚少，就先顶起了，常关注！
------解决方案--------------------------------------------------------
首先要清晰架构的目的是什么？给谁服务的？
然后再搜集整理需要的服务内容。
程序的目的是满足需要，架构是提供更好的满足需要的有效手段。
行业不同、客户群不同，需要也不同。就像设计模式总是喜欢用pos机图书馆这样的模型来讲解，看起来很好，但实用起来总是有距离。
------解决方案--------------------------------------------------------
1. 人远比技术重要
你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。
2. 理解你要实现的东西
好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。
3. 谦虚是必须的品格
你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。
4. 需求就是需求
如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。
5. 需求其实很少改变，改变的是你对需求的理解
Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。
如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。
你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。
你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。
如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。
你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。
你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？
需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。
6. 经常阅读
在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。
每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。
7. 降低软件模块间的耦合度
高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。
你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。
耦合度低的软件可以很容易被重用、维护和扩充。
8. 提高软件的内聚性
如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。
判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。
只有高内聚性的模块才可能被重用。
9. 考虑软件的移植性
移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many ? 译者注）。
即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。
记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。
好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。
10. 接受变化
这是一句老话了：唯一不变的只有变化。
你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999）
通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。
11. 不要低估对软件规模的需求
Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。
今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。
在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。
在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。
12. 性能仅仅是很多设计因素之一
关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。
但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。