97条架构师须知转载.doc

97条架构师须知 转载 ? 以下原文转载自译言-编辑荐读 原作者： 来源97 things every software architect should know-the book-Softarch 97Things 译者刘昆云 97条架构师须知 原载：编译：刘昆云 1.Dont put your resume ahead ofthe requirements by Nitin Borwankar 【需求先于履历】 身为架构师要平衡客户、公司和个人的利益。用时兴的技术为个人履历增光添彩固然重要，但应该把客户的长远需求放在首位。约束技术偏好，能够使客户、团队、自己和家人都多些快乐。在未来的工作中，客户的口碑是比个人的履历更加宝贵的东西。 2.Simplify essential complexity；diminish accidental complexity by NealFord 【简化先天复杂性，避免后天复杂性】 任何业务问题都有其复杂性，简化复杂性是客观需要。但为此采取的工作很可能带来新的复杂性。了解代码中真正用于处理业务的比例，从实践中发展出恰当的系统框架，避免随意添加框架。后天复杂性的积累会使系统越来越难以维护和升级。 3.Chances are your biggest problemisnt technical by Mark Ramm 【技术不是最大问题】 聪明的架构师能够选择最恰当的技术，而有效的架构师则还要说服开发人员理解他的选择。软件是由人开发的，人心不齐才是最大的问题。有时人的问题导致项目失败，却让技术来背黑锅。必要时应进行平等的对话、理性的分析、耐心的解释。 4.Communication is King；Clarityand Leadership its humble servants byMark Richards 【沟通为王，澄清和引领为仆】 闭门造车、发号施令的架构师必将被反抗的开发者所推翻。架构师应就项目的宗旨和目标与开发人员沟通。有效沟通的要点是简明和垂范。抛开长篇大论的Word文档，使用清晰易懂的Visio图形；讨论时使用白板，对重要的内容拍照记录。与QA、PM和开发人员密切合作，让他们了解架构过程，洞悉架构全景，引领他们走出迷茫。 5.Architecting is aboutbalancing by Randy Stafford 【在平衡中进行架构】 架构工作包括模块划分、接口定义、职责分配、模式应用、性能优化等传统技术活动，也要考虑安全、可用性、支持、发布、开发条件等问题，更要照顾管理人员、操作人员、维护人员等有关各方的关切。要在平衡各方关切的过程中开展架构工作。 6.Seek the value in requestedcapabilities by Einar Landre 【鉴别客户要求中的价值】 客户往往把他们的思考作为解决他们所面临的问题的方案。但客户要求未必都是对解决实际问题有价值的。架构师应当提出更好、更节约的解决方案。这一目标可以通过和客户进行讨论达到。和客户讨论时，多从业务角度问问为什么，少使用软件术语，不要假定客户具有软件方面的知识。 7.Stand Up！by Udi Dahan 【站着说话】 架构师和项目组成员的沟通，不应象过去和机器打交道一样随意。当你的听众超过一个人时，自己就应当站着说话。站着说话的好处是有指挥整个房间的气势，增加了你的权威和自信，别人更不容易打断你的话。站着说话还能使用眼神交流、肢体语言，也有助于控制声音。站着说话，能提高沟通效果。 8.Skyscrapers arent scalable byMicheal Nygard 【摩天大楼不可伸缩】 把软件工程比喻成盖楼，有好的一面。从荒芜的工地到耸立的高楼，过程漫长。每一段时间中，每一个工人都要各尽其责，每一个未完工的构件都要稳稳当当才行，值得软件工程学习，这就是一次一个组件的增量部署。这个比喻也有不恰当的一面。摩天大楼在造成以后就不可搬迁、不可加层。而软件则可以反复调整，这就是及早发布(Early release)。 9.Youre negotiating more oftenthan you think.by Michael Nygard 【谈判多过你的想象】 我们作为工程师，更愿意与人协作。而项目负责人作为控制项目成本的人，更在乎削减成本。我们看到的是谈话，他看到的是谈判，所以我们常常遭受预算打击。如果你提了冗余、备份之类的东西后，他问你这个东西必须要有吗?,千万不要让步。不要说没有也行，只是会在故障恢复期间不能运行这样的话。反而要说：事实上不仅要两套，要四套才能确保万无一失。没有这个，每天就至少会有三次出问题，而且不排除当你正在给董事长做演示的时候出问题。 10.Quantify