- 浏览: 216069 次
- 性别:
- 来自: 哈尔滨
文章分类
最新评论
-
lizhenzhendebishe:
提示An error was discovered proce ...
WebService:Axis客户端调用需要身份验证的CXF服务 -
yuanliangding:
学习了。不太接触底层的东西
UNIX系统的IO模型 -
_copythat:
加油,。。。
阳光总会在风雨之后洒向苍茫 -
donlianli:
莫非去淘宝菜鸟网络了?
阳光总会在风雨之后洒向苍茫 -
菜鸟小于:
我也是哈尔滨的,在广州做了三年的开发,可是实际上我们是在维护一 ...
阳光总会在风雨之后洒向苍茫
1. 客户需求重于个人简历 ( Nitin Borwankar )
客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。
2. 简化根本复杂性 ,消除偶发复杂性 ( Neal Ford )
分析问题好比拨云见月、水落石出。
3. 关键问题可能不是出在技术上 ( Mark Ramm )
团队同心,其利断金。
4. 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 ( Mark Richards )
沟通应当言简意赅、详略得当,别拖泥 带水。
5. 架构决定性能 ( Randy Stafford )
种瓜得瓜,种豆得豆,架构设计也是一样道理。
6. 分析客户需求背后的意义 ( Einar Landre )
抽丝剥茧,洞见症结。不要被表面需求迷惑。
7. 起立发言 ( Udi Dahan )
起立发言效果更好。
8. 故障终究会发生 ( Michael Nygard )
应该提前设计预防措施,限制故障。
9. 我们常常忽略了自己在谈判 ( Michael Nygard )
工程师应该适时转换角色,学习谈判的技巧。
10. 量化需求 ( Keith Braithwaite )
没有规矩,不成方圆。
11. 一行代码比五百行架构说明更有价值 ( Allison Randal )
可工作的代码才是目标,设计只是达成目标手段。
12. 不存在放之四海皆准的解决方案 ( Randy Stafford )
软件世界没有万能的钥匙。
13. 提前关注性能问题 ( Rebecca Parsons )
尽早展开性能测试。
14. 架构设计要平衡兼顾多方需求 ( Randy Stafford )
平衡兼顾项目的技术需求和相关各方的业务需求。
15. 草率提交任务是不负责任的行为 ( Niclas Nilsson )
要设法杜绝开发人员草率提交任务的念头。
16. 不要在一棵树上吊死 ( Keith Braithwaite )
为客户提供多样化的解决方案。
17. 业务目标至上 ( Dave Muirhead )
技术决策不能脱离业务目标和现实条件的约束。
18. 先确保解决方案简单可用,再考虑通用性和复用性 ( Kevlin Henney )
19. 架构师应该亲历亲为 ( John Davies )
身先士卒才能赢得同事的信任。
20. 持续集成 ( David Bartlett )
21. 避免进度调整失误 ( Norman Carnovale )
不惜一切代价拒绝调整项目进度的要求。
22. 取舍的艺术 ( Mark Richards )
架构不可能满足所有需求。
23. 打造数据库堡垒 ( Dan Chak )
一开始就要定义好数据模型。
24. 重视不确定性 ( Kevlin Henney )
推迟决策,建设性地利用不确定性。
25. 不要轻易放过不起眼的问题 ( Dave Quick )
别忘了温水煮青蛙的故事。
26. 让大家学会复用 ( Jeremy Meyer )
重复利用已有资源,首先要改变大家的观念。
27. 架构里没有大写的“I ” ( Dave Quick )
别让自己变成自大狂。
28. 使用“ 一千英尺高” 的视图 ( Erik Doernenburg )
选择合适的架构视图。
29. 先尝试后决策 ( Erik Doernenburg )
30. 掌握业务领域知识 ( Mark Richards )
31. 程序设计是一种设计 ( Einar Landre )
软件开发也分成设计和生产两个阶段。
32. 让开发人员自己做主 ( Philip Nelson )
33. 时间改变一切 ( Philip Nelson )
选择值得投入精力的工作,别跟以前的工作过不去。
34. 设立软件架构专业为时尚早 ( Barry Hawkins )
35. 控制项目规模 ( Dave Quick )
36. 架构师不是演员,是管家 ( Barry Hawkins )
别忘了你的工作责任。
37. 软件架构的道德责任 ( Michael Nygard )
架构师的决定会影响许多人,务必慎重。
38. 摩天大厦不可伸缩 ( Michael Nygard )
但软件可以。
39. 混合开发的时代已经来临 ( Edward Garson )
40. 性能至上 (Craig Russell )
41. 留意架构图里的空白区域 ( Michael Nygard )
空白区域“充满”了各种软件和“硬件”。
42. 学习软件专业的行话 ( Mark Richards )
同行之间讲行话方便交流。
43. 具体情境决定一切 ( Edward Garson )
44. 侏儒、精灵、巫师和国王 ( Evan Cofsky )
开发团队不应该同质化。
45. 向建筑师学习 ( Keith Braithwaite )
借鉴建筑行业的经验。
46. 避免重复 ( Niclas Nilsson )
47. 欢迎来到现实世界 ( Gregor Hohpe )
现实世界比软件世界复杂。
48. 仔细观察,别试图控制一切 ( Gregor Hohpe )
49. 架构师好比两面神 ( David Bartlett )
架构师应该像两面神一样,眼观六路、耳听八方。
50. 架构师应关注边界和接口 ( Einar Landre )
寻找自然的边界,分而治之。
51. 助力开发团队 ( Timothy High )
优秀团队是成功的保障,要尽量助力开发团队。
52. 记录决策理由 ( Timothy High )
记录架构决策背后的理由,具有极高的投资回报价值。
53. 挑战假设, 尤其是你自己的 ( Timothy High )
臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。
54. 分享知识和经验 ( Paul W. Homer )
帮助周围的人不断改善,他们也会帮助我们发挥出全部的潜力。
55. 模式病 ( Chad La Vigne )
不要让一展设计模式功力的欲望,遮蔽了务实的真知。
56. 不要滥用架构隐喻 ( David Ing )
不要耽溺于系统隐喻之中,反让它拖了后腿。
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. 命名要恰如其分( Sam Gardiner )
弄清楚要做的究竟是什么。
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. 没有永不过时的解决方案( Richard Monson-Haefel )
94. 用户接受度问题( Norman Carnovale )
减轻用户接受度问题带来的风险。
95. 清汤的重要启示 ( Eben Hewitt )
软件架构设计需要不断的精炼浓缩。
96. 对最终用户而言,界面就是系统 ( Vinayak Hegde )
97. 优秀软件不是构建出来的,而是培育起来的( Bill de hóra )
客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。
2. 简化根本复杂性 ,消除偶发复杂性 ( Neal Ford )
分析问题好比拨云见月、水落石出。
3. 关键问题可能不是出在技术上 ( Mark Ramm )
团队同心,其利断金。
4. 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 ( Mark Richards )
沟通应当言简意赅、详略得当,别拖泥 带水。
5. 架构决定性能 ( Randy Stafford )
种瓜得瓜,种豆得豆,架构设计也是一样道理。
6. 分析客户需求背后的意义 ( Einar Landre )
抽丝剥茧,洞见症结。不要被表面需求迷惑。
7. 起立发言 ( Udi Dahan )
起立发言效果更好。
8. 故障终究会发生 ( Michael Nygard )
应该提前设计预防措施,限制故障。
9. 我们常常忽略了自己在谈判 ( Michael Nygard )
工程师应该适时转换角色,学习谈判的技巧。
10. 量化需求 ( Keith Braithwaite )
没有规矩,不成方圆。
11. 一行代码比五百行架构说明更有价值 ( Allison Randal )
可工作的代码才是目标,设计只是达成目标手段。
12. 不存在放之四海皆准的解决方案 ( Randy Stafford )
软件世界没有万能的钥匙。
13. 提前关注性能问题 ( Rebecca Parsons )
尽早展开性能测试。
14. 架构设计要平衡兼顾多方需求 ( Randy Stafford )
平衡兼顾项目的技术需求和相关各方的业务需求。
15. 草率提交任务是不负责任的行为 ( Niclas Nilsson )
要设法杜绝开发人员草率提交任务的念头。
16. 不要在一棵树上吊死 ( Keith Braithwaite )
为客户提供多样化的解决方案。
17. 业务目标至上 ( Dave Muirhead )
技术决策不能脱离业务目标和现实条件的约束。
18. 先确保解决方案简单可用,再考虑通用性和复用性 ( Kevlin Henney )
19. 架构师应该亲历亲为 ( John Davies )
身先士卒才能赢得同事的信任。
20. 持续集成 ( David Bartlett )
21. 避免进度调整失误 ( Norman Carnovale )
不惜一切代价拒绝调整项目进度的要求。
22. 取舍的艺术 ( Mark Richards )
架构不可能满足所有需求。
23. 打造数据库堡垒 ( Dan Chak )
一开始就要定义好数据模型。
24. 重视不确定性 ( Kevlin Henney )
推迟决策,建设性地利用不确定性。
25. 不要轻易放过不起眼的问题 ( Dave Quick )
别忘了温水煮青蛙的故事。
26. 让大家学会复用 ( Jeremy Meyer )
重复利用已有资源,首先要改变大家的观念。
27. 架构里没有大写的“I ” ( Dave Quick )
别让自己变成自大狂。
28. 使用“ 一千英尺高” 的视图 ( Erik Doernenburg )
选择合适的架构视图。
29. 先尝试后决策 ( Erik Doernenburg )
30. 掌握业务领域知识 ( Mark Richards )
31. 程序设计是一种设计 ( Einar Landre )
软件开发也分成设计和生产两个阶段。
32. 让开发人员自己做主 ( Philip Nelson )
33. 时间改变一切 ( Philip Nelson )
选择值得投入精力的工作,别跟以前的工作过不去。
34. 设立软件架构专业为时尚早 ( Barry Hawkins )
35. 控制项目规模 ( Dave Quick )
36. 架构师不是演员,是管家 ( Barry Hawkins )
别忘了你的工作责任。
37. 软件架构的道德责任 ( Michael Nygard )
架构师的决定会影响许多人,务必慎重。
38. 摩天大厦不可伸缩 ( Michael Nygard )
但软件可以。
39. 混合开发的时代已经来临 ( Edward Garson )
40. 性能至上 (Craig Russell )
41. 留意架构图里的空白区域 ( Michael Nygard )
空白区域“充满”了各种软件和“硬件”。
42. 学习软件专业的行话 ( Mark Richards )
同行之间讲行话方便交流。
43. 具体情境决定一切 ( Edward Garson )
44. 侏儒、精灵、巫师和国王 ( Evan Cofsky )
开发团队不应该同质化。
45. 向建筑师学习 ( Keith Braithwaite )
借鉴建筑行业的经验。
46. 避免重复 ( Niclas Nilsson )
47. 欢迎来到现实世界 ( Gregor Hohpe )
现实世界比软件世界复杂。
48. 仔细观察,别试图控制一切 ( Gregor Hohpe )
49. 架构师好比两面神 ( David Bartlett )
架构师应该像两面神一样,眼观六路、耳听八方。
50. 架构师应关注边界和接口 ( Einar Landre )
寻找自然的边界,分而治之。
51. 助力开发团队 ( Timothy High )
优秀团队是成功的保障,要尽量助力开发团队。
52. 记录决策理由 ( Timothy High )
记录架构决策背后的理由,具有极高的投资回报价值。
53. 挑战假设, 尤其是你自己的 ( Timothy High )
臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。
54. 分享知识和经验 ( Paul W. Homer )
帮助周围的人不断改善,他们也会帮助我们发挥出全部的潜力。
55. 模式病 ( Chad La Vigne )
不要让一展设计模式功力的欲望,遮蔽了务实的真知。
56. 不要滥用架构隐喻 ( David Ing )
不要耽溺于系统隐喻之中,反让它拖了后腿。
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. 命名要恰如其分( Sam Gardiner )
弄清楚要做的究竟是什么。
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. 没有永不过时的解决方案( Richard Monson-Haefel )
94. 用户接受度问题( Norman Carnovale )
减轻用户接受度问题带来的风险。
95. 清汤的重要启示 ( Eben Hewitt )
软件架构设计需要不断的精炼浓缩。
96. 对最终用户而言,界面就是系统 ( Vinayak Hegde )
97. 优秀软件不是构建出来的,而是培育起来的( Bill de hóra )
发表评论
-
使用zookeeper实现分布式共享锁
2013-04-13 15:59 2608分布式系统中经常需要协调多进程,多个jvm,或者多台机器之间 ... -
WebService:Axis客户端调用需要身份验证的CXF服务
2012-11-24 12:05 7082CXF服务端代码: 1、web.xml配置 < ... -
使用axis轻松调用Webservice
2012-11-10 13:15 22002使用axis1.4调用webservice有两种简单的方式: ... -
执行java程序时如何引用依赖的jar
2012-11-10 12:38 1793在执行java程序时我们可以通过-Djava.ext.dirs ... -
Log4j简单实用配置
2012-10-27 12:22 3677#A1为控制台输出,A2为文件输出,R为文件输出,并且按 ... -
JavaNIO处理长连接
2012-09-12 21:04 14154之前在IBM的网站上看到过一篇介绍NIO的文章,收获很大。但文 ... -
Int和byte数组之间的转换
2012-08-27 20:25 18825有时候和C的程序通信的时候,我们在封装协议时,可能需要将Jav ... -
用闭锁测试HashMap的并发写入问题
2012-08-27 19:39 3671今天无意中看到以前写 ... -
LDAP查询分页,基于迭代器的查询分页
2012-08-25 17:26 8624LDAP服务器端可以支持分页查询,但是有个前提条件 ... -
并行计算框架的Java实现--系列三
2012-07-14 14:38 4172接上篇并行计算框架的Java实现--系列二 优化锁,之 ... -
并行计算框架的Java实现--系列二
2012-07-14 08:41 2942接上篇并行计算框架的J ... -
并行计算框架的Java实现--系列一
2012-07-14 07:38 3522最近的工作需要统计一些复杂的报表,为了提高效率,想用多线程去实 ... -
ant初探
2012-06-29 13:38 2920前些天和同事交流,他说ant非常好用,他一直在用,学习资料共享 ... -
基于事件的 NIO 多线程服务器
2012-06-27 17:06 1287JDK1.4 的 NIO 有效解决了原有流式 IO 存在的线程 ... -
Java NIO学习
2012-06-22 22:46 0端午节加班要开发一个SocketServer,需要承载1000 ... -
httpclient访问https服务,可以信任证书
2012-06-02 00:48 6860private HttpClient initHttpClie ... -
Java或Web工程中查找配置文件
2012-06-02 00:35 1073String path = ""; URL ... -
如何获取真实的终端IP
2011-11-24 11:16 1224在有Apache做负载均衡的时候使用request.getRe ... -
MANIFEST.MF的应用以及如何读取jar包外的log4j.properties
2011-11-22 18:21 34MANIFEST.MF是jar文件的配置文件,在用eclips ... -
java实现的telnet协议
2011-10-02 17:14 7401package telnet; import j ...
相关推荐
软件架构师作为一个专业领域的高级职位,其核心职能...《软件架构师应该知道的97件事》这本书通过多位专家的经验分享,提供了一个关于如何成为优秀软件架构师的丰富知识库,对于提升软件架构师的专业能力具有重要价值。
《软件架构师应该知道的97件事》这本书,通过分享一系列心得,为软件架构师提供了一份职业成长的指南,其中包含了沟通、生产和文化三个方面的核心内容。 首先,沟通篇强调了沟通在软件架构中的重要性。软件架构师的...
### 97条架构师须知(架构师应当知道的97件事) #### 知识点一:需求先于履历 - **核心思想**:作为一名软件架构师,首要任务是满足客户的长期需求而非仅仅追求个人职业简历上的亮点。这意味着在选择技术或设计...
软件架构师应该知道的97件事 软件架构师应该知道的97件事 英文版
以上是对“软件架构师应该知道的97件事总结”的详尽解析,涵盖了软件架构设计中的多个方面,旨在帮助架构师更好地理解他们的角色,做出明智的决策,并创建出能够满足业务需求、具有良好性能和可维护性的软件系统。
《架构师应该知道的97件事》是一本由Richard Monson-Haefel编辑的书籍,汇集了软件架构领域的专家智慧。这本书旨在为软件架构师提供深入的理解和实用的指导,涵盖了一系列重要的知识点,以下是对其中几个核心概念的...
《软件架构师应该知道的97件事》是针对软件架构设计这一重要领域的知识总结,它涵盖了软件开发过程中架构师必须掌握的关键概念、原则和实践。作为软件架构师,理解并运用这些知识点对于创建高效、可扩展且易于维护的...