Chinaunix

标题: 【话题讨论】如何成为一名优秀的架构师?（积分已转账-2013-2-28） [打印本页]

作者: arron刘 时间: 2013-01-28 14:13
标题: 【话题讨论】如何成为一名优秀的架构师?（积分已转账-2013-2-28）
20积分已转账，请注意查收！

架构师是一个神秘而又神圣的名词，作为软件开发领域的设计师，架构师承载着太多的责任和挑战。对于一个程序员或者工程师来说，架构师就像是一个目标，一条道路，抑或是一座山峰。
俗话说不想当将军的士兵不是好厨师，那么如何才能够一个优秀的架构师呢？

讨论话题：

1、成为优秀的架构师应该注意哪些方面？

2、架构师的朋友可以分享一些自己的职业道路经验。

讨论时间：2013.1.28-2013.2.18

活动奖励：每位参加者都能获得适当的积分奖励。最低20分，最高不限,^_^想要赚分的朋友也可以来凑热闹哟。

作者: pitonas 时间: 2013-01-28 17:09
架构师是神圣的
架构师是神秘的
架构师

是一座山峰。

作者: Mylib 时间: 2013-01-28 17:11
这个。。。没经验分享，等高手发表。

作者: zhaopingzi 时间: 2013-01-28 18:14
不知道架构师为何物；

作者: Hongqiyaodao 时间: 2013-01-28 18:17
提示: 作者被禁止或删除内容自动屏蔽

作者: pmerofc 时间: 2013-01-28 19:27
提示: 作者被禁止或删除内容自动屏蔽

作者: duanjigang 时间: 2013-01-28 19:55
:wink::wink::wink:
知行合一，先学，而后思，然后总结。
俺总结这么几句。

作者: mz198424 时间: 2013-01-28 21:17
多多学习+修炼+实践。。。

作者: hellioncu 时间: 2013-01-28 21:44
有足够丰富的开发经验
技术要有深度+广度
抽象、归纳等思维能力

作者: hbsycw 时间: 2013-01-28 21:53
业务架构看需求，技术架构看成本。这里讨论的应该是技术架构吧。个人视角，架构师在软件开发中的角色应该是宏观技术管理，需要把握的是软件开发中的技术方向、软件结构和系统性能。再具体一点，架构师是能够根据需求提出最佳技术解决方案的人。要想成为优秀的架构师，当然首先要深入技术，重在技术积累--“理论学习+技术实践”；其次要能够跳出技术，对于一种技术的存在、目的和作用，要了然于心，才能在架构决策时进行合理取舍。

作者: gvim 时间: 2013-01-28 21:56
软件组件化发展到现在，软件架构师没那么牛逼了。传统软件领域，以前觉得牛逼的很多事情都被框架做了，比如注入和依赖反转，比如资源查询和管理，比如消息，比如事务，比如模块组件。现目前行业内牛逼的软件架构师不过是比其他人更熟悉业务，遇到过很多业务问题，吃过不少亏。是业务里最懂技术的，是技术里最懂业务的。
当然，能像martin fowler哪样在不同行业间寻求模式的，，，这片土地上几乎不存在。
我以为传统软件领域好的架构是迭代重构出来的，当你不断学习业务，重构几次业务代码之后，你就是这个业务领域内合格的狗驾驶了。

作者: webdna 时间: 2013-01-28 23:44
我看这帖能不能回复一万条

作者: 一介村夫 时间: 2013-01-29 07:27
1.嘴皮子要利索；
2.笔头子要花哨；
3.脸皮子要结实。

作者: duolanshizhe 时间: 2013-01-29 08:35
架构师就是军队的大将军，通过他的运筹帷幄，把技术体系构建好，然后结合业务流程，使用合理、高效、高性价比的方案来解决当前的问题！

作者: spider0808 时间: 2013-01-29 08:50
我是一个菜鸟，刚刚开始接触这些，但是我觉得一个顶尖高手，他的基础一定是非常牢固的，基础万岁！

作者: fengzhanhai 时间: 2013-01-29 09:00
本帖最后由 fengzhanhai 于 2013-01-29 09:02 编辑

斑竹对于架构师的定义混淆，笔者认为架构师可以分为两类一类是软件架构师；还有一类是系统架构师。对于一个非code企业，更多的是关注系统架构而非代码架构。还有软件架构和系统架构完全是两个不同的领域。如果让软件架构师去指导规划企业系统架构的完全是外行指导内行！这样未来会给公司带来不可估量的损失~ 我们现在也正经历这种混蛋过程~特指正错误。所以恳请版主更正一下你的议题。这样的讨论会误导很多人

