软件架构师应该知道的97件事--读书笔记.pdfVIP

软件架构师应该知道的97 件事笔记 by:ciahi /ciahi 1. 客户需求重于个人简历 1. 客户需求重于个人简历 11.. 客客户户需需求求重重于于个个人人简简历历 不要为了学习新的知识或丰富自己的简历而选择新技术解决问题，要尽量选择切 合实际的技术解决客户的难题。 脚踏实地的为客户着想，选择正确的方案可以降低项目的压力，团队工作起来更 开心，客户也会更满意，从而你也会有更充裕的时间学习新的知识。 2. 简化根本复杂性，消除偶发复杂性 2. 简化根本复杂性，消除偶发复杂性 22.. 简简化化根根本本复复杂杂性性，，消消除除偶偶发发复复杂杂性性 根本复杂性是问题本身就很复杂，所以它是无法避免的。偶发复杂性是在解决根 本复杂性的过程中衍生的，即解决方案本身带来的新问题。 如为了解决某个问题而设计的一个软件框架，设计该框架本身，就是引入的偶发 复杂性。所以，如果原本问题比较简单，但设计或引入一个太过灵活的框架，可 能得不偿失。(避免过度设计) 3. 关键问题可能不是出在技术上 3. 关键问题可能不是出在技术上 33.. 关关键键问问题题可可能能不不是是出出在在技技术术上上 简单的项目也可能会出现问题，这并不是因为我们选错了某种语言或者系统，根 本原因还是“人” 所以，要帮助团队完成项目，多与项目成员沟通，及时改正团队成员不正确的工 作方式。 沟通的技巧： a) 不要把对话看成对抗 改变心态，发现他人的优点，把沟通视为请教，就会有所收获，并且能避免引入 对方的戒备之心。 b) 不要带着情绪与人沟通 当你处于愤怒、沮丧、烦恼等情绪中时，对方可能会误认为你的举动不怀好意。 c) 尝试通过沟通设定共同的目标 4. 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 4. 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格 44.. 以以沟沟通通为为中中心心，，坚坚持持简简明明清清晰晰的的表表达达方方式式和和开开明明的的领领导导风风格格 架构师要避免只发号施令，让开发人员执行的弊病。要让开发人员了解项目的蓝 图和决策过程，让大家共同验证你的架构，让开发人员参与你的架构的制订过程， 这样开发人员才能更心甘情愿的去执行。 架构师应该提高自己的沟通技巧，帮助大家快速、精准的理解项目的目标。要言 简意赅的表达观点，用简单的图表来表达自己的想法。 用相机拍下自己在向团队成员表叙时在白板上写写画画的想法，会后分享给大 家，并且自己好好整理一下。 5. 架构决定性能 5. 架构决定性能 55.. 架架构构决决定定性性能能 如果架构有问题，仅仅通过优化局部，不足以获得理想的性能的。找出性能瓶颈， 优化瓶颈，如果需要的话，重新设计架构的内在逻辑和部署策略。 6. 分析客户需求背后的意义 6. 分析客户需求背后的意义 66.. 分分析析客客户户需需求求背背后后的的意意义义 分析客户提的需求，为什么提这样的需求。即要知道客户要求的功能和需求的真 正意义，这样或许我们可以在达到客户目的的情况下，采取更简单的办法。 7. 起立发言 7. 起立发言 77.. 起起立立发发言言 在多人场合发表意见时，起立发言非常重要，尤其是其他人坐着的时候。站立时， 无形中增添了一种权威和自信，容易控制了场面。听众不会轻易打断你的发言。 站立时可以更好的利用肢体语言，且在十人以上的场合，起立发言方便与每位听 众保持视线接触。眼神交流和肢体语言等表达在沟通中的作用不可小觎。起立发 言也更容易控制语气、语调、语速和嗓门，让声音传播的更远。讲到重点时，注 意语速的减缓，发声技巧也能改善沟通效果。 8. 故障终究会发生 8. 故障终究会发生 88.. 故故障障终终究究会会发发生生 为了防止A程序出错，增加了监控程序B，但监控程序B 本身就可能会出错。 所以故障及错误是无法避免的，即要做好错误的防范措施。 9. 我们常常忽略了自己在谈判 9. 我们常常忽略了自己在谈判 99.. 我我们们常常常常忽忽略略了了自自己己在在谈谈判判 项目投资人为了削减预算，可能会去掉一些“东西”。当投资人问“我们真的需要 这东西吗？” 很多工程师把自己摆在了工程师的位置，会回答一些不使用这些东 西的替代方案，但往往这些替代方案是极差的。在投资人看来，有其它方案可选， 他不关心是什么方案，他往往会让你去掉这些“东西”。 我们这时应该把自己放到谈判者的角度上，说明不使用该