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

31. 程序设计是一种设计

 

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

 

32. 让开发人员自己作主

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

 

33. 时间改变一切

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

 

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

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

 

35. 控制项目规模

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

a) 抓住真正需求

b) 分而治之

c) 设置优先级

d) 尽快交付

 

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

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

 

37. 软件架构的道德责任

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

 

38. 摩天大厦不可申缩

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

 

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

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

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

 

40. 性能至上

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

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

 

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

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

 

42. 学习软件专业的行话

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

 

43. 具体情境决定一切

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

 

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

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

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

 

45. 向建筑师学习

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

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

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

 

你可能感兴趣的:(设计模式,编程,api,招聘,文档,任务)