Apache 架构师总结的 30 条架构原则
本文作者叫 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)：不要去搞一些不需要的东西，需要的时候再搞吧。 点评 : 这一点我被 diss 过好几次，之前的时候，我总是臆想觉得某个功能以后可能会用到，然后就顺手把它实现了，实际到了后面并没用上，反而造成了代码冗余。 原则 3： 爬，走，跑。换句话说就是先保证跑通，然后再优化变得更好，然后继续优化让其变得伟大。迭代着去做事情，敏捷开发的思路。对于每个功能点，创建里程碑（最大两周），然后去迭代。 原则 4：创建稳定、高质量的产品的唯一方法就是自动化测试。所有的都可以自动化，当你设计时，不妨想想这一点。 点评：单侧还是很有必要的，但是没有一个恒定的标准说你应该怎么去做。 原则 5： 时刻要想投入产出比（ROI）。就是划得来不。 原则 6： 了解你的用户，然后基于此来平衡你需要做哪些事情。不要花了几个月时间做了一个 devops 用户界面，最后你发现那些人只喜欢命令行。此原则是原则 5 的一个具体表现。 点评:是否有站在用户的角度思考问题呢？是否是为了用新技术而用新技术？ 原则 7：设计和测试一个功能，尽可能的独立。当你做设计时，应该想想这一条。从长远来看这能给你解决很多问题，否则你的功能只能等待系统其他所有的功能都就绪了才能测试，这显然很不好。有了这个原则， 你的版本将会更加的顺畅。 […]