软件架构师应该知道的97件事
1.? 客户需求重于个人简历 ( Nitin Borwankar )
客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。
//-----
这里讲的是需求,其实听过一个故事,山寨产的吹空盒子用大风力电扇,而大公司却花重金,用各种技术来判断,其实实现的效果都是一样的.软件的3个元素,时间,成本,质量之前的权衡,选择一个平衡点,才是关键.
还有技术上还是选择自己可以把控的技术这样会比较好点,避免了风险.
?
2.? 简化根本复杂性 ,消除偶发复杂性 ( Neal Ford )
分析问题好比拨云见月、水落石出。
//面对业务分析,我比较经常的手段是, 用户的用例图分析, 哪些角色 做了哪些动作 , 分享完了这些,进行提炼,分析出所需要操作的实体 Entity 在分析出Entity之间的Relation,在根据 Entity和Relation得到View,这些在给Actor看,是否是Actor需要的,这样进行迭代,几次就差不多了.先理清楚,在下手.
?
3.? 关键问题可能不是出在技术上 ( Mark Ramm )
团队同心,其利断金。
//技术只是一个方面可以学,可以培训,可是团队如果没有和谐,相互包容的气氛是不行的.团队是互补性的,一起进步才行,现在不是个人英雄的时代的了.
?
4.? 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 ( Mark Richards )
沟通应当言简意赅、详略得当,别拖泥 带水。
//问题大家说说就知道的了,怎么做就可以行动了,但是对于标准的制定上还是有一个人要强势的制定一个标准,当然也要听大家的意见.
?
5.? 架构决定性能 ( Randy Stafford )
种瓜得瓜,种豆得豆,架构设计也是一 样道理。
//钢筋混凝土的时代还在继续,性能有待提升,先完成需求在进行优化,功能胜于性能,但是必须不但完善自己的设计,这个也是自己得把握的,毕竟现在为老板干活看到的是效果.
?
6.? 分析客户需求背后的意义 ( Einar Landre )
抽丝剥茧,洞见症结。不要被表面需求 迷惑。
//对于客户的需求不是每个都需要的,有些是可以略去的,有些是可以通过技术来实现掉的,我自己的原则是,做有意义的功能,对于客户提出的复杂而没有实际使用价值的功能,会尽量去避免
?
7.? 起立发言 ( Udi Dahan )
起立发言效果更好。
//这个很少,原来有过段时间的早会,后来取消了,这个和国内的大环境有关
?
8.? 故障终究会发生 ( Michael Nygard )
应该提前设计预防措施,限制故障。
//故障,主要是安全方面,还有硬件的稳定性方面,硬件方面不好避免,可是系统安全方面真的得发时间,处理注入和跨站等问题,需要贯彻到所有的开发过程中,注意变量的过滤,审核大家的提交的代码.
?
9.? 我们常常忽略了自己在谈判 ( Michael Nygard )
工程师应该适时转换角色,学习谈判的 技巧。
//对于分析师或者架构师,是衔接开发人员和需求人员的一个接口角色,有的时候必须考虑到开发团队的时间及利益,需要去谈判
?
10. 量化需求 ( Keith Braithwaite )
没有规矩,不成方圆。
//需求整理很重要,我自己用的是MindManager在导出成文档.
?
11. 一行代码比五百行架构说明更有价值 ( Allison Randal )
可工作的代码才是目标,设计只是达成 目标手段。
//设计和实现,二者同样重要,设计是为了能够更好的实现,实现是为了验证设计,这个是提高的过程,只有去实践了才会有更好的设计
?
12. 不存在放之四海皆准的解决方案 ( Randy Stafford )
软件世界没有万 能 钥 匙。
//个别项目,个性化的设计,别考虑太多了,但是可以公用的,还是得把它提出来复用的
?
13. 提前关注性能问题 ( Rebecca Parsons )
尽早展开性能测试。
//性能测试往往在小团队里面会被忽视掉了,这个也是个很大的问题,性能测试我现在做的主要是
1.数据库方面的优化,索引,表结构,SQL语句方面,在设计好E-R图后,创建相关的业务VIEW,然后填充数据进行测试
2.在界面上部署时,会进行JS,CSS等的压缩处理,减少页面大小
3.使用ajax减少页面同时加载信息数
4.业务逻辑进行单元测试,关注逻辑性能
?
14. 架构设计要平衡兼顾多方需求 ( Randy Stafford )
平衡兼顾项目的技术需求和相关各方的业务需求。
//业务需求,和技术需求,一个处于项目需求方,一个针对内部团队.架构设计,往往是沿用自己熟练的框架,对于业务需求方面主要是界面,和用户交互,以及用户体验,往往技术选用在内部团队需要有一个普及过程.
?
15. 草率提交任务是不负责任的行为?? ( Niclas Nilsson )
要设法杜绝开发人员草率提交任务的念头。
//代码审核,code review 没有几个team会去认真做,这个在国内很普遍,我在的公司都没咋个做,也是很无奈啦...
?
16. 不要在一棵树上吊死?? ( Keith Braithwaite )
为客户提供多样化的解决方案。
//解决方案都是用解决方案模板的,针对不同的公司修改的,在国内方案往往很不被重视,关键在于酒桌和关系,无奈了.
?
17. 业务目标至上 ( DaveMuirhead )
技术决策不能脱离业务目标和现实条件的约束。
//在规定时间内能够上线,不出大的问题,这个是最重要的.
?
18. 先确保解决方案简单可用,再考虑通用性和复用性?? ( Kevlin Henney )
//在 时间 和 资金 还有 精力方面权衡了...代码重构还是在自己有体力,有心情的时候做,效率才会高
19. 架构师应该亲历亲为 ( JohnDavies )
身先士卒才能赢得同事的信任。
//技术必须是自己验证过可行了在进行普及
?
20. 持续集成 ( DavidBartlett )
//集成,这个就是不断完善自己的架构,或者说是框架了,自己用起来顺手就好了
?
21. 避免进度调整失误 ( NormanCarnovale )
不惜一切代价拒绝调整项目进度的要求。
//进度调整往往来自老板或者是需求方,这个也是很无奈的事情
?
22. 取舍的艺术 ( Mark Richards )
架构不可能满足所有需求。
//按照自己的方向,做自己这个领域内的架构,自己用起来顺手,提高工作效率就好了
?
23. 打造数据库堡垒 ( Dan Chak )
一开始就要定义好数据模型。
//数据库的设计和复用,最近这段时间来对数据库的设计上面还是认真的考虑到了复用了
?
24. 重视不确定性 ( Kevlin Henney )
推迟决策,建设性地利用不确定性。
//不确定性太多了,决策的时候往往没有经过足够的验证
?
25. 不要轻易放过不起眼的问题 ( Dave Quick )
别忘了温水煮青蛙的故事。
//小问题导致的问题很多,往往在SQL的没写好,导致性能的严重问题.
?
26. 让大家学会复用 ( Jeremy Meyer )
重复利用已有资源,首先要改变大家的观念。
//这点需要善于去看别人的文章,别人的代码,这点现在锻炼的比较好了,比较喜欢去看别人的代码,特别喜欢逛开源的网站了 google code, sourceforge等
?
27. 架构里没有大写的“I ” ( DaveQuick )
变让自己变成自大狂。
//自大狂不至于,定一个规范和标准必须是有一个决策者的
?
28. 使用“ 一千英尺高” 的视图 ( Erik Doernenburg )
选择合适的架构视图。
//可伸缩的视图才是需要的,小到块视图,达到整体的视图,以类图和E-R图表现出来
?
29. 先尝试后决策 ( Erik Doernenburg )
//做决策必须结果论证
30. 掌握业务领域知识 ( Mark Richards )
//业务的分析能力需要基类的
?
31. 程序设计是一种设计 ( EinarLandre )
软件开发也分成设计和生产两个阶段。
//设计和生产,还没达到这样的
?
32. 让开发人员自己做主 ( PhilipNelson )
//对架构或者框架进行扩张是个好主义
?
33. 时间改变一切 ( PhilipNelson )
选择值得投入精力的工作,别跟以前的工作过不去。
//但凡认真的做事情,总是会进步的
?
34. 设立软件架构专业为时尚早 ( Barry Hawkins )
//这个也可以开课讲的?
?
35. 控制项目规模 ( DaveQuick )
//项目的规模是需求方主导的
?
36. 架构师不是演员,是管家 ( Barry Hawkins )
别忘了你的工作责任。
//需要综合考虑 资源 时间 进度等
?
37. 软件架构的道德责任 ( Michael Nygard )
架构师的决定会影响许多人,务必慎重。
//项目流产,架构师要负很大的责任的,当然项目经理的责任更多些
?
38. 摩天大厦不可伸缩 ( Michael Nygard )
但软件可以。
//要什么样的东西,先设计好,画个图给大家看看
?
39. 混合开发的时代已经来临 ( Edward Garson )
//何为混合开发?
?
40. 性能至上 (CraigRussell )
//进度,性能,自动化,需要的是一个平衡,应该不能强调某个重要方面
?
41. 留意架构图里的空白区域 ( Michael Nygard )
空白区域“充满”了各种软件和“硬件”。
//写好备注还是很重要的,一些实现是需要前置和后置条件的
?
42. 学习软件专业的行话 ( Mark Richards )
同行之间讲行话方便交流。
//吹也要对想听的人吹就好了
?
43. 具体情境决定一切 ( Edward Garson )
//可以复用的就复用了,个性化的东西托出来研究
?
44. 侏儒、精灵、巫师和国王 ( Evan Cofsky )
开发团队不应该同质化。
//各司其职,互补,共进,可是现在我还没在这样的团队里面过
45. 向建筑师学习 ( Keith Braithwaite )
借鉴建筑行业的经验。
//设计模式还是得用的,别过渡就好了,我就会2-3个...嘎嘎,经常用的.
46. 避免重复 ( Niclas Nilsson )
//重复无法避免
47. 欢迎来到现实世界 ( Gregor Hohpe )
现实世界比软件世界复杂。
//真的做这些功能是现实世界需要的功能么>
48. 仔细观察,别试图控制一切 ( Gregor Hohpe )
49. 架构师好比两面神 ( DavidBartlett )
架构师应该像两面神一样,眼观六路、耳听八方。
50. 架构师应关注边界和接口? ( Einar Landre )
寻找自然的边界,分而治之。
51. 助力开发团队 ( Timothy High )
优秀团队是成功的保障,要尽量助力开发团队。
52. 记录决策理由 ( Timothy High )
记录架构决策背后的理由,具有极高的投资回报价值。
53. 挑战假设, 尤其是你自己的 ( Timothy High?? )
臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。
54. 分享知识和经验 ( Paul W. Homer )
帮助周围的人不断改善,他们也会帮助我们发挥出全部的潜力。
55. 模式病 ( Chad La Vigne )
不要让一展设计模式功力的欲望,遮蔽了务实的真知。
56. 不要滥用架构隐喻 ( DavidIng )
不要耽溺于系统隐喻之中,反让它拖了后腿。
57. 关注应用程序的支持和维护 ( Mncedisi Kasper )
应用程序的支持和维护,永远都不应该是事后才考虑的事情。
//这点还是很关键的了,很多时候都是开发完了就不想去弄他们的了..
58. 有舍才有得 ( Bill de hóra )
珍惜需要权衡的时机,远胜毫无约束和限制。
59. 原则、公理和类比胜于个人意见和口味 ( Michael Harmer )
60. 从“ 可行走骨架” 开始开发应用 ( Clint Shank )
从“ 可行走骨架” 开始,增量培育系统成长 。
61. 数据是核心( Paul W. Homer )
从“数据是核心”这个角度去认识系统,能大大降低理解复杂度 。
//数据是个核心问题需要好好的解决掉,做好备份
62. 确保简单问题有简单的解 (Chad La Vigne )
63. 架构师首先是开发人员 (Mike Brown )
碰到麻烦时,架构师可不能只会干吹烟圈却束手无策。
//技术是自己的强项
64. 根据投资回报率(ROI )进行决策( George Malamidis )
65. 一切软件系统都是遗留系统( Dave Anderson )
软件很快便会过时,修改维护无可避免。
66. 起码要有两个可选解决方案( Timothy High )
67. 理解变化的影响 ( Doug Crawford )
清楚认识变化类型及其影响。
68. 你不能不了解硬件( Kamal Wickramanayake )
硬件容量规划,是和软件架构同等重要的事情。
69. 现在走捷径,将来需付息( Scot Mcphee )
及时还清技术债务。
//这点深刻的体会到了,自己问题的所在呵呵....
?
70. 不要追求“完美”,“足够好”就行( Greg Nyberg )
避免过度设计。
71. 小心“好主意” ( Greg Nyberg )
//有些变更,还有重构不一定要立马做,要测试完全没有问题在进行,否则会完蛋的
72. 内容为王 ( Zubin Wadia )
73. 对商业方,架构师要避免愤世嫉俗( Chad La Vigne )
74. 拉伸关键维度,发现设计中的不足( Stephen Jones )
75. 架构师要以自己的编程能力为依托( Mike Brown )
76. 命名要恰如其分( SamGardiner )
弄清楚要做的究竟是什么。
77. 稳定的问题可以获得高质量的解决方案( Sam Gardiner )
78. 天道酬勤( Brian Hart )
真正做好那些看似简单的任务,坚守承诺。
79. 对决策负责( Yi Zhou )
80. 弃聪明,求质朴( Eben Hewitt )
81. 精心选择有效技术,绝不轻易抛弃( Chad La Vigne )
82. 客户的客户才是你的客户!( Eben Hewitt )
83. 事物发展总会出人意料 ( Peter Gillard-Moss )
设计是在不断变化的世界中持续进行探索试验的过程。
84. 选择彼此间能和谐共处的框架 ( Eric Hawthorne )
当心“无所不能”型的框架。
85. 着重强调项目的商业价值( Yi Zhou )
86. 不仅仅只控制代码,也要控制数据 ( Chad La Vigne )
87. 偿还技术债务 ( Burkhardt Hufnagel )
在速度和架构间进行权衡,保持平衡。
88. 不要急于求解( Eben Hewitt )
首先看看是否可以改变问题。
89. 打造称手的系统( Keith Braithwaite )
90. 找到并留住富有激情的问题解决者 ( Chad La Vigne )
91. 软件并非真实的存在 ( Chad La Vigne )
虚拟世界中的软件是柔韧可变的。
92. 学习新语言 ( Burkhardt Hufnagel )
防止沟通不畅和误解 。
93. 没有永不过时的解决方案( RichardMonson-Haefel )
94. 用户接受度问题( NormanCarnovale )
减轻用户接受度问题带来的风险。
95. 清汤的重要启示 ( Eben Hewitt )
软件架构设计需要不断的精炼浓缩。
96. 对最终用户而言,界面就是系统 ( Vinayak Hegde )
97. 优秀软件不是构建出来的,而是培育起来的( Bill de hóra )
?
转