1000copy@gmail.com

欢迎来到1000copy@gmail.com>>　　 | 首页 资源中心 | 阅读 | Python | 专栏学习technet 系列课程 | 个人目标 | 家人 | 玩乐 | 技术 | ITPUB论坛

架构师，小到功能分解，大到系统决策

发表人:1000copy | 发表时间: 2006年七月19日, 22:33

架构师，小到功能分解，大到系统决策


能够把一个系统分解为多个子系统，每个系统之间的接口明确界定，从而分而治之，分而治之的目的是让每个子系统都不那么复杂，并且可以让一般的，不要求很高的水平的程序

员可以很好的处理。资源总是稀缺的，架构师是最稀缺的人才，他来做高层的分解当然是最合适的。

企业并非总是需要架构师这个角色 ，很多时候功能分解都是必须的，也是人人都做的来的。分而治之，从panas时代开始就已经深入程序员的内心的。
当我们觉得这个功能项目还不能一句话说清楚，还不能数理化的说，还不能够比较有把握的说可以多久做到出来的时候，往往意味着我们还需要继续分解。
当然有些时候我们觉得烦了，不想分解了，其实不是不做分解了，而是在边调试，边coding的时刻继续做分解。但是这个方式开始有些变化，也不是写文档或者画图构思了。
也就不那么令人烦恼。

自顶向下通常意味着降低风险，全局在控制内，但是有时候还是需要自底向上，比如复杂的技术问题，平台开发，新技术应用比较多的项目，可能会出现“因为我不知道怎么做，

所有也无法分工”的现象，或者“勉强把耦合度大的大模块分开为几个模块，还不如一个人搞定”的现象。


这样情况必然会有，但是项目管理者必须清晰的认识到，这是项目中的“风险”条目，需要回答一个问题“如果这个风险成为一个现实，我将如何应对？”。

系统架构师当然不是仅仅技术而已，就说划分子系统的接口而言，同样的系统，不同的人会有不同的划分方法，每个人都会依赖于个人的背景，历史，习惯，或者怪僻提出自己的

看法，有人说高手多了不易成事也是这个原因。为什么要采用我的想法？主要不是依赖职位，而是影响力。

认真的听取同事的意见，充分考虑他的想法，协调和平衡，明确自己的底线，反复强调最核心的不超过3条的观点（必杀技，不重要的不要讲），关键时刻的决断。整个一个谈判精

英了。

分类: ( 阅读 ) :: 评论 (0) :: 静态链接网址 :: 引用 (0)

发表评论

标题

在此添加评论

称呼

邮箱地址（可选）

个人主页（可选）




Valid XHTML 1.0 Strict and CSS. Powered by pLog
Design by Blog.lvwo.com