作者: iamdsy1 时间: 2013-01-29 09:27
呃，我也凑个人头
我以为楼主说的架构师是各种大型网站的系统架构师，或者是需要处理海量数据的系统的架构师
其实对楼主的问题应该分为两步
1、如何成为一个架构师
2、如何成为一个优秀的架构师
对第一个问题，我认为架构师需要两点：
1、最主要的是要有知识的广度，比如各种SQL和NOSQL数据库的功能、缺陷，各种语言在应用开发中的优势，iptables和selinux加上各种数据库怎样才能正常工作，lvs、haproxy等各种软件负载均衡的处理能力和缺陷。
2、架构师对将要架构的系统的业务流程要比较熟悉，知道怎样和上述技术进行结合，或者知道什么样的业务用什么样的技术实现是比较好的，至少能列出一两条理由来。
对第二个问题，其实要求的还是两点
1、对前述的各种技术很精通，包括细节，最好是每一种技术都实地在生产环境中使用过，解决过问题。
2、对业务流程很熟悉
嗯，上述就是我自己的感受，但其实我不是架构师。

作者: dooros 时间: 2013-01-29 09:53

arron刘发表于 2013-01-28 14:13
架构师是一个神秘而又神圣的名词，作为软件开发领域的设计师，架构师承载着太多的责任和挑战。对于一个程序 ...

能否介绍下架构师这个职业？什么是架构师？架构师干些啥工作？需要什么技术才能？

作者: uxyzp 时间: 2013-01-29 12:05
那么如何才能够一个优秀的架构师呢？跳来跳去周围搞

作者: gnah 时间: 2013-01-29 12:08
我是来看看何谓架构师的..

作者: godymoon 时间: 2013-01-29 12:16
架构师要把一个业务从硬件 + OS + DB + 开发技术选型通吃么？
比如用什么类型的服务器，各项规格性能要完全熟悉，然后决定用什么类型的操作系统，什么类型的数据库，要不要高可用，要不要负载均衡，开发用什么语言，用什么框架……
一套搞下来，各个环节能给出靠谱的指导，是不是就是架构师了？

作者: 千年老狼 时间: 2013-01-29 12:53
@mz198424请注意楼主的头像

还有分数不少啊

作者: 瀚海书香 时间: 2013-01-29 13:19
回复 1# arron刘
没写好代码的架构师不是好司机

作者: andersonyan 时间: 2013-01-29 14:44
在行业有足够的从业经验，过硬的技术水平，是架构师的硬实力;
开放创新的心态，良好的技术与技术，技术与产品，部门与部门，上级与下级之间的沟通能力是架构师的软实力。
管理人的能力是架构师的一个很重要的方面。

我们公司之前就有一个项目，多部门协作，但是因为架构的人很急，脾气也不好，
不但和他手下的工程师在公司里骂起来(导致后者做完了DEMO就转岗)，
也各别的部门的领导斗气，动不动就说我的项目最重要，有吵和大领导吵去。结果别的部门消极合作。

最后这个项目也只是完成了，但是远达不到优秀

作者: nanqingzhe 时间: 2013-01-29 15:16
个人觉得，架构师不仅仅是实施研发层面的了，更多的是基于设计考虑，俗称的“搭架子”。设计一套框架，各个模块之间的关系，以及流程的兼顾。但是，在国内，感觉纯粹的架构师很少或者没有，基本上是没有见过。国内的都是做开发的出身，一步一步升上去后，做管理兼顾需求分析后，进行架构的设计。设计之初，充分考虑当前的应用需求，如果有之前的版本，还要留有兼容的空间。关键的难点在于以后，现阶段由于认识的局限性，或者开发没有开始，设计的过于理想，而在待实施的过程中，很多设计之初的思想都会或多会少的改变。

个人观点，不代表正确的思路

作者: xike2002 时间: 2013-01-29 17:45
回复 7# duanjigang

知行合一是明代大儒王守仁的心学的核心思想啊，支持架构师！

作者: fengyun530 时间: 2013-01-29 17:48
1、成为优秀的架构师应该注意哪些方面？
架构师这个职业并没有非常清晰的定义，甚至很多人都感觉陌生，我个人感觉：架构师首先必须独立做过软件开发的每个领域，不熟悉的话连各项工作怎么搭配组合都不清楚，更谈不上怎么去优化各个细节组合搭配了。架构师应该注意的是整体协调和布局。从项目拿到手，用什么开发工具，采用什么结构来设计会达到人力、时间、性能的3效率。

2、架构师的朋友可以分享一些自己的职业道路经验。
没有做过这个职业，没什么经验可分享的，不过我觉得架构师的好坏可以影响到整个项目的好坏和成败！

