结合本身经历聊聊注重实效的程序员应该掌握的几个原则

本篇文章是《程序员修炼之道》第二章的笔记，总结了高效程序员须要遵照的一些原则和经常使用的开发模式，对咱们有很是重要的指导意义。建议每一个程序员都应该学习并掌握这些原则。若是你们以为这个系列文章有价值，咱们能够组织一次抽书的活动，鼓励你们从原文学习。

DRY 原则

软件开发过程无时无刻都伴随着维护，若是项目中有大量的重复代码会对咱们的维护工做形成很大的麻烦。好比：一段代码在多个地方出现， 一旦要修改就须要咱们同时修改多个地方，若是某个地方忘记修改就可能致使一些没必要要的错误。所以做者提出 DRY原则 - Don't repeat yourself（不要重复你本身）。

咱们平时有很多重复的场景， 同时也有避免重复的解决方法，下面举几个例子。

• 代码与注释：咱们常常被说教要在代码里加注释。但注释并非越多越好，咱们应该把注释留给高级的说明，对于比较低级的说明用代码代替注释便可。不然，就存在重复的知识，每次修改代码都要想着修改注释
• 代码与文档：文档的更新是永远滞后于代码的，常常更新了代码但忘记更新文档。咱们能够采用一些辅助技术或者自研的技术，好比：API doc、Java doc 之类的工具，代码更新后，文档会随着更新
• 设计中的重复：假设某个类中有个起始坐标和结束坐标两个属性，这时再加一个两点间距离的属性就有点重复了，由于咱们能够根据起止点计算出距离
• 临时性的重复：有时候咱们临时作一些需求可能用到了项目中某段代码，咱们通常会直接复制过来用，这时候也存在重复。更完全的作法是咱们能够把一些比较经常使用的计算逻辑抽象成接口，造成本身的工具包，须要的时候直接引用便可，无需拷贝代码。好比：一些常见的求和，求最值等须要 for 循环的处理逻辑是否是能够抽象一个 reduce 函数
• 开发者之间的重复：这个是比较常见的重复，若是一个项目的两个组同时开发很容易形成同一个小的逻辑在两个组的成员有各自的实现，这种重复不太好避免。但咱们能够增长团队之间的交流，能够组织一个平台，把一些比较好的组件开放出来。我作数据开发时常常会用到一些 udf 处理数据，若是我当前项目中没有，我会到公司的公共平台去搜相应的关键词， 通常都能找到现成的 udf。我比较建议团队内部开源不一样的项目代码，固然是不涉及机密代码的前提。我在开发中常常会问上游同窗数据怎么处理的，通过了什么逻辑，这样作一方面增长沟通成本，二来毕竟耳听为虚。因此我就常常反编译上游的代码，之后须要看逻辑不须要问别人，直接看代码节省很是多的时间。固然开源也有个好处是咱们能够学习别人代码中优秀的地方。

正交原则

正交性就是不相互依赖性或者解耦性。若是两个或多个事物中的一个发生变化，不会影响其余事物，那么这些事物就是正交的。对应到编程，就是咱们常说的高内聚、低耦合。正交的系统好处很是多，正交的系统能够下降风险，当系统中某个组件修改时，只要对外的接口保持不变，该组件就能够任意修改而整个系统不会受到影响。正交的系统能提升生产率，由于系统组件是解耦的，所以各个组件能够独立地、并行地进行开发。好比最近几年比较火的先后端分离技术就是很好的表明，之前后端的同窗常常须要写一些套页面的前端代码，先后端同窗的代码交织在一块儿相互依赖。但先后端分离后，只须要把协议肯定好，先后端技术就能够解耦，开发同窗就能够并行开发，提升生产率。下面列举几种维持正交性的方法

• 设计：设计系统时咱们能够采用基于组件的分层架构。每层提供一级抽象，每层只是用其下面的层次提供的抽象，层与层之间的协议/接口稳定且可扩展，下层组件的改动对上层透明
• 编码：为了让代码保持解构，咱们能够开发 “羞怯” 的代码，对于不须要开放出来的逻辑，能够控制其访问权限，不被其余组件引用。避免使用全局数据，全局数据涉及多个使用方同时更新，致使组件耦合度较高。避免编写类似的函数，类似的函数每每有重复的代码，使得修改代码要同时更新多处
• 测试：在进行单元测试时，若是某个单元牵扯系统其他很大一部分，说明该单元与系统其余部分耦合度较大，须要引发开发同窗的重视

可撤销原则

