软件架构师应该知道的97件事 笔记(三)

31. 程序设计是一种设计

 

代码即文档，写代码即是设计行为，而非生产行为。

 

32. 让开发人员自己作主

应该给自己的团队足够的自主权，让他们发挥自己的创意和能力。不要过于拘泥于细节，要为开发人员创造一个良好的开发体验，如自己设计的API是否易于理解及使用，如果经常被误用，应该怎么修改。而且要创造一个良好的氛围，让大家主动起来，如果遇到什么问题，及时的向你征求意见。

 

33. 时间改变一切

让结果说话，认真执行KISS原则。现在的设计，可能会被两三年之后的自己所否定，同样，以前的设计也容易被自己否定，所以不要跟以前的工作过不去。

 

34. 设计软件架构专业为时尚早

软件开发仍处于相对初级的尝试阶段

 

35. 控制项目规模

尽量控制和缩小项目规模，提高项目成功机会。

a) 抓住真正需求

b) 分而治之

c) 设置优先级

d) 尽快交付

 

36. 架构师不是演员是管家

炫耀和作秀放到市场营销上去，而不是设计中，架构师应该把自己看成管家，承担着管理他人资产的责任，为客户利益着想。

 

37. 软件架构的道德责任

任何浪费用户时间的行为，就是不道德的行为。即使只浪费用户一点时间，但影响到几百万用户时，累加起来就是一个非常长的时间。应该浪费自己的时间，节省用户的时间。

 

38. 摩天大厦不可申缩

软件相对建筑，扩展新功能要简单的多，而且产品发布越早，公司的净收益就会越高，所以，应用软件只要具备了用户要求的关键功能就可以发布了。提早发布，还能持续改善软件架构的品质。

 

39. 混合开发的时代已经来临

混合编程是指在同一套软件系统中同时采用多种核心编程语言。

把若干强大的工具组合起来，形成更巧妙的解决方案。

 

40. 性能至上

性能和其它指标一样重要，减少软件响应时间，提高人机交互效率。

不要拿摩尔定律来安慰自己，认为硬件及系统的速度足够快并且以后会更快，而忽略了软件性能。

 

41. 留意架构图里的空白区域

架构图中的两个模块之间，仍有很多细节需要考虑，比如A和B的通信，在架构图上可能只是简单的一个箭头，但实际上要考虑两个程序之间的响应时间，如果超时如何处理，如果中间电缆出问题怎么办等。

 

42. 学习软件专业的行话

使用行话可以提高交流质量及效率。如企业架构模式、应用架构模式、集成模式、设计模式、反模式等。

 

43. 具体情境决定一切

设计架构的过程就是做出明智决策的过程。脱离了具体的情景比较技术的优劣是无意义的。

 

44. 侏儒、精灵、巫师和国王

一个团队中要有各种性格和各种特长的人，招聘时尽量招聘不同性格的人。

相同的人在一起，视野往往不够开阔。安排任务时也尽量根据团队成员的特点来安排，让大家相互学习。

 

45. 向建筑师学习

要想成为伟大的建筑师，优雅丰富的心灵远比聪明才智重要。 --- 弗兰克·劳埃特·赖特

建筑师应该是伟大的雕塑家，或者伟大的画家，否则他不过是个建筑工人。 --- 约翰·拉斯金

架构应该蕴涵适当的艺术成份。