作者: fengyun530 时间: 2013-01-29 17:51
架构师，在目前好像并没有独立的职业，大部分由项目经历或者技术主管来负责，大家统一用什么工具，开发注意的细节等。都由他们来制定，但是确实很多时候，在细节部分耽误不少时间。原因就是没有一个好的架构师，开始的时候布局就没有把握好。导致开发人员做了很多返工和无用功。开发的代码可维护性不强，甚至一团乱麻！

作者: lkkkun 时间: 2013-01-29 20:44
我觉得成为一名优秀的架构师，需要的是一种对需求分析的整体把握，而且需要能够衡量技术是否能够重用。

作者: 流氓无产者 时间: 2013-01-30 09:13
很多感觉就是安排你当cto吧，又差点儿，安排别的吧，又怕你跑，所以给个title

作者: wsgod2000 时间: 2013-01-30 09:30

对这个行业很陌生，想多了解下这方面的知识！

作者: hsy75 时间: 2013-01-30 09:51
知其所以然
广泛涉猎
深度总结
基础扎实
实践丰富
各种公司做过

作者: lazy_bug 时间: 2013-01-30 09:56
架构师首先是一名优秀的程序员，然后其他方面的通才，最终融汇贯通，无招胜有招！

作者: wzg2643 时间: 2013-01-30 10:08
   个人觉得，架构师首先要知识全面，从编程思想，到数据库，从windows到linux，从软件上层到底层都要熟悉，就算不熟悉只要要了解，不一定会用，但至少要知道是干什么的，对过去以及当前主流模式等都要有所了解，不然在设计的时候可能用的不是最优的方案
   另外，架构师必要时还需要具有售前与项目经理的能力（国内环境所致）
   以上为个人想法

作者: ylky_2000 时间: 2013-01-30 10:21
信息化架构师：
个人理解如下：
1、懂软件开发的牛人，有丰富的项目管理经验，尤其熟悉主流开发技术、工具和系统框架；
2、深谙业务部门业务的流程和细节；
3、对数据库、网络有一定的了解；
4、沟通能力和协调能力的EQ达人；
5、如果是了解高可用、高并发更好；
6、对it版权和软硬件价格熟悉最好。

作者: g361031315 时间: 2013-01-30 11:12
时间的积累。。期间认真学习

作者: 疯狂小诗 时间: 2013-01-30 13:23
作为一个新员工，我只能说觉得我们的一个SE太厉害了。
写代码方面，他的想法是：代码是永远都要写的，而且确实，代码里面各种算法的设计和各个模块结构的设计，都很好。
业务方面，大家有不懂的东西也经常问他，在电信软件领域，不得不说，他对业务很精通。
也许这就是一个架构师至少应该具备的吧。

作者: ckf513728912 时间: 2013-01-30 15:11
要成为架构师一般情况要多少年的修炼

作者: 代号：军刀 时间: 2013-01-30 17:17
回复 2# pitonas

2楼我咋看你的文字隐隐中透露着猥琐

作者: 代号：军刀 时间: 2013-01-30 17:18
目前是系统运维，不知离我想到达的架构师之路还有多远，坐等架构师指点

作者: socol1 时间: 2013-01-30 17:54
加入一个大型的电商，做一个运维管理人员，利用手中能获得到的信息，对整个系统架构做一个完整而详细的理解！！！
当然，对业务流程也要做熟悉，这样对你的知识增长会有很大的提高，在实践中学习会更好

作者: wubo5152 时间: 2013-01-30 18:24
我不会说我进来是为了拿积分的

作者: java3344520 时间: 2013-01-30 20:25
软件开发领域的设计师这个是架构师的领域么?

架构师到底要懂哪些？框架？还是编程？还是数据库？估计这个面远远比软件开发要多的多吧，估计楼主是做编码的！

作者: xike2002 时间: 2013-01-31 11:46
做架构师的确挺难的，虽然每个公司都有自己的架构师，但是这群架构师好像和普通人有很大的不同之处，和普通的程序设计和开发者也很少有沟通，感觉他们就是一群整天在公司自己一个闷着头工作的人，几乎和外界是完全隔离的，这就是常说中的大牛啊。可能这就是所谓的古来圣贤皆寂寞吧！

作者: haitao 时间: 2013-01-31 15:40
架构师是负责系统运行的技术模式的选择、创建，行政、市场（项目经理、产品经理的事情）应该不用他分心了。
系统分析师更关键：承接用户，发掘需求，归纳总结，从千万条可能的功能路径里排除大部分，剩下的再征求用户的有效反馈，最后落实到一条功能路径，以便后续的编码实现。
项目经理、产品经理是负责整体项目，更多行政、市场等非技术因素、环节；
系统分析师、架构师则是侧重技术部分的总体把控，其中后者作用可能会少一点：类似的项目、系统，架构其实是可以复用、照搬的；
而需求则是不同客户都不尽相同的，除非是SAP这样的软件商，可以店大欺客。

