文档介绍：2. 简化根本复杂性,消除偶发复杂性( Neal Ford )
分析问题好比拨云见月、水落石出。
这个问题同样要求架构师能对问题有准确的分析,首先要发现问题的矛盾点,从而改变问题,然后对问题进行确认,从而形成最终方案,只有问题确定了,方案才会变的有意义。
3. 关键问题可能不是出在技术上( Mark Ramm )
团队同心,其利断金。
一个团队的团结可以比架构师自身能力要重要,一个架构师还要担负粘合团队能力的作用,一个不稳定的团队是做不出好的项目或者产品的。
如果架构师或者经理仅仅关注项目计划、项目进度,仅仅靠管理技术管理一个团队,则这个团队是不稳定的,只有为这个团队注入了灵魂,这个团队才会变的有生机,才能创造更大的价值
4. 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格( Mark Richards )
沟通应当言简意赅、详略得当,别拖泥带水。
人无时无刻不存在沟通,但是如何建立有效的沟通是至关重要的,沟通必须时刻关注问题点。
即沟通前,我们每个人都应该有个目标,通过沟通,我们想达到一个什么目标,有了这个目标,才能使整个的沟通更加有效。
6. 分析客户需求背后的意义( Einar Landre )
抽丝剥茧,洞见症结。不要被表面需求迷惑。
一个架构师的最主要的能力就是对问题以及需求的分析,架构师随着年龄的增长,他的技术水平可能会下降,但是他对问题的分析能力以及解决能力都在不断的提升,这种能力和技术本身没有什么关联。当一个架构师面对一个问题,能够很快的找出关键点所在,并针对问题域给出解决方案,这才是架构师能力体现差异化的最大的标准。
7. 起立发言( Udi Dahan )
起立发言效果更好。
起立发言能使自己有一种责任感,能强化自我认同意识。
9. 我们常常忽略了自己在谈判( Michael Nygard )
工程师应该适时转换角色,学习谈判的技巧。
通常把架构师看成一个技术层面的角色,但是现实情况是架构师还要担负起很多其他的责任,包括同用户沟通需求,
同用户沟通需求需要谈判的技术。
10. 量化需求( Keith Braithwaite )
没有规矩,不成方圆。
在现在项目管理中,量化需求是一个最基本的要求,领导要做资源调配,要想量化需求,则要对需求要有详细、清楚的了解,其实整个的研发阶段真实客观的了解用户的需求是至关重要的。
11. 一行代码比五百行架构说明更有价值( Allison Randal )
可工作的代码才是目标,设计只是达成目标手段。
架构师不要陷入到过度设计的泥沼,任何详细的架构设计到研发阶段总会发现一些问题,所以架构设计要适中。
12. 不存在放之四海皆准的解决方案( Randy Stafford )
软件世界没有万能钥匙。
任何解决方案都不是万能的,不加任何限制的解决方案都是不可信的,所以也不要奢求构架出能解决所有问题的解决方案
13. 提前关注性能问题( a Parsons )
尽早展开性能测试。
提前关注性能问题应该从两个方面:第一,软件架构师要根据获得的性能需求以及业务场景给出合理的架构设计,例如是否采用缓存等;
另一个方面就是要求编程人员有良好的编程习惯。所谓的尽早展开性能测试,最主要的要了解业务数据量的需求分析,如果前期对业务调研不够充分,很容