【转】架构师的自我修养(一)
1. 架构师既是技术专家,同时也是业务领域的专家,能够预见业务领域风险,并提供解决的办法。技术上经验丰富的人会有很多,只要在技术的道路上,总是会沉淀各种各样的技术。而对于业务的把握,则是一个缘分。需要有额外的兴趣,额外的时间投入,才能够有机会在相关的业务领域深入下去。
2. 架构师在选择技术的时候,要为客户着想,而不是为自己的简历着想,添上光辉一笔。
3. 选取框架技术的时候,量体裁衣,不要引入复杂性。衡量框架复杂性的指标: 代码中解决业务问题的代码所占的比例。
4. 项目中人才是关键,对于拖后腿的成员,要引入对话。首先,看到这个人的优点,设定一个共同的目标(最好是帮助别人)顺带能够弥补他的缺点,控制好情绪去沟通。(愤怒,沮丧,烦恼,慌张等都不可取)
5. 架构师能够言简意赅地表达自己的命令和技术决策非常重要,这能提高沟通效率,没有人愿意阅读冗长的架构决策文档。简便的白板,图表,加相
6. 架构师是团队的领导,必须要以身作则,获得同伴的尊敬,建立团结的工作环境
7. 架构决定性能,遵循分布式计算,物理学的基本原理来提高性能。架构性能是一个复杂的主题,从需求,到应用实现层,最后到数据库层,都可以做很多工作。不能轻信厂商,简单的更换硬件,或者底层软件架构WLS,JBOSS。
8. 分析客户需求背后的意义,极其更深层次的原因。比如,战斗机的速度需求是2.5马赫(2倍音速), 但这个需求背后的意义是“迅速撤离战场”,设计团队其实能够提出更好的建议,而不仅仅是2倍音速。所以架构师需要理解用户需求背后的意义,站在同一个层面去思考问题,提出更有效的解决方案,,并且把最有价值的需求摆在第一位。 了解背后的需求通常都不那么容易,因为客户经常认为那是不言而喻的,而技术团队则很难理解。
9. 增加自己的影响力,表现力,让开发人员,或者管理层接受自己的意见。任何时候都要以积极有效的状态去销售观点。比如,起立发言,眼神交流,语速等
10. 承认任何系统都有缺陷,所以要事先设计好防范故障的模型,应对威胁系统安全的意外情况
11. 架构师应该谨慎地站在业务团队的一边,把投资回报率当作项目的目标。
12. 架构师在面对需求时,要有足够的敏锐,让需求得以量化。而不是模棱两可的“要快”,“要可伸缩”,“要灵活”。 面对无法量化,至少要给一个范围
13. 项目开始时候就关注性能的设计,进行相关的性能测试。
14. 架构师要兼顾平衡,不仅创造优质软件,同时兼顾不同Stakeholder的目标。CEO要控制成本,运营要易于管理,开发要代码方便维护。有时紧急任务会打破平衡,让一些不易于维护的代码实现紧急需求,但是长期看,还是要维持一个稳定的平衡。
15. 想尽一切办法,让团队杜绝草率提交代码的行为。避免把有缺陷的代码丢给同事。所以自动化构建,自动化测试框架尤为重要。
16. 很多架构师都非常看重通用性和复用性,并以此作为炫耀的资本,最后造成过度的设计。追求所谓的灵活性,往往会错失一些简单的设计,以及更有价值的特性。 所以原则上,先确保解决方案的简单可用,再考虑通用性和复用性。
17. 架构师是技术团队和业务团队的接口人,能胜任所有的技术,才能代表技术团队发言。同时又要懂得业务,督促技术满足业务的需求。 要展示自己的实践能力,建立威信并赢得大家的尊重,成为大家的榜样。
18. 谨记MF的名言“尽早构建,持续构建”
19. 架构师要有谈判的技巧来应付突如其来的时间缩短,功能增多等要求来改变计划。迅速表明立场,质量为上,如果加快进度,那么就去掉部分不那么重要的功能,但是要确保核心功能的质量。 (取舍的艺术,通过讲故事来谈判,“瓦纳号”: 波兰国王提需求,既运兵又作战,结果起航礼炮结束后就立刻沉没了)
20. 架构师要非常非常重视数据的建模,严格遵守完整性,尽可能使用约束,恰当的Key,同时名称的定义也要不言而喻。
原文链接:
https://zzhonghe.iteye.com/blog/2032491