作者: dooros 时间: 2013-01-31 22:55
看不到远方，就无法成为好的架构师。

作者: linux_c_py_php 时间: 2013-02-01 13:14
见的坑多了就成了架构师了, 都是吃亏吃出来的.

作者: wait空白 时间: 2013-02-01 16:42
何为架构师。

一个技术经理给我说的，一得广，什么hp，ibm，sun，oracle database，db2，emc ，hds，乱七八糟的都得接触，再者，怎么得到熟练的程度，精通不精通无所谓吧。

一定需要有全面的认识，我觉得，没个十年八年的，也不好整。

其实我对架构师的理解，就像对修房子的策划一样。怎么去合理的规划才是关键。

日积月累吧。

争取早日看见架构师的曙光。

作者: kofjk1000 时间: 2013-02-01 17:14

第一是对整个大需求业务的掌握第二就是所说的知识层面的，对各方面，包括开发，使用工具等，能够决定用什么开发，怎么开发第三就是看个人的想法了，估计这是经历过了才懂的。

作者: tkchks 时间: 2013-02-01 22:16
:wink: 架构师应该是从coder进化而来的

作者: 代号：军刀 时间: 2013-02-02 11:00
我们公司的架构师我只闻其名，没见过其人

作者: baimameidian 时间: 2013-02-02 14:12
个人以为没有大量的实战经验积累，就谈不上架构师。大家都想成为架构师，而只有那些把基础工作做好，在此过程中又能不断学习总结，并且能结合项目经验不断反思总结，这样的人才能最终成为所谓的架构师吧。

作者: 蛛蛛281306 时间: 2013-02-03 12:11
架构师要有丰富的实战经验才能确保不是纸上谈兵。

作者: ambious888 时间: 2013-02-03 22:36
架构师心中要有solution
和对行业的理解

作者: zw2002 时间: 2013-02-04 09:38
得有成长环境和良好的经历，挺难的。

作者: luobo5100 时间: 2013-02-04 11:05
正在努力的方向：短期目标成为架构师！

作者: Drewsun 时间: 2013-02-04 14:20

Hongqiyaodao 发表于 2013-01-28 18:17
以前计划成为架构师，可现在只能天天去换硬盘！

真实写照啊

作者: sumuu 时间: 2013-02-04 16:40
架构师其实最重要到感觉还是学习能力，当然架构师也是有等级。
一个人是不可能把所有技能等学完到，好多东西都是边用边学。

作者: azheng123 时间: 2013-02-04 17:00
我不是架构师，但是架构师是我的目标。我的计划是这样的，首先必须将计算机知识从计算机原理到编译原理到数据结构到系统内核实现到编程语言到算法实现这些基础知识搞清楚，这样才能在遇到问题的时候及时发现问题和解决问题。再之是积累项目经验，能够合理的规划项目，总而言之，要解决开发过程中的一些问题，为每一个项目的完美实现提供必须的支持。

作者: action08 时间: 2013-02-04 17:15
回复 14# duolanshizhe

大将军不是头衔高了，别人就愿意跟随听从的；；；
没有个那么多年的经验，就带队伍上战场流汗流血，是个手下都会感觉耸起来的；毕业生不谈

作者: action08 时间: 2013-02-04 17:18

lazy_bug 发表于 2013-01-30 09:56
架构师首先是一名优秀的程序员，然后其他方面的通才，最终融汇贯通，无招胜有招！

架构师首先是一名优秀的程序员，同意，

作者: action08 时间: 2013-02-04 17:20

蛛蛛281306 发表于 2013-02-03 12:11
架构师要有丰富的实战经验才能确保不是纸上谈兵。

很有道理，我想把你的话改一个字，架构师要有丰富的实战经验才能确保不是纸上用兵

作者: pitonas 时间: 2013-02-04 17:32
那么如何才能够一个优秀的架构师呢？

作者: a7pufap 时间: 2013-02-06 11:13
架构师: 可以在同时分析和解读任何网络或系统中任何代码的工序流程.

作者: txgc_wm 时间: 2013-02-06 11:23
回复 2# pitonas

楼主，你这是灌水啊！
你的这张头像是罗玉phone吗？

作者: txgc_wm 时间: 2013-02-06 11:26
架构师在整体的框架上有一个全面的认识，同时也能够觉察出它的优劣。
他也应该是一个优秀的程序员，解决过各种各样的问题。

