Month: October 2010

世博后，世博园应该会被打造为上海的湾仔
Powered by MoFire

tranditional system asumption通常认为系统都不是分布的,系统是由一个集中的应用构成,并且大多数操作都是本地的,所有的交互都是可预测的,并且所有的全局状态都是可见的.
–这是大多数人仍然保有的观念,随着复杂度的增强,系统将变得越来越难以维护,原有的”简单”早就了后续工作的复杂度的剧增.

为了避免这种错误的观念,书中列出了两种方法:
1.proactive thinking leads to architecture,
2.design and software reuse

由于当前所使用的编程语言和系统容量,大多数的软件模块是不可维护的,除非是由原本创造的程序员.每年有30%的的开发人员更新率是的很多文档不全或者是由某些英雄主义程序员开发的系统变成不可维护的烟囱系统.

好的程序员是必要的,但不是使系统成功的充要条件.

没有计划,很多个人的成功并不足以让整个项目成功.
Without planning, it becomes apparent that many individual success are not sufficient for overall project success.

architecture-centered process(以架构为中心的过程)
步骤:
1.System envisioning(系统总览):决定purpose,focus,assumptions,and priority
2.requirement analysis(需求分析)
3.architecture planning(架构规划) :以下是Open Distributed Processing(ODP)的基本概念:
a.business enterprise architecture:关注业务建模
b.logical information architecture:关注数据库建模
c.computational interface architecture:关注接口设计
d.distributed engineering architecture:关注操作系统
e.technology selection architecture:关注网络工程
–ODP的主要贡献是提出了”关注点分离”的概念,可以让以上的每个架构concern由不同专业的人来分工完成.
4.mockup(界面模拟)
5.architecture prototype(架构原型)
6.project management planning(项目管理计划)
7.parallel incremental development(并行增量开发)
8.system transition(系统切换)
9.operations and maintenance(操作和维护)
10.system migration(系统升级)

时间安排:
50%的系统计划
50%的开发(其中编码占一半,测试和培训占一半)

通过架构来管理复杂度:
造成复杂度增加的原因有:
1.认为管理复杂度是不关紧要的
2.不重视教育/培训和实践理复杂度的模式
管理复杂度的常用方法:
1.封装
2.repository architecture
3.横向架构
4.分层架构
5.纵向架构

A software architect is sometimes required to mediate between conflicing demands of project management and higher-level stakeholders in  a devleopement project.
某种程度来说,每个项目计划都是”梦想”,是程序员一砖一瓦早就了交付的软件.架构师必须非常积极的去通过沟通和管理来满足程序员的需求,预估各种工具的采购,保证团队的被认可.架构师最终的价值在于让程序员可以高效有效的工作.

软件开发的一个常识:好的架构不是偶然发生的.而是必须经过规划,监控和不断的经受各种质疑的挑战之后才铸就的.如果作为架构师不能持续的监控软件的执行情况并确认是否按照约定和设计的运行,那么就是架构师的失职.

成功架构师的七个习惯:
1.keep it simple:和团队沟通时尽量沟通思想而不是技术细节.
2.let others defend the architecture: 让其他人来提出/回应技术方面的质疑.
3.act , dont argue: 争论伤感情,无产出,百害无一利.
4.keep an eye on the prize:始终想着最终目标
5.be willing to change , but never too much at once:不要引入太多风险,变化带来不可控,不可控就是风险点.
6.learn where to stop:不要过多的做细节的事,不要在设计决策方面进行微观管理
7.know how to follow:虚心跟随,打造专注高效的团队气氛