如何提升代码可读性?阿里发布16条设计规约

脍炙人口的唐诗“两个黄鹂鸣翠柳，一行白鹭上青天”，清爽直接，简明易懂。可读性好的代码也是让人陶醉的，那么如何写出可读性的代码？

近期，《阿里巴巴Java开发手册》推出详尽版，新增16条设计规约，让优雅的代码触手可及。下面让我们一起来了解。

长按识别以下二维码，关注“阿里技术”官方公众号，回复“手册”，即可免费在线阅读、或下载此书。

▲70万工程师关注的阿里技术公众号

为何要新增设计规约？

代码的可读性是指代码让人容易阅读、理解、调试、可预料的程度。提高代码的可读性可以为代码阅读者节约时间和精力，提升团队协作效率。熟悉和遵守《阿里巴巴JAVA开发手册》的编程风格，那只是“标”，而代码可读性的“本”可以追溯到软件设计阶段。试想一下如果发型师没有设计好，不用指望能剪出一个“可读性”比较好的你。

设计是一种梦想和追求，谁都喜欢有气质的女神，谁都会欣赏有设计感的代码。你可能会问，什么是设计感？就像烧饭这件事，村姑和御厨都会烧，都能吃饱，但是菜品的美感、口感，有本质的区别。代码到艺术层面上，能够体现出来非常好的扩展性、解耦性。代码就象积木一样，灵活搭建，结构清晰，不用担心拔出萝卜带出泥。

何为16条？

万事万物皆有法则，这种理论层面的抽象来自于实践，同时理论指导下的实践又不断地修正或夯实理论。软件设计有七大基础原则，分别是：单一原则、开闭原则、里氏代换原则、组合复用原则、接口隔离原则、 依赖倒置原则、迪米特原则，这些原则指导着实际代码生产中的模块、类、方法的实现。

设计规约是根据阿里巴巴实际项目架构经验提炼而成，共16条。设计规约主要从UML图和架构设计原则来规定比较基础的软件设计理念，并且明确了超过什么样的阈值需要以什么样的方式来呈现设计思维。根据阿里巴巴内部的反馈声音来看，对于数据底层结构、状态图、以及敏捷开发相关的三条，共鸣感最强，那么详细点评一下：

数据底层结构

底层数据结构属于大厦的地基工程，如果地基不稳，那么上层去修正难度是相当大的，甚至是无法修正。所以设计规约提倡，存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。有缺陷的底层数据结构容易导致系统风险高，可扩展性差，重构成本因历史数据迁移、系统平滑过渡也会陡然增加，所以，存储方案和数据结构需要认真地进行设计和评审，生产环境提交执行后，需要进行double check。

评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发展、表或字段之间的辩证关系、字段名称、字段类型、索引等；数据结构变更（如在原有表中新增字段）也需要进行评审通过后上线。

状态图

业务对象状态相关的编码错误是引起线上故障的一个重要导火索。多一个状态，少一个状态，如果没有历史设计文档沉淀，那么都是灾难性的。如果某个业务对象的状态超过3个，使用状态图来表达并且明确状态变化的各个触发条件。

状态图的核心是对象状态，首先明确对象有多少种状态，然后明确两两状态之间是否存在直接转换关系，再明确触发状态转换的条件是什么。淘宝订单状态有已下单、待付款、已付款、待发货、已发货、已收货等。比如已下单与已收货这两种状态之间是不可能有直接转换关系的。

敏捷开发

敏捷开发是当下流行的一种开发模式，相比传统软件生产流程，更加快速地交付，短平快上线，占领前沿市场。但是，敏捷开发仅适合于信任度好、理解力强、技术水平相对一致的创业型团队。但目前在很多公司，敏捷成为一个抓进度的拔苗助长式的借口，导致交付质量很差，开发同学幸福感低，用户黏性差的现象，所以避免如下误解：敏捷开发 = 讲故事 + 编码 + 发布。敏捷开发是快速交付迭代可用的系统，省略多余的设计方案，摒弃传统的审批流程，但核心关键点上的必要设计和文档沉淀是需要的。

写在最后

我们相信技术之心生生不息，也相信好的规约值得被传播和应用。本次新增的不单是16条新的设计规约，还是阿里技术人的情怀与追求。我们也期待大家的意见，持续完善《阿里巴巴Java开发手册》。

最后，欢迎在留言区评论，说说你眼里的软件设计之坑，比如那些年或仓促上马，或粗制滥造的设计导致编码阶段磕磕绊绊的经历，帮助后来者避免陷坑。

我们会筛选最具价值的评论，各送出一本《阿里巴巴Java开发手册》实体书（共计5本）。

截止时间：即日起至7月17日

每天一篇技术文章，

看不过瘾？

关注“阿里巴巴机器智能”，

发现更多AI干货。

 ↑ 翘首以盼等你关注

你可能还喜欢

点击下方图片即可阅读