作者: allone_2 时间: 2013-02-06 19:26
我是架构师吗？
架构师听起来有一丝神秘感，但是他是软件开发核心力之一。同时也是神圣的职业，代表着信仰。
长期php开发让我得到了不少经验积累，我初学PHP的时候没有任何框架经验更不知道框架是干什么的，我就基于对面向对象开发了第一套系统，由于php简单易用让我很快的解决了语法的障碍投入到了核心类库开发，一系列的问题都可以得到很快的解决。这才发现我具备了抽象画思维能力。这也对我升为架构师坚定了基础。慢慢的了解到了PHP的优劣尝试用学习其他语言但是没有过大的精力去尝试开发，让我学习到了语言各个方面的优势。
C/C++ 追求运行效率效率好多地方都和成本有联系的效率越高成本越低  java看好相反
java  追求标准化快速的构建复杂的业务体系。
PHP 当然是简单易用成本低不适合复杂业务复杂业务靠其他语言弥补它的不足
Python 这个有点给java相像他比java更跨平台。好多事情都可以做到，这点PHP不足的地方。

在开发第一套系统的时候我PHP当然首选是mysql数据库，我也是那种最求完美的人，传说php mysql经典组合，我查看了好多质料确实也验证了这一传说是真的，当然也有了解到其他数据库。
mysql 轻量级低成本
mssql 中量级成本稍高但是好像用正版的也不少，反之也是普遍。
Oracle 重量级成本一个字高的无法承受不是一般业务体系用到的，有钱的企业还是普遍的
PostgreSQL 不单是解决成本问题功能上也是很优越的媲美Oracle产品，也是我喜欢的。
nosql 技术不过于成熟都是在尝试一般企业用不到
看了这样多但是我还是选择了PHP mysql 因为业务体系并不是很大轻量级东西就配合适合他的配件。

公司里面都是用的windows系统，让我苦恼的事情就是有时候网络很慢操作起来不便，并且非正版还带来了很多麻烦事情，病毒就很折腾人。
windows 正版还是相对安全的成本还是存在的。
linux  性能上windows 没有什么可比性，但是不代表可以替代掉全部windows 并且成本低维护起来也很轻松。
FreeBSD 是我重点介绍的如果，如果业务追求电脑硬件不是特别新的完全可以用FreeBSD胜过linux，但是根据业务需要还是有关系的，它也是我的首选，重点是稳定.安全.高效。

web服务器选择起来也很麻烦的。
nginx linux发挥不错FreeBSD也一样。相同硬件条件下。他的轻巧为它高效率坚定了基础。挑战极限访问首选。
apache 比起nginx就相应重量级了，他安全上稳定性不可置疑的。如果保守的人一定选择它，我就是其中之一。
其他的不作为考虑的应用不同选择性就不同了。

由于接触PHP时间长了，但是对于我半年多已经算很长时间了。有人会问我半年多你是初学者，我要说每天接触12小时以上学习加写码呢，又有C语言根底，这个不可以争议各有个的说法。
第二套系统架构早已在我心中满下伏笔，经验已经让我在脑海里呈现第二套系统架构的模型。
知战胜者战必胜，别怪我啰嗦，架构师就要有这样的思维，超前的思维能力，清晰的思维逻辑，抽象画的思维空间。我个人认为这几点必须注意。

这时候有人觉得该有点置疑了，做一套PHP系统谈不上升级架构师，但是通过一套PHP系统延伸出来很多类似的PHP系统呢，这就要考验程序部分的架构够不够合理，当然我是开发者又是设计者，丰富的应用经验，让我设计的时候就开始抽象画，可能这个PHP系统就是传说中的PHP框架开发，但是我认为他是核心的经常接触OS 我认为核心的就叫内核。你也可以叫它为框架。更贴近一点称为规范化设计的标准类库。说了这样多我到底都不知道自己算不算是架构师。

自己在以前的公司因为就我一个程序员，开发设计运营都是我自己，并且兼职运维兼职数据库维护，反正是乱七八糟的技术我自己一个人来。梦想是架构师但是自己却一直不知道架构师需要什么标准。有时候觉得自己像有时候觉得还不合格。

作者: shdnzwy 时间: 2013-02-07 00:52
来学习一下，对架构不了解

