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

软件架构师应该知道的97件事软件架构师是IT?行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事，?博文视点?即将翻译出版的新书《软件架构师应该知道的97?件事》（97 Things Every Software Architect Should Know?）探讨的就是这个主题。本书的编辑Richard Monson-Haefel?是畅销书《?Enterprise JavaBeans?》和《?Java?消息服务?》的作者。Richard?邀请五十多位杰出的软件架构师分享工作经验和观点，帮助读者少走弯路。其中不乏大家熟悉的名字：《?卓有成效的程序员?》的作者Neal Ford，《?企业集成模式?》的作者Gregor Hohpe，?Servlets?和JSP?专家组和W3C RDF工作组技术专家Bill de hóra，?《?Web?应用程序快速开发?：?使用TurboGears?》的作者Mark Ramm，《?Release It!?》的作者Michael Nygard，《?软件开发沉思录》的作者之一Rebecca Parsons?博士，活跃于Perl?社区的女架构师Allison Randal?，《?Java SOA Cookbook?》的作者?Eben Hewitt?，?等等。下面内容摘自该书的标题，并给出了必要的补充说明， 由本书译者SeanBV（他的CSDN博客）整理，推荐给大家。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．?