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

软件架构师应该知道的97件事 1．??客户需求重于个人简历?（?Nitin Borwankar?） 客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。 2．??简化根本复杂性?，消除偶发复杂性?（?Neal Ford?） 分析问题好比拨云见月、水落石出。 3．??关键问题可能不是出在技术上?（?Mark Ramm?） 团队同心，其利断金。 4．??以沟通为中心，坚持简明清晰的表达方式和开明的领导风格?（?Mark Richards?） 沟通应当言简意赅、详略得当，别拖泥 带水。 5．??架构决定性能?（?Randy Stafford?） 种瓜得瓜，种豆得豆，架构设计也是一 样道理。 6．??分析客户需求背后的意义?（?Einar Landre?） 抽丝剥茧，洞见症结。不要被表面需求 迷惑。 7．??起立发言?（?Udi Dahan?） 起立发言效果更好。 8．??故障终究会发生?（?Michael Nygard?） 应该提前设计预防措施，限制故障。 9．??我们常常忽略了自己在谈判?（?Michael Nygard?） 工程师应该适时转换角色，学习谈判的 技巧。 10．?量化需求?（?Keith Braithwaite?） 没有规矩，不成方圆。 11．?一行代码比五百行架构说明更有价值?（?Allison Randal?） 可工作的代码才是目标，设计只是达成 目标手段。 12．?不存在放之四海皆准的解决方案?（?Randy Stafford?） 软件世界没有万能钥匙。 13．?提前关注性能问题?（?Rebecca Parsons?） 尽早展开性能测试。? 14．?架构设计要平衡兼顾多方需求?（?Randy Stafford?） 平衡兼顾项目的技术需求和相关各方的业务需求。 15．?草率提交任务是不负责任的行为???（?Niclas Nilsson?） 要设法杜绝开发人员草率提交任务的念头。 16．?不要在一棵树上吊死???（?Keith Braithwaite?） 为客户提供多样化的解决方案。 17．?业务目标至上?（?Dave Muirhead?） 技术决策不能脱离业务目标和现实条件的约束。 18．?先确保解决方案简单可用，再考虑通用性和复用性???（?Kevlin Henney?） 19．?架构师应该亲历亲为?（?John Davies?） 身先士卒才能赢得同事的信任。 20．?持续集成?（?David Bartlett?） 21．?避免进度调整失误?（?Norman Carnovale?） 不惜一切代价拒绝调整项目进度的要求。 22．?取舍的艺术?（?Mark Richards?） 架构不可能满足所有需求。 23．?打造数据库堡垒?（?Dan Chak?） 一开始就要定义好数据模型。 24．?重视不确定性?（?Kevlin Henney?） 推迟决策，建设性地利用不确定性。 25．?不要轻易放过不起眼的问题?（?Dave Quick?） 别忘了温水煮青蛙的故事。 26．?让大家学会复用?（?Jeremy Meyer?） 重复利用已有资源，首先要改变大家的观念。 27．?架构里没有大写的“I?”?（?Dave Quick?） 变让自己变成自大狂。 28．?使用“?一千英尺高”?的视图?（?Erik Doernenburg?） 选择合适的架构视图。 29．?先尝试后决策?（?Erik Doernenburg?） 30．?掌握业务领域知识?（?Mark Richards?） 31．?程序设计是一种设计?（?Einar Landre?） 软件开发也分成设计和生产两个阶段。 32．?让开发人员自己做主?（?Philip Nelson?） 33．?时间改变一切?（?Philip Nelson?） 选择值得投入精力的工作，别跟以前的工作过不去。 34．?设立软件架构专业为时尚早?（?Barry Hawkins?） 35．?控制项目规模?（?Dave Quick?） 36．?架构师不是演员，是管家?（?Barry Hawkins?） 别忘了你的工作责任。 37．?软件架构的道德责任?（?Michael Nygard?） 架构师的决定会影响许多人，务必慎重。 38．?摩天大厦不可伸缩?（?Michael Nygard?） 但软件可以。 39．?混合开发的时代已经来临?（?Edward Garson?） 40．?性能至上?（Craig Russell?） 41．?留意架构图里的空白区域?（?Michael Nygard?） 空白区域“充满”了各种软件和“硬件”。 42．?学习软件专业的行话?（?Mark Richards?） 同行之间讲行话方便交流。 43．?具体情境决定一切?（?Edward Garson?） 44