作者: guchao30 时间: 2013-02-07 19:33
培养过程架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。总结构架师自我培养过程大致如下，仅供参考。
1、架构师胚胎(程序员)
学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信(通信协议)——学习搭建应用系统所必须的原材料。
2、架构师萌芽(高级程序员)
学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice(研究生可以研究网络计算机、高性能并发处理等内容)
3、架构师幼苗(设计师)
应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式(c++版本、java版本)、ejb设计模式、J2EE构架、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。
4、软件架构师的正式成型在于机遇、个人努力和天赋软件构架师其实是一种职位，但一个程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为一体的精英人才这可不是每个人都能够遇上的馅饼……
具备能力一般来讲，系统架构师应该拥有以下几方面的能力：
1：具备 8 年以上软件行业工作经验；
2：具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验；
3：具备 3 年以上的代码编写工作经验；
4：具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验；
5：对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握；
6：对 .Net/JAVA 技术及整个解决方案有深刻的理解及熟练的应用，并且精通WebService/J2EE 架构和设计模式，并在此基础上设计产品框架；
7：具有面向对象分析、设计、开发能力(OOA、OOD、OOP)，精通 UML 和 ROSE，熟练使用 Rational Rose、PowerDesigner 等工具进行设计开发；
8：精通大型数据库如 Oracle、Sql Server 等的开发；
9：对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础；
10：在应用系统开发平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例；
11：良好的团队意识和协作精神，有较强的内外沟通能力。
架构师的隐形职责1、为技术部门提供技术支持
2、在最需要的时刻去攻克最艰巨的技术壁垒
3、幕后项目经理
4、业务部门与技术部门间的粘合剂
5、业务发展的催化剂
（百度的灌个水）

作者: pitonas 时间: 2013-02-10 08:37
对于一个程序员或者工程师来说，架构师就像是一个厨师

作者: cker00 时间: 2013-02-11 19:39
出色的架构师应该具备很深的造诣吧

作者: hertcloud 时间: 2013-02-12 21:18

hbsycw 发表于 2013-01-28 21:53
业务架构看需求，技术架构看成本。这里讨论的应该是技术架构吧。个人视角，架构师在软件开发中的角色应该是 ...

赞一个！！！

作者: passthru 时间: 2013-02-16 15:35
本帖最后由 passthru 于 2013-02-17 11:26 编辑

不错的话题！

我的看法：

如何成为一名优秀的架构师?

首先，我们要明确，什么是应用系统架构？架构师在应用系统实现过程中又起到什么作用？

1）什么是应用系统架构？

请参考我blog中文，《应用系统架构》。

2）架构师在应用系统实现过程中又起到什么作用？
• 架构师的责任就是把业务架构的各个模块在一个单独硬件平台上，或一个整体，包括多个层次复杂的综合硬件系统平台上，把应用系统落实在最能体现硬件平台运行效率的地方。
•优秀的架构师，整体观要非常强，精通当今至少一条行业技术方向和主要技术，熟悉当今IT潮流硬件平台，和在此之下的潮流软件实施技术。
•架构师职责之一，就是把控应用系统项目实施规范。
•架构师的职责之一，就是会懂得用人，把各team leader放在最能发挥作用的地方。
•一个好的应用系统，不会因为业务扩充或变化，而影响应用系统运行和运行效率。功能唯一，包括功能代码唯一，是好的系统架构的保障，同时也是评价一个优秀架构师的标准。

《应用系统架构》
-- http://blog.chinaunix.net/uid-20328593-id-3490373.html：

做任何一个应用系统，比如银行核心、ERP核心、订票系统等等，应用系统都包括三个架构：1）业务架构；2）系统架构；3）实施架构。

1）业务架构
业务架构是应用系统的业务范围的具体划分和体现。业务架构与将要落地的系统平台无关。
业务架构的搭建，可以在概设阶段完成轮廓的搭建，对一些具体的细节，可以没有，或将会存在。但是，要在架构搭建过程中，把控着，或设计者，要留有充分的包容余地。
业务架构具体内容，要有粗细业务流的体现。每个业务流肯定要行得通。对综合或交叉的业务流要详细划分，按通用性，或者特殊性，划分为各自的子集。
业务架构要包括应用系统项目的当前实施范围，或将要实施的范围。
业务架构应该做到，业务范围内容的增加，不影响已经搭建好的业务架构，并且，比较容易地融合到业务架构中。
在业务架构搭建过程中，对熟悉的、惯例的业务用细业务流按模块划分，进行描述。对没有落地的业务内容，按粗业务流进行模块划分描述。划分好的业务功能模块，在业务架构中是唯一的，不能重叠。

