Apache架构师的30条设计原则


Apache架构师的30条设计原则

文章插图
【Apache架构师的30条设计原则】作者:Srinath 来源:ImportSource
本文作者叫 Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员 。他是 Apache Axis2 项目的联合创始人,也是 Apache Software 基金会的成员 。他是WSO2流处理器(wso2.com/analytics)的联席架构师 。Srinath 撰写了两本关于 MapReduce 和许多技术文章的书 。他获得了博士学位 。来自美国印第安纳大学 。
Srinath 通过不懈的努力最终总结出了30条架构原则,他主张架构师的角色应该由开发团队本身去扮演,而不是专门有个架构师团队或部门 。Srinath 认为架构师应该扮演的角色是一个引导者,讨论发起者,花草修建者,而不是定义者和构建者 。Srinath 为了解决团队内部的架构纷争和抉择,制定了以下30条原则,这些原则被成员们广泛认可,也成为了新手架构师的学习途径 。
基本原则原则1:KISS(Keep it simple,sutpid) 和保持每件事情都尽可能的简单 。用最简单的解决方案来解决问题 。
原则2:YAGNI(You aren’t gonna need it)-不要去搞一些不需要的东西,需要的时候再搞吧 。
(小编点评:speculative development的例子可谓俯拾皆是 。程序员们对自己说:“我肯定以后会需要这项额外的功能,所以现在就提前把它实现了吧” 。其实这是最考验功力的地方,不能闭门YY需要的功能,架构上又要洞察趋势 。)
原则3:爬,走,跑 。换句话说就是先保证跑通,然后再优化变得更好,然后继续优化让其变得伟大 。迭代着去做事情,敏捷开发的思路 。对于每个功能点,创建里程碑(最大两周),然后去迭代 。
(小编点评:快速反馈,一个“拍脑袋的里程碑”也好过没有里程碑...)
原则4:创建稳定、高质量的产品的唯一方法就是自动化测试 。所有的都可以自动化,当你设计时,不妨想想这一点 。
(小编点评:一切自动化也要考虑ROI,比如对于特别易变的页面层...)
原则5:时刻要想投入产出比(ROI) 。就是划得来不 。
原则6:了解你的用户,然后基于此来平衡你需要做哪些事情 。不要花了几个月时间做了一个devops用户界面,最后你发现那些人只喜欢命令行 。此原则是原则5的一个具体表现 。
原则7:设计和测试一个功能得尽可能的独立 。当你做设计时,应该想想这一条 。从长远来看这能给你解决很多问题,否则你的功能只能等待系统其他所有的功能都就绪了才能测试,这显然很不好 。有了这个原则,你的版本将会更加的顺畅 。
原则8:不要搞花哨的 。我们都喜欢高端炫酷的设计 。最后我们搞了很多功能和解决方案到我们的架构中,然后这些东西根本不会被用到 。
(小编点评:老板喜欢ppt?)
功能选择原则9:不可能预测到用户将会如何使用我们的产品 。所以要拥抱MVP(Minimal Viable Product),最小可运行版本 。这个观点主要思想就是你挑几个很少的使用场景,然后把它搞出来,然后发布上线让用户使用,然后基于体验和用户反馈再决定下一步要做什么 。
原则10:尽可能的做较少的功能 。当有疑问的时候,就不要去做,甚至干掉 。很多功能从来不会被使用 。最多留个扩展点就够了 。
(小编点评:产品经理可能是听不进去的,最好采取数据度量说话...)
原则11:等到有人提出再说(除非是影响核心流程,否则就等到需要的时候再去做) 。
原则12:有时候你要有勇气和客户说不 。这时候你需要找到一个更好的解决方案来去解决 。记住亨利福特曾经说过的 :”如果我问人们他们需要什么,他们会说我需要一匹速度更快的马” 。记住:你是那个专家,你要去引导和领导 。要去做正确的事情,而不是流行的事情 。最终用户会感谢你为他们提供了汽车 。
服务端设计和并发原则13:要知道一个server是如何运行的,从硬件到操作系统,直到编程语言 。优化IO调用的数量是你通往最好架构的首选之路 。
原则14:要了解Amdhal同步定律 。在线程之间共享可变数据会让你的程序变慢 。只在必要的时候才去使用并发的数据结构,只在必须使用同步(synchronization)的时候才去使用同步 。如果要用锁,也要确保尽可能少的时间去hold住锁 。如果要在加锁后做一些事情,要确保自己在锁内会做哪些事情 。
原则15:如果你的设计是一个无阻塞且事件驱动的架构,那么千万不要阻塞线程或者在这些线程中做一些IO操作,如果你做了,你的系统会慢的像骡子一样 。


推荐阅读