可撤销原则是说，当系统中某个部分须要改变时，咱们能不能很好的撤销已有的代码，灵活的适应新变化。由于需求无时无刻都在变化，所以可撤销性就一直存在。举个栗子：假设咱们开发一个数据库可视化软件，最开始的需求是基于 Mysql 的，若是咱们不作分层设计，凡是须要增删改查的地方咱们直接写 JDBC 代码。可是某一天咱们底层数据要支持 MongoDB 怎么办，由于咱们的 JDBC 代码分布在项目的各个模块的代码中，几乎没法撤销，这时候系统只能重写。若是咱们设计之初将数据访问层做为一个组件抽象出来，那么上层只须要调用抽象出来的接口来操做数据库。这样作的好处是当须要支持其余数据库时，只须要为该数据库编写支持咱们抽象接口的数据库访问代码便可，所以系统就具有可撤销性的。其实，咱们在 Web 项目中常用 ORM 框架也是基于可撤销原则的，ORM 能够将数据库表映射成对象，底层的增删改查对上层透明，因此能够灵活地调整底层数据库。

曳光弹与原型

在黑暗中须要打击军事目标时一般会使用曳光弹，它在枪与击中的地方之间留下一条烟火般的踪影，用来指示弹道和目标，从而协助射手修正弹道。其实，黑暗中的目标就像咱们开发中面对的未知系统。面对未知系统，若是咱们制做大量文档，逐一列出每项需求，尝试肯定全部未知因素，就犹如在黑夜中对目标未知预先进行大量计算而后射击，很显然这种状况须要消耗大量计算力而且不必定能击中目标。而注重实效的程序员每每更喜欢使用曳光弹。曳光弹的核心优点就是反馈是及时的。好比：咱们要开发一个支持多种序列化格式的 RPC 框架，最开始咱们是否是能够先用简单的系统默认的序列化方式先将整个系统框架搭建起来，先让系统可以运行起来。运行后咱们能够及时地获得使用方的反馈，修复已有问题、增长多种序列化框架、不断迭代完善。

介绍完了曳光弹再来讲说原型，记得在大学学习《软件工程》时就接触了原型开发。原型更像是一个 Demo，不注重代码的实现，而是可以快速出一个可以与产品肯定需求的东西。好比：咱们须要肯定某个系统的 UI 需求，咱们能够用最快的开发语言，开发出一个 Demo，它的代码不须要规范，交互界面也不须要太美观，由于原型大几率不会在后续实际的项目实现中使用。

接下来简单总结一下这两种开发模式的区别。曳光弹强调的是明确需求后，咱们能不能开发出一个麻雀虽小、但五脏俱全的系统来快速得到反馈，从而指导咱们进一步迭代。在曳光弹开发模式下，后续代码是依赖于初版的代码。而原型开发更侧重明确需求这个阶段，快速开发一个 Demo ，目的是为了可以基于原型肯定系统的需求。这个阶段不在意用什么代码、不在意系统的完整性、健壮性以及正确性，由于原型代码基本不会用在真实的系统开发中。

领域语言与估算

这节内容我以为平时应用很少，理解的不深入，所以就简单总结。领域语言个人理解就是使用（创造）一门规范的伪代码，为何是伪代码呢？假设咱们与产品沟通需求，咱们可使用文字，但咱们都知道中华文字博大精深，别人表达的意思跟咱们的理解可能不一致，不然的话咱们也不须要这么苦逼的加班，固然直接用编程语言沟通更不可行。那么就须要一个中间层的伪代码，既能清晰的表达出需求，又能让产品或者使用不一样编程语言的程序员都能看懂。

对于估算这一节，做者介绍了一些常见的预估问题（估算项目时间、流量）的一些指导性意见，但感受比较偏理论，实操性不强。但给我印象最深的一句话是：

在咖啡机旁给出的估算将像咖啡同样回来纠缠你。

也就是说估算不等于不假思索的回答，咱们能够用 “这个问题我如今答复不了，我回去想下” 之类的话术先应付一下，后续再详细地思考。

小结

本章主要介绍了三个原则中，这三个原则若是在开发中加以总结和利用将对咱们高效地开发很是有帮助。DRY 原则避免重复劳动，正交原则避免改动一个组件时牵扯整个系统的维护，可撤销原则避免更换系统某个组件时致使系统崩溃。最后，介绍了曳光弹和原型开发两种快速开发模式，尤为是曳光弹，我比较喜欢用，先小规模、小成本搭建骨架并跑起来，后续再不断地丰富骨肉，但愿以上介绍的内容对你往后开发有帮助。

欢迎关注公众号「渡码」，我将分享更多优秀书籍的内容，组织按期抽书活动