[读书笔记]软件架构师应该知道的97件事

  1、开发人员应该解决问题,而不是解迷取乐。

  2、关键问题可能不是出在技术上:

  • 不要把对话当成对抗
  • 不要带成情绪与人沟通
  • 尝试通过沟通设定共同目标

  3、以沟通为中心,坚持简明清晰的表达方式和开明的领导风格。

  • 让开发人员参与架构的制订过程,这样他们才会买你的帐!

  4、架构才是影响应用性能和可伸缩性的决定因素,性能参数是无法简单地通过更换软件,或者“调优”底层软件架构来改善的。

  5、分析客户需求背后的意义

  • 架构师可以通过询问客户,分析客户要求的功能和需求的真正意义,定位真正的问题,从而提出比客户的建议更好、成本更底的解决方案。

  6、让沟通事半功倍,起立发言是简单、有效的方法!

  7、故障终究会发生。

  8、量化需求

  • 比如:必须在1500毫秒响应用户的输入。在正常负载(定义如下....)的情况下,平均响应时间必须控制在750~1250毫秒之间。由于用户无法识别500毫秒以内的响应,所以我们必须将响应时间降低到这个范围之下。

  9、一行代码比五百行架构说明更有价值

  • 如果你亲自参与开发,应该珍视自己花在写代码上的时间,千万别听信这会分散架构师精力的说法。参与项目所付出的努力,既能拓展你的宏观视野,也能丰富你的微观视界。

  10、提前关注性能问题。

  11、草率提交任务是不负责任的行为。

  12、业务目标至上、掌握业务领域知识

  • 架构师必须通过沟通协调,即保护软件架构,又坚持业务目标,即允许开发人员制定微观(技术)决策,又设法避免他们参与制定业务决策。如果技术决策脱离了业务目标目标和现实条件的约束,则无异于用宝贵的稀缺资源进行高风险的投机。

  13、先确保解决方案简单可用,再考虑通用性和复用性。

  • 许多用来实现基础设施的代码,包括组件框架、类库、基础服务,普遍存在一个问题,它们的设计一味强调通用性而不考虑具体应用,导致出现许多令人困惑的可选项和不确定因素,这些功能常常不是因为被闲置,就是被误用,甚至毫无价值。

  14、架构师应该亲力亲为

  • 对技术缺乏全面理解的架构师,充其量只是个项目经理。
  • 架构师完全可以要求团队成员的帮助,让团队成员充分参与制订解决方案,同时引导讨论方向,找出正确的方案。
  • 架构师应该尽早参与项目,与团队成员并肩工作,而不是坐在象牙塔里发号施令。

  15、持续集成

  • 尽早构建,经常构建。

  16、避免进度调整失误

  • 加快进度不一定会降低成本,要考虑交付质量和后期造成的影响,可以尝试去掉一些不重要的功能,留待后续版本发布。

  17、取舍的艺术

  • 世界上不存十全十美的设计,既具有高性能,又具有高可用性;既高度安全,又高度抽象;

  18、不要轻易放过不起眼的问题

  • 自已的盲点自己难以查觉,忠言虽然逆耳,却是你最宝贵的财富。
  • 组织团队一起来想办法管理风险。

  19、让大家学会复用

  • 大家知道它们的存在
  • 大家知道如何使用它们
  • 大家认识到利用已有的资源好过自己动手

  20、架构里没有大写的"I"

  • 自我反省,做人问题。
  • 重视团队合作,架构属于团队,不是你一个人的。你负责导航,大家一起划桨。双方缺一不可,但相比之下,你更离不开他们的帮助。
  • 做技术的,保持谦虚是最基本的素质!

  21、先尝试后决策

  • 尽量推迟决定的时间,最后即便不做决策,决策也会自己呈现。
  • 对同一个问题尝试两种或两种以上的解决方案,比直接决策然后动手实现的工作量要大。

  22、程序设计是一种设计

  • 把编写代码看成设计行为,而不是生产行为。

  23、控制项目规模

  • 抓住真正的需求
  • 分而治之
  • 设置优先级
  • 尽快交付

  24、架构师不是演员,是管家。

  • 扎实掌握技术和业务领域知识,以严谨的领导风格赢得团队的尊重。

  25、混合开发的时代已经来临

  26、性能至上

  • 尤其目前的互联网行业

  27、学习软件专业的行话

  • 比如架构和设计模式可以分成四大类,企业架构模式、应用架构模式、集成模式和设计模式。

  28、具体情境决定一切

  • 架构决策只有在情境需要时,才能牺牲尽量简单的原则。

  29、侏儒、精灵、巫师和国王

  • 软件架构师好比国王,应该熟悉各种人的性格特点,招聘不同性格的人加入自己的团队,英明的国王知道怎样用目标来激励不同的种族,率领大家并肩作战完成任务。

  30、避免重复

  • 复制是魔鬼
  • 重复性的工作拖累开发进度

  31、仔细观察,别试图控制一切

  32、架构师当聚焦于边界和接口

  • 低耦合,高内聚
  • 定义系统边界

  33、助力开发团队

  • 确保开发人员拥有他们所需的工具
  • 确保开发人员拥有他们所需的技能
  • 只要不违背软件设计的总体目标,就让开发人员自己做出决策。
  • 保护好开发人员,不要让他们卷入到不那么重要的工作中。

  34、记录决策理由

  • 不要为了写文档而写。
  • 懂得《取舍的艺术》,定义软件架构,就是要在质量属性、成本、时间以及其它各种因素之间,做出正确的权衡。

  35、分享知识和经验

  36、模式病

  • 使用模式解决适用的问题才是最重要的,禁止在项目中硬塞不必要的模式。

  37、关注应用程序的支持和维护

  • 应用程序超过80%的生命周期都是在维护上
  • 理解开发人员和支持人员确实具有不同的技能
  • 在项目中尽可能早地引入支持负责人
  • 将支持负责人作为团队的核心成员之一
  • 让支持负责人参与规划应用程序的支持

  38、有舍才有得

  • 接受某种约束或放弃某个特性,可带来更好的架构,这种架构在构建和运维上都会更加简单,而且成本底。

  39、先考虑原则、公理和类比,再考虑个人意见和口味。

  40、数据是核心

  • IDE、操作系统、软件等都是工具。

  41、不仅仅控制代码,也要控制数据。

  • 源代码控制和持续集成,是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容通常会随着源代码变化而变化,它们也是这一过程的重要组成部分,因此也需要对之进行类似的控制。
  • 灵活运用“数据库脚本”解决问题。

  42、确保简单问题有简单的解

  • 对于简单的问题,不要采用复杂的解决方案。软件设计者都是聪明人,但是出于炫技心理,很容易陷入“杀鸡用牛刀”的误区。
  • 对应第一条“开发人员应该解决问题,而不是解迷取乐。”

  43、架构师首先是开发人员

  • 作为架构师,主要目标应该是创建可行、可维护的解决方案,当然,也一定要能解决当前的问题。

  44、根据投资回报率(ROI)进行决策

  45、一切软件系统都是遗留系统

  • 即使系统十分前沿,采用了最新的技术开发而成,但对于接手的下一个而言,它也会是遗留系统。
  • 设计优化的架构基础,考虑如下几个问题:清晰性、可测性、正确性、可跟踪
  • 可以参考一些优秀的开源项目

  46、起码要有两个可选的解决方案

  47、理解变化影响

  • 优秀的架构师能够深刻理解变化带来的影响,这种影响不仅限于彼此隔离的软件模块之间,而且包括人与人之间,以及系统与系统之间。
  • 变化有多种不同表现形式:功能需求的变化、可扩展性需求的演进、系统的接口被修改、团队人员流动等。
  • 常用方法减轻变化的影响:运行小规模的增量渐变、构建可重复运行的测试用例、让测试用例更易编写、跟踪好依赖关系、系统性的行动,根据反馈信息作出进一步反应、自动化重复的任务。

  48、你不能不了解硬件

  • 学习硬件知识
  • 和基础设施架构师紧密合作

  49、现在走捷径,将来付利息。

  50、不追求“完美”,“足够好”就行

  • 在设计和实现上追求完美,会导致过度设计和模糊混乱的解决方案,最终使系统难以维护。应用程序开发不是选美大赛,因此,停止吹毛求疵的做法,不要再浪费时间追求尽善尽美。

  51、小心“好主意”

  • 那种诱人的、不用想都知道的、外表无辜、以为不可能会产生伤害的那种“好”主意。通常在项目进展到一半而似乎一切看起来都挻好——形势和进度都在循序渐进,初步测试进展顺利,落地日期看起来可靠无误——的时候,项目团队中有人会冒出这些想法。务必小心那些“好主意”,它可能会杀死你的项目。

  52、内容为王

  • 很多系统的成功取决于其内容的建设。

  53、对商业方,架构师要避免愤世嫉俗。

  54、架构师要以自己的编程能力为依托

  • 对应“架构师首先是开发人员”

  55、稳定的问题才能产生高质量的解决方案

  • 只要问题是稳定的,你就可以创建出一个拥有稳定设计的系统。稳定的设计可以让你集中精力,打造出高质量的应用程序。

  56、天道酬勤

  57、弃聪明,求质朴。

  58、对决策负责

  • 重要的架构决策应该以书面形式记录下来,它们必须经过校核证实,并可被追溯。
  • 必须和执行该决策及会直接或间接受其影响的人进行过沟通,达成共识。

  59、精心选择有效技术,绝不轻易抛弃。

  60、客户的客户才是你的客户!

  61、事物发展总会出人意料

  • 设计是一个不断发现的过程,发现问题并解决问题。
  • 没有永不过期的解决方案。

  62、着重强调项目的商业价值

  • 形成价值陈述
  • 建立量化的度量标准
  • 回过头来关联传统商业的衡量方式
  • 知道该在哪里停止
  • 寻找恰当的时机

  63、偿还技术债务

  • 花合适时间“一次做对”!
  • 取巧走“捷径”,争取尽快推出修改后以产品。

  64、打造上手的系统

  • 用户体验很重要
  • 对最终用户而言,界面就是系统!

  65、找到并留住富有激情的问题解决者

  • 我们所要找的,是那种具备解决问题的能力和激情的开发人员,都善于攻克各种难题的人才。
  • 提防批评过度,它可能会扼杀开发人员的创造力,降底生产力。
  • 好的开发人员都非常聪明,他们知道自己并非一无是处,如果你对其工作吹毛求疵,将会降低他们对你的尊重!
  • 以正确的方式经营开发团队,其重要性不言而喻。

  66、学习新语言

  • 想要理解客户或者想让客户理解你的语言,必须学习客户所在行业领域的语言,这样才能做到有效沟通。

  67、优秀软件不是构建出来的,而是培育起来的。

  • 设计尽可能小的系统,帮助成功交付,并推动它向宏伟的远景目标不断演化。注意,不要把这种演化式方法和削减需求、规范混乱和生产废品这样的做法混淆在一起。
posted @ 2011-12-30 18:26  Astar  阅读(1911)  评论(0编辑  收藏