软件架构师应该知道的97件事

  • 客户需求重于个人简历
  • 简化根本复杂性,消除偶发复杂性
  • 关键问题可能不是出在技术上
  • 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格
  • 架构决定性能
  • 分析客户需求背后的意义
  • 起立发言
  • 故障终究会发生
  • 我们常常忽略了自己在谈判
  • 量化需求
  • 一行代码比五百行架构说明更有价值
  • 不存在放之四海皆准的解决方案
  • 提前关注性能问题
  • 架构设计要平衡兼顾多方需求
  • 草率提交任务是不负责任的行为
  • 不要在一棵树上吊死
  • 业务目标至上
  • 先确保解决方案简单可用,再考虑通用性和复用性
  • 架构师应该亲力亲为
  • 持续集成
  • 避免进度调整失误
  • 取舍的艺术
  • 打造数据库堡垒
  • 重视不确定性
  • 不要轻易放过不起眼的问题
  • 让大家学会复用
  • 架构里没有大写的“i”
  • 使用“一千英尺高”的视图
  • 先尝试后决策
  • 掌握业务领域知识
  • 程序设计是一种设计
  • 让开发人员自己做主
  • 时间改变一切
  • 设立软件架构专业为时尚早
  • 控制项目规模
  • 架构师不是演员,是管家
  • 软件架构的道德责任
  • 摩天大厦不可伸缩
  • 混合开发的时代已经来临
  • 性能至上
  • 留意架构图里的空白区域
  • 学习软件专业的行话
  • 具体情境决定一切
  • 侏儒、精灵、巫师和国王
  • 向建筑师学习
  • 避免重复
  • 欢迎来到现实世界
  • 仔细观察,别试图控制一切
  • 架构师好比两面神
  • 架构师当聚焦于边界和接口
  • 助力开发团队
  • 记录决策理由
  • 挑战假设尤其是你自己的
  • 分享知识和经验
  • 模式病
  • 不要滥用架构隐喻
  • 关注应用程序的支持和维护
  • 有舍才有得
  • 先考虑原则、公理和类比再考虑个人意见和口味
  • 从“可行走骨架”开始开发应用
  • 数据是核心
  • 确保简单问题有简单的解
  • 架构师首先是开发人员
  • 根据投资回报率(roi)进行决策
  • 一切软件系统都是遗留系统
  • 起码要有两个可选的解决方案
  • 理解变化的影响
  • 你不能不了解硬件
  • 现在走捷径,将来付利息
  • 不要追求“完美”,“足够好”就行
  • 小心“好主意”
  • 内容为王
  • 对商业方,架构师要避免愤世嫉俗
  • 拉伸关键维度,发现设计中的不足
  • 架构师要以自己的编程能力为依托
  • 命名要恰如其分
  • 稳定的问题才能产生高质量的解决方案
  • 天道酬勤
  • 对决策负责
  • 弃聪明,求质朴
  • 精心选择有效技术,绝不轻易抛弃
  • 客户的客户才是你的客户!
  • 事物发展总会出人意料
  • 选择彼此间可协调工作的框架
  • 着重强调项目的商业价值
  • 不仅仅只控制代码,也要控制数据
  • 偿还技术债务
  • 不要急于求解
  • 打造上手(zuhanden)的系统
  • 找到并留住富有激情的问题解决者
  • 软件并非真实的存在
  • 学习新语言
  • 没有永不过时的解决方案
  • 用户接受度问题
  • 清汤的重要启示
  • 对最终用户而言,界面就是系统
  • 优秀软件不是构建出来的,而是培育起来的

你可能感兴趣的:(软件架构师应该知道的97件事)