2）系统架构
系统架构是业务架构落实到具体硬件平台的应用，硬件平台如HP-UX、RS6000、ES9000、AS400等等，操作系统如UNIX、AIX、390 Z系统、OS400、LINUX等等。
架构师的责任就是把业务架构的各个模块在一个单独硬件平台上，或一个整体，包括多个层次复杂的综合硬件系统平台上，把应用系统落实在最能体现硬件平台运行效率的地方。
业务架构是有范围的，在现有状况下，或将来一定时间段，实现的业务架构都会满足现有项目需求。
优秀的架构师，整体观要非常强，精通当今至少一条行业技术方向和主要技术，熟悉当今IT潮流硬件平台，和在此之下的潮流软件实施技术。
架构师不是万能的，但是，在架构师的统帅下，各分支的模块架构实现，要根据架构师规划和设计的系统架构轮廓进行实施，具体模块实现要team leader，根据模块特征，做具体技术设计和实现。
架构师职责之一，就是把控应用系统项目实施规范。
打个比方，IT架构师，就像建筑总体架构师，业务架构就像一个建筑架构，比如一个社区的建筑规划，哪里是居住区？哪里是电影院？哪里是超市？等等，这些都是在社区建设初期，架构师就要设计和规划出轮廓。对具体细节操作，比如社区中有一块区域要建筑一座楼房，第三层要实现中式复古装修；第四层要实现欧式宫廷式装修，等等，每一层都有各自熟悉精通这方面的team leader设计领导实施。
架构师的职责之一，就是会懂得用人，把各team leader放在最能发挥作用的地方。
一个好的应用系统，不会因为业务扩充或变化，而影响应用系统运行和运行效率。不提倡打补丁的做法。功能唯一，包括功能代码唯一，是好的系统架构的保障，同时也是评价一个优秀架构师的标准。

3）实施架构
实施架构是系统架构具体实现手段，是体系项目实施提升效率的具体实施行为。
在400平台下，RPGIV宏预编译、java技术引进交互式代码RPGIV代码开发、连调和分类管理具体技术，都属于实施架构的技术落实。

（先提出我的看法，具体补充还将会在我的blog文章中体现，passthru.cublog.cn）

作者: starggw 时间: 2013-02-16 23:04
真正的架构师，出来说明下架构师成长之路吧。
我认为架构师只是一个统称，有业务架构师，写代码的架构师，运维方面的架构师。

我个人对运维架构师比较感兴趣。

作者: TerryCheu 时间: 2013-02-16 23:41
周爱民的《做人，做事，做架构师》总结的很好！

成为一名优秀的架构师，得先把前两项做好。

做架构师终极目标还是做好系统，要实践是检验真理的唯一标准！学习能力沟通能力组织管理能力设计编程能力理论设计编程等广度及深度智商与情商的融合自我反省与安慰
亲和力以及丰富的领域业务经验及建模能力这些是必备的！

作者: moon_rock 时间: 2013-02-17 09:31
架构师应该拥有纵横交错的知识体系，通过多年理论、实践层层迭代，以达到对本质深刻的认识，融会贯通于即将实施的工程。
对技术执着追求，对细节掌控把握，能从宏观微观多角度切入去分析解决问题，例如：宏观，能从硬件内核角度去认识软件运行机制，减少中断上下文切换，进程上下文切换。微观，能从业务方面去分析问题域，建立相关的数据模型，分布式结构，分析优化数据缓冲模型、代码路径等。
一直在前进，不固步自封，精益求精，勇于推翻自己的设计。

作者: zhaopingzi 时间: 2013-02-18 10:59
架构师看上去很美

作者: jackli2011 时间: 2013-02-18 11:08
广度
深度
持久度

水平拓展
横向拓展
发散思维

作者: 525478495 时间: 2013-02-18 14:46
神马是架构师，看高手解答

作者: jawn_lee 时间: 2013-02-18 15:41
了解到很多知识，谢谢！

作者: seesea2517 时间: 2013-02-20 15:01
学习一下。目前还没有这个理想就是。。。

作者: starggw 时间: 2013-02-20 21:59
好东西收藏了。。。。啊

作者: y君临城下 时间: 2013-02-23 00:21
回复 5# Hongqiyaodao

哈哈

作者: frogoscar 时间: 2013-02-25 22:42
http://tech.it168.com/focus/200812/jiagoushi/index.html

1.人远比技术重要

你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时候将主要精力都集中在技术上。显然，构件（components），EJB（EnterpriseJavaBeans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。从微软操作系统和OFFICE套件在市场上的成功可以得到对这个问题的最佳解释。

2.理解你要实现的东西

好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。有效的系统分析和架构是减少后期错误或复杂实现的必要保证。

3.谦虚是必须的品格

你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。目空一切、自满自足的人是不可能成为一个优秀的软件架构师的。

4.需求就是需求

如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。我们进行的很多需求分析，实际上是想当然的认为用户的需求和自己认为的应该是一样的。

5.需求其实很少改变，改变的是你对需求的理解

需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力。

如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。

你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你的工作。

需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。

6.经常阅读

在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。

每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。这一条在我周围能够真正实现的人很少。

