坏味道

代码坏味道解析

坏味道
是什么?
不好的编码习惯或思维导致所写的代码在清晰理解性、内存和效率、扩展性和维护性方面对整个项目的损坏和潜在的危害。
软件工程和建筑工程的共通点,代码坏味道好比建筑设计和材料的劣质对工程的影响,即不论是否存在坏味道都能完成工程实现,但最终成果的耐用性和易用性却大相径庭。

清晰理解性
一、过长的参数、方法、类

* 接口设计,如果参数过多(一般超过4个的时候),建议考虑使用封装成对象或数据结构。(接口设计低耦合)

          好处有二: 1. 参数添加的时候,不会导致依赖这个接口的调用方代码不可用 2. 代码看上去清爽

* 将长方法/类拆分、抽象出通用方法或类

二、重复代码

* 折叠条件判断:使用短路与、短路或
* 提取重复代码、功能成类的私有方法
* 重复的字段、方法可上拉到超类、extract类中

三、数据团
提取出来为数据类并封装相关数据的操作:eg枚举类
应用实例:

四、滥用==比较(针对包装类型和引用类型数据)
造成问题:易产生数据转换的麻烦,难理解
解决办法:

* 使用集合或对象自带的isEmpty()等比较方法

            反例:if(newAddressList.size() == 0)
           Assert.isFalse(commodityGoodsVoList == null || commodityGoodsVoList.size() == 0)

* 使用被覆写了的equals()方法---值比较,针对包装类型

        覆写了的类有:
           Number(Integer、Double等),Vector,Pair,List,HashMap,Collection,Enum,Set,Boolean,Date

* 使用各类工具包,如StringUtils.equals()-----引用类型数据

            避免空指针异常,并且会进行造型

五、空对象操作
造成问题:空指针异常
建议:使用java8 Optional 静态类
// Optional.ofNullable - 允许传递为 null 参数
Optional a = Optional.ofNullable(value1);
// Optional.of - 如果传递的参数是 null,抛出异常 NullPointerException
Optional b = Optional.of(value2);

// Optional.orElse - 如果值存在,返回它,否则返回默认值
//value不为null时返回value值,否则返回Illegal
Optional.ofNullable(value).orElse(“Illegal”);
optional.orElseThrow(() -> new IllegalArgumentException(“Illegal”));
Optional.ofNullable(value).orElseGet(() -> getDefaultValue());
map 是可能无限级联的, 比如再深一层, 获得用户名的大写形式
Optional user= Optional.ofNullable(user1);
return user.map(u -> u.getUsername())
.map(name -> name.toUpperCase())
.orElse(null);

六、单一方法、匿名方法

* 使用Lambada表达式(允许把函数作为一个方法的参数传递进方法中)免去使用匿名方法的麻烦,即简化了函数式编程

JAVA7实现:
MathOperation addition = new MathOperationImp(){
int operation(int a, int b){
return a+b;
}
};
Lambada实现:
MathOperation addition = (int a, int b) -> a + b;

内存、效率
一、基类偏执、包装类的创建
问题:易产生游离数据,耗费内存

*  解决方式:使用相应包装类的静态方法:Long.parse(String i)、Long.valueOf(String i)、Long.valueOf(int i)

二、使用for(int i=0;;)进行遍历
问题:i被单次使用,降低效率耗费存储
建议:(无需访问数组下标时)

* 使用Iterator遍历

        Iterator 支持从源集合中安全地删除对象

* 使用for each
* 使用Stream()---java8特性

   Stream处理方式类似管道过滤网,可进行筛选, 排序,聚合等操作,最后收集元素。
    使用:把一个集合先变成Stream,然后,通过filter()、map()、limit()、等实现Stream的变换。Stream还有一个forEach()来完成每个元素的迭代,使用collect()来收集元素。
      应用示例:

public List getPersonalizedPayMode(String sellerEntityId, String buyerSelfEntityId, Long orderAmount,Short billType) {
return payModeSelectedServiceList.stream().map(iPayModeSelectedService -> iPayModeSelectedService.select(sellerEntityId, buyerSelfEntityId,orderAmount,billType))
.filter(payClientVo -> payClientVo != null).collect(Collectors.toList());
}
*****它不是数据结构,是方法,只输出过滤后的元素,不会改变原有数据结构和数据
不支持索引访问;延迟计算特点,访问的时候才被计算出来。

    三、String的连加
            使用StringBuffer.append();
            *在初始数据较大的情况要先定义初始值以减少扩容次数
            *它是线程安全的

四、布尔值得返回
问题:游离数据

*  建议:使用Boolean.TURE返回

扩展性、维护性
一、解耦
接口设计低耦合、系统分层低耦合、模块之间的低耦合、模块内部的低耦合和高内聚 、类的方法设计
------------------------http://k.2dfire.net/pages/viewpage.action?pageId=220823924
分层解耦:MVC模式
二、继承
swtich语句可用继承来替换,保证易维护性
三、封装
eg:枚举类

### 代码味道概述 代码味道是指程序中存在的某些结构上的缺陷,这些问题虽然不会阻止程序运行,但却会降低其可读性、可维护性和扩展性。通过识别并消除这些味道,可以显著提升代码质量。 #### 味道类型及改进方式 1. **过长的方法** 过长的方法通常包含了过多的责任和复杂的逻辑,这会使方法难以理解和测试[^1]。 #### 改进方式 - 将大方法拆分为多个小方法,每个方法只负责单一职责。 - 使用提取函数(Extract Method)技术来分离出独立的功能模块。 ```python def process_data(data): cleaned_data = clean_data(data) # 提取清洁数据功能 analyzed_data = analyze_data(cleaned_data) # 提取分析数据功能 return format_results(analyzed_data) # 提取格式化结果功能 def clean_data(data): ... def analyze_data(data): ... def format_results(data): ... ``` 2. **霰弹式修改** 霰弹式修改发生在每次变更需求时都需要在多个类中进行大量小改动的情况[^3]。这种模式不仅增加了开发成本,还容易遗漏重要部分。 #### 改进方式 - 应用移动方法(Move Method)、内联临时变量(Inline Temp)等重构手段集中相关行为到单个位置处理。 - 考虑引入抽象基类或者接口统一管理共同的行为特性。 3. **发散式变化** 发散式变化指的是当面对特定类型的改变时,需要同时调整同一类中的多处地方[^2]。这种情况表明该类承担了太多不同方面的责任。 #### 改进方式 - 利用提炼类(Extract Class)把不相关的属性与操作移除出去形成新的子组件。 - 对于复杂的数据模型考虑采用DTO(Data Transfer Object),减少原始对象负担。 4. **重复代码** 如果发现相似片段反复出现,则意味着存在潜在共享机制未被充分利用的机会。 #### 解决方案 - 合并重复条件片段(Consolidate Conditional Expression) - 创建通用工具库供项目其他区域调用 5. **循环语句滥用** 循环往往带来性能瓶颈以及嵌套层次加深的问题。 #### 处理建议 - 替代迭代器或流表达式简化流程控制 ```java List<String> names = people.stream() .map(Person::getName) .collect(Collectors.toList()); ``` 6. **过度耦合** 类之间依赖关系过于紧密,任何一方变动都会影响另一方正常运作。 #### 缓解措施 - 实施依赖注入(Dependency Injection),使服务提供者和服务使用者相互隔离. - 推荐遵循开闭原则(Open/Closed Principle) 7. **缺乏清晰命名** 不恰当的名字会让读者困惑不解,无法快速把握意图. #### 补救办法 - 更改含糊不清的术语为更具描述性的词语 - 确保名称能够反映实际用途而非实现细节
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值