霜天部落 | 关注LAMP高性能、高并发架构的设计与研究

怎么做最好的软件架构师?他们来告诉你!

怎么做最好的软件架构师?他们来告诉你!

1. 不要轻易放过不起眼的问题 ( Dave Quick )

别忘了温水煮青蛙的故事。

2. 让大家学会复用 ( Jeremy Meyer )

重复利用已有资源,首先要改变大家的观念。

3. 架构里没有大写的“I” ( Dave Quick )

不要让自己变成自大狂。

4. 使用“ 一千英尺高” 的视图 ( Erik Doernenburg )

选择合适的架构视图。

5. 客户需求重于个人简历 ( Nitin Borwankar )

客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉,往往事与愿违。

6. 简化根本复杂性,消除偶发复杂性 ( Neal Ford )

分析问题好比拨云见月、水落石出。

7. 关键问题可能不是出在技术上 ( Mark Ramm )

团队同心,其利断金。

8. 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 ( Mark Richards )

沟通应当言简意赅、详略得当,别拖泥带水。

9. 架构决定性能 ( Randy Stafford )

种瓜得瓜,种豆得豆,架构设计也是一样道理。

10. 分析客户需求背后的意义 ( Einar Landre )

抽丝剥茧,洞见症结。不要被表面需求迷惑。

11. 起立发言 ( Udi Dahan )

起立发言效果更好。

12. 故障终究会发生 ( Michael Nygard )

应该提前设计预防措施,限制故障。

13. 我们常常忽略了自己在谈判 ( Michael Nygard )

工程师应该适时转换角色,学习谈判的技巧。

14. 量化需求 ( Keith Braithwaite )

没有规矩,不成方圆。

15. 一行代码比五百行架构说明更有价值 ( Allison Randal )

可工作的代码才是目标,设计只是达成目标手段。

16. 不存在放之四海皆准的解决方案 ( Randy Stafford )

软件世界没有万能钥匙。

17. 提前关注性能问题 ( Rebecca Parsons )

尽早展开性能测试。

18. 架构设计要平衡兼顾多方需求 ( Randy Stafford )

平衡兼顾项目的技术需求和相关各方的业务需求。

19. 草率提交任务是不负责任的行为 ( Niclas Nilsson )

要设法杜绝开发人员草率提交任务的念头。

20. 不要在一棵树上吊死 ( Keith Braithwaite )

为客户提供多样化的解决方案。

21. 业务目标至上 ( Dave Muirhead )

技术决策不能脱离业务目标和现实条件的约束。

22. 先确保解决方案简单可用,再考虑通用性和复用性 ( Kevlin Henney )

23. 架构师应该亲历亲为 ( John Davies )

身先士卒才能赢得同事的信任。

24. 持续集成 ( David Bartlett )

25. 避免进度调整失误 ( Norman Carnovale )

不惜一切代价拒绝调整项目进度的要求。

26. 取舍的艺术 ( Mark Richards )

架构不可能满足所有需求。

27. 打造数据库堡垒 ( Dan Chak )

一开始就要定义好数据模型。

28. 重视不确定性 ( Kevlin Henney )

推迟决策,建设性地利用不确定性。

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. 找到并留住富有激情的问题解决者 ( Chad La Vigne )

90. 软件并非真实的存在 ( Chad La Vigne )

虚拟世界中的软件是柔韧可变的。

91. 学习新语言 ( Burkhardt Hufnagel )

防止沟通不畅和误解 。

92. 没有永不过时的解决方案( Richard Monson-Haefel )

93. 用户接受度问题( Norman Carnovale )

减轻用户接受度问题带来的风险。

94. 清汤的重要启示 ( Eben Hewitt )

软件架构设计需要不断的精炼浓缩。

95. 对最终用户而言,界面就是系统 ( Vinayak Hegde )