7.降低软件模块间的耦合度

高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库。

耦合度低的软件可以很容易被重用、维护和扩充。

8.提高软件的内聚性

如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

9.考虑软件的移植性

移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传。

即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。

当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。

好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你仅仅需要更新那个包就可以了。这些说到容易做到很难，没有扎实的基本功是很难成功的。

10.接受变化

这是一句老话了：唯一不变的只有变化。

通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。

11.不要低估对软件规模的需求

Internet带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。

今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。

在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。

在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。同时也不能只因为考虑未知的用户量而花费太大的成本。需求分析是平衡控制的依据。

12.性能仅仅是很多设计因素之一

关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。花哨的、运行快速但是不能解决用户问题的系统，是不会得到用户的满意的。

13.管理接口

应该在开发阶段的早期就定义软件模块之间的接口。这有助于开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后模块怎样实现就不是很重要了。

从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

14.走近路需要更长的时间

在软件开发中没有捷径可以走。

缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。

在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。

你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。

避免走捷径，只做一次但要做对。

15.证明你的设计在实践中可行

在设计的时候应当先建立一个技术原型，或者称为“端到端”原型。以证明你的设计是能够工作的。

你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。

16.应用已知的模式

目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。

一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。

17.研究每个模型的长处和弱点

目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。

18.在现有任务中应用多个模型

当你收集需求的时候，考虑使用样例模型，用户界面模型和领域级的类模型。

当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。

程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。

19.带工具的傻瓜还是傻瓜

使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。现在的编程工具越来越容易上手，有不少的人已经不去加强对基础知识的学习，这是很危险的。

20.理解完整的过程

好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。

软件开发是一个很复杂的过程，除了编程、建模、测试等你擅长工作外，还有很多工作要做。好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。

21.常做测试，早做测试

如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。建立一个技术原型供技术评审使用，以检验你的软件模型。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。测试工作一贯是得不到重视的，即便你天天挂在嘴上，但是请看看你的行动。黑盒测试将压力给了测试人员，实际上很多的无用测试的根源应该从白盒测试中查找，这是软件开发人员的问题。

22.把你的工作归档

不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。给每个模型一些概要描述以使别人很快明白模型所表达的内容。

23.技术会变，基本原理不会

如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。

软件建模技术是需要多年的实际工作才能完全掌握的。好在我们可以从以上的建议开始，完善自己的软件开发经验。

要想成为优秀的软件架构师或软件开发人员，必须要有一个端正的态度，如果只是想依靠这个所谓的名份做幌子、混日子。我劝你还是不要踏入这个行业，以免误人误己。

作者: lsyang100 时间: 2013-02-26 11:15
架构师就是武功练到一定成度，可以开宗立派的宗师了！

作者: dzc2009 时间: 2013-02-26 14:47
在我的影响里，貌似是做运维做到了巅峰后再做的事:wink:

作者: qinyiwang 时间: 2013-02-26 15:21
架构师这么高端的。。。感觉起码要有coding几年，再慢慢成长为架构师的

作者: askbai 时间: 2013-03-05 18:29
说的不错哦，应该就是这些吧

frogoscar 发表于 2013-02-25 22:42
http://tech.it168.com/focus/200812/jiagoushi/index.html

1.人远比技术重要

作者: 民工甲V 时间: 2013-06-03 14:05
回复 14# duolanshizhe

http://www.itpub.net/thread-1746514-1-1.html

能麻烦你帮我看看这个问题吗?

作者: wzjwqs 时间: 2013-12-19 13:22
回复 75# passthru

赞同,知道有什么,该干什么,怎么干.

比知道"架构师"更重要.

作者: passthru 时间: 2013-12-20 13:15
本帖最后由 passthru 于 2013-12-20 13:31 编辑

wzjwqs 发表于 2013-12-19 13:22
回复 75# passthru

赞同,知道有什么,该干什么,怎么干.

1）在一个应用系统下，把N条业务处理流，归纳和设计为功能点唯一，就是业务架构；
2）根据实施项目的应用系统的特点，把设计的业务架构转设计为应用系统系统架构；
3）对一个特定的硬件平台每一个或每一类的功能模块，提供编程规范、数据字典规范、命名规范、数据结构命名和使用规范、接口规范、必要时提供效率开发平台、编程模板等，并从架构师对各种计算机语言的认识，对具体的模块，规定实施模块对应的语言要求；
4）架构师提供上述的架构体系应后，对应用系统总体系能测试负责，对没有达到客户提出的性能指标项，在上述架构下，提供改进方法，包括上面三点提到的内容的实施方法，并对各自平台硬件系统，汇集相应的系统专家，提供相应的提升应用系统性能的方案和技术。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)