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