|
锁定老帖子 主题：架构师核心技能养成计划
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-02-19
江南白衣 写道 我觉得如果一个系统，并不只由一个单体的程序组成(即使是这个单体程序可能分布成一个负载均衡的群集)，而是由几个程序运行在不同的服务器上共同组成的时候(比如仅一个接入系统就需要radius server,认证server,在线server，实时计费sever,详丹与帐务server，业务管理server，对外接口server，数据库，数据仓库等等),这时就需要架构师了。我们单位目前的很多软件都属于这个类型，所以还是需要架构师啊：）
ozzzzzz 写道 我觉得江南白衣对于framework和architecture的区别还是有所混淆，至少不比rup中说的清楚。包括他列举的那些书单和所说的方法，都只是给类似公司总工的人的，而不是给类似Gates这样的构架师的。
可以说构架师80%的成分是管理和企业组织以及市场方面的，只有20%才是技术方面的。当然这20%的重要程度是50%。然而一个小型的软件公司（基本上国内所有的软件公司都包括在内），他们没有复杂的产品线，也没有很多历史用户负担，更没有那么多的细分市场，搞一个构架是不核算的，更不用说搞一个构架师了。 NO! 这个时候你的工作最多的依然是framework层面的。Architecture最大的用途，是治理公司的经营和生成结构，和人员结构，以及销售策略，更多的是战略层面的，而不是战术层面的。 |
| 返回顶楼 | |
|
发表时间：2007-02-19
hehe，那就是战术层面的吧。战略层面的的确是CTO和总工了。
但书单的书，应该对战术层面的架构师也适合吧。IBM DW的文章里还有架构师组的提法，一些大的项目，由一组架构师互补长短的进行共同设计，应该也是指战术层面的架构师。 |
| 返回顶楼 | |
|
发表时间：2007-02-19
隐藏票又长了....看来讲开发人员或者项目经理的事情大家心里都有同感，而架构和架构师，在大家在不同的组织，面对不同的项目时都有不同的定义，而且这些定义在自己的范围内都是对的，所以就难说到一块了，怪不得这个领域也没什么大卖的书了....
|
| 返回顶楼 | |
|
发表时间：2007-02-19
江南白衣 写道 隐藏票又长了....看来讲开发人员或者项目经理的事情大家心里都有同感，而架构和架构师，在大家在不同的组织，面对不同的项目时都有不同的定义，而且这些定义在自己的范围内都是对的，所以就难说到一块了，怪不得这个领域也没什么大卖的书了....
 白衣其实也不必太关注隐藏票的增减。
从文章上看，白衣很努力，  不过如果跟我们现在大多数人的理解差不多，而表述又不够清楚精炼的话，难免受到打击。 继续努力哦...
|
| 返回顶楼 | |
|
发表时间：2007-02-20
江南白衣 写道 hehe，那就是战术层面的吧。战略层面的的确是CTO和总工了。
但书单的书，应该对战术层面的架构师也适合吧。IBM DW的文章里还有架构师组的提法，一些大的项目，由一组架构师互补长短的进行共同设计，应该也是指战术层面的架构师。 DW是默认RUP为官方方法了，所以他们提出这样的概念我一点也不奇怪。 然而古话说“名不正，言不顺”。将Architecture无限放大将压缩下层技术人员的技术决策权利，同时造成对Architecture为核心构建程序的组织以臃肿组织结构和庞杂的管理系统。在我看来Architecture更多的是被提炼出来的设计规则，而不应该去被设计。 |
| 返回顶楼 | |
|
发表时间：2007-02-26
那么引子中的那个问题该怎么回答？
|
| 返回顶楼 | |
|
发表时间：2007-03-26
                 
|
| 返回顶楼 | |
|
发表时间：2007-07-16
个人观点：软件项目或者产品复杂到一定程度，架构师还是非常有必要的。
江南白衣所提到的项目就是我认为的复杂到了一定程度的项目。 引用 将Architecture无限放大将压缩下层技术人员的技术决策权利 客观来说，过分的民主还不如集中有效率。（当然，我非常赞成软件开发过程中，民主的正面作用）。我觉得Architect的职责在很多大型项目里面的作用和必要性还是很显著的。至少，不可能指望所有的工程师对项目都有全局认识，对于大项目，这个对很多普通工程师来说，要求太高了。 |
| 返回顶楼 | |
