阿里妹导读
代码整洁是软件长期稳定和可扩展的基础,本文作者从现实中的代码、重构、设计模式谈论代码整洁之道,总结出如何做一个有思想的程序员。
软件开发是一个需要团队协作、长期维护的过程,代码整洁是软件长期稳定和可扩展的基础。整洁的代码具备清晰的代码结构和规范的命名,具有良好的可读性和可维护性,便于快速定位和修复问题,有利于新功能的快速迭代。
团队成员也可以更高效地协作,减少沟通成本,整体提高项目的研发效率。
首先我们可以来看下C++之父Bjarne Stroustrup对于好代码的定义。
我喜欢我的代码优雅且高效。 逻辑应该简单明了,这样 bug 就很难隐藏;依赖关系最小化,以便于维护;错误处理应该根据明确的策略完成;性能应该接近最佳,以免诱使人们通过无原则的优化使代码变得混乱。干净的代码可以很好地完成一件事。
总体来说,优雅的代码具备如下特点:
圈复杂度(Cyclomatic Complexity)是一种代码复杂度的度量指标,用于衡量代码中的控制流路径的数量和复杂程度。它通过统计代码中的决策点(如条件语句和循环语句)来计算。圈复杂度的值可以用于判断代码的复杂程度和测试的覆盖范围。较高的圈复杂度表示代码中存在更多的路径和可能的执行情况,增加了理解、维护和测试代码的难度。
iLogtail 作为一款阿里云日志服务(SLS)团队自研的可观测数据采集器,目前已经在 Github 开源,其核心定位是帮助开发者构建统一的数据采集层。不仅仅是在功能、性能上表现突出,代码层面也一直在追求整洁优雅,详见《跟着iLogtail学习设计模式》。
iLogtail部分关键模块代码,代码行数跟圈复杂度基本是控制在比较合理的范畴。
但是也存在少数代码,整体复杂度已经到了极度复杂的程度,严重影响了代码的可扩展性。例如,下图两个函数,563行代码/169圈复杂度 代码[1], 332行代码/71圈复杂度 代码[2]。
备注:以上圈复杂度基于 VSCode 插件 Codalyze [3]获取。
综上我们可以看出,对于一些简单的代码往往是比较容易控制好结构的;但是拥有着比较复杂的业务逻辑的代码,往往会不是那么优雅,而且随着时间的推移,复杂度会变得越来越高。为什么造成这种局面?主要有以下几个原因:
接下来,我们结合实战手段介绍如何合理地利用重构跟设计模式两种手段避免代码腐化的问题。
重构实际上是对代码的一种调整,目的是在不改变软件可观察行为的前提下,提升代码的扩展性和可理解性,降低维护成本。
就像破窗效应中提到的一样,干净优雅的代码会让开发者心生敬畏;而一旦代码中出现了一些小的问题或坏味道,如果不及时修复,日积月累最终将会导致代码的腐化。因此,为了保证代码的质量,首先需要对代码中的坏味道有敏锐的识别能力。常见的坏味道:
///////////////////// 原始代码 /////////////////////
void printOwing() {
Enumeration e = _orders.elements();
double outstanding = 0.0;
// print banner
System.out.println("***************************");
System.out.println("******** Custor Owes ******");
System.out.println("***************************");
// calculate outstanding
while (e.hasMoreElements()) {
Order each = (Order) e.nextElement();
outstanding += each.getAmount();
}
// print details
System.out.println("name:" + _name);
System.out.println("amount" + outstanding);
}
///////////////////// 重构后 /////////////////////
void printBanner() {
System.out.println("***************************");
System.out.println("******** Custor Owes ******");
System.out.println("***************************");
}
void printDetails(double outstanding) {
System.out.println("name:" + _name);
System.out.println("amount" + outstanding);
}
double getOutstanding() {
Enumeration e = _orders.elements();
double outstanding = 0.0;
while (e.hasMoreElements()) {
Order each = (Order) e.nextElement();
outstanding += each.getAmount();
}
return outstanding;
}
void printOwing() {
printBanner();
double outstanding = getOutstanding();
printDetails(outstanding);
}
///////////////// 重构前 /////////////////
// 1
public User getUser(String username, String telephone, String email);
// 2
public void postBlog(String title, String summary, String keywords, String content, String category, long authorId);
///////////////// 重构后 /////////////////
// 考虑函数是否职责单一,是否能通过拆分成多个函数的方式来减少参数。
public User getUserByUsername(String username);
public User getUserByTelephone(String telephone);
public User getUserByEmail(String email);
// 将函数的参数封装成对象
public class Blog {
private String title;
private String summary;
private String keywords;
private Strint content;
private String category;
private long authorId;
}
public void postBlog(Blog blog);
///////////////// 重构前 /////////////////
if (date.after(SUMMER_START) && date.before(SUMMER_END)) {
// ...
} else {
// ...
}
///////////////// 重构后 /////////////////
// 引入解释性变量后逻辑更加清晰
boolean isSummer = date.after(SUMMER_START)&&date.before(SUMMER_END);
if (isSummer) {
// ...
} else {
// ...
}
// 重构前的代码
public List<String> matchStrings(List<String> strList,String substr) {
List<String> matchedStrings = new ArrayList<>();
if (strList != null && substr != null) {
for (String str : strList) {
if (str != null) {
if (str.contains(substr)) {
matchedStrings.add(str);
}
}
}
}
return matchedStrings;
}
// 重构后的代码:先执行判空逻辑,再执行正常逻辑
public List<String> matchStrings(List<String> strList,String substr) {
if (strList == null || substr == null) { //先判空
return Collections.emptyList();
}
List<String> matchedStrings = new ArrayList<>();
for (String str : strList) {
if (str != null && str.contains(substr)) {
matchedStrings.add(str);
}
}
return matchedStrings;
}
微重构
模块级重构
面对复杂臃肿的老代码,开发者往往心生畏惧。但是只要秉承如下原则,重构也不再可怕。- 重构前需要对整体有清晰的认识:架构设计梳理、模块间交互、周边交互。进而指导后续的重构过程。
最后,牢记细致认真是代码重构最重要的素养。设计模式
众所周知,程序员往往自嘲为码农。但是我认为码农跟程序员还是有本质区别的,这个区别就是抽象思维。码农只会CRUD,单点解决问题,导致只能埋头苦干;而程序员可以通过抽象思维解决,进行产品跟技术实现的归纳总结,一次解决更多通用需求。而软件技术本质上也是一门抽象的艺术。抽象思维是程序员最重要的思维能力,抽象的过程就是寻找共性、归纳总结、综合分析,提炼出相关概念的过程。
而设计模式是软件开发中抽象化思维的重要经验总结。总体上可以分为三类:
在《跟着iLogtail学习设计模式》一文中,深入阐述了多种设计模式的应用实践,这里不再一一介绍,而是从几个场景问题触发,探讨如何解决。
相信大家都见过如下代码,将处理逻辑的定义、创建、使用直接耦合在一起,代码特别冗长。
public class OrderService {
public double discount(Order order) {
double discount = 0.0;
OrderType type = order.getType();
if (type.equals(OrderType.NORMAL)) { // 普通订单
//...省略折扣计算算法代码
} else if (type.equals(OrderType.GROUPON)) { // 团购订单
//...省略折扣计算算法代码
} else if (type.equals(OrderType.PROMOTION)) { // 促销订单
//...省略折扣计算算法代码
}
return discount;
}
}
使用策略模式避免冗长的if-else/switch分支:将不同类型订单的打折策略设计成策略类,并由工厂类来负责创建策略对象。
// 定义策略接口
public interface DiscountStrategy {
double calDiscount(Order order);
}
// 具体策略实现
// 省略NormalDiscountStrategy、GrouponDiscountStrategy、PromotionDiscountStrategy类代码...
// 建立策略工厂
public class DiscountStrategyFactory {
private static final Map<OrderType, DiscountStrategy> strategies = new HashMap<>();
static {
strategies.put(OrderType.NORMAL, new NormalDiscountStrategy());
strategies.put(OrderType.GROUPON, new GrouponDiscountStrategy());
strategies.put(OrderType.PROMOTION, new PromotionDiscountStrategy());
}
public static DiscountStrategy getDiscountStrategy(OrderType type) {
return strategies.get(type);
}
}
// 策略的使用
public class OrderService {
public double discount(Order order) {
OrderType type = order.getType();
DiscountStrategy discountStrategy = DiscountStrategyFactory.getDiscountStrategy(type);
return discountStrategy.calDiscount(order);
}
}
假如有一个几何形状Shape类, 扩展出两个子类: 圆形Circle和 方形Square 。 现在需要引入颜色的因素,该如何实现?
桥接模式可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构, 从而能在开发时分别使用。一个类存在两个(或多个)独立变化的维度,可以通过组合的方式,让这两个(或多个)维度可以独立进行扩展。
适配器模式将一种类型的接口转换成希望的另一类接口,使得原本接口不兼容对象能够一起配合工作。适配器接受客户端通过适配器接口发起的调用, 并将其转换为适用于被封装服务对象的调用。
我们的系统当中,往往会依赖各种各样的外部系统,合理地利用适配器模式可以达到如下效果:- 外部系统的可替代性:当需要把项目中依赖的一个外部系统替换为另一个外部系统的时候(例如日志系统从Elasticsearch切换到SLS),利用适配器模式可以减少对代码的改动及测试复杂度。
Copyright© 2013-2019