提高代码质量的几条参考建议

单元测试 什么是单元测试 ? 单元测试通常是指对一个函数或方法测试。单元测试的目的是验证每个单元的行为是否符合预期,并且在修改代码时能够快速检测到任何潜在的问题。通过编写测试用例,我们可以验证这些模块在特定输入下是否产生正确的输出。单元测试的目的是确保每个模块在各种情况下都能正常运行。 写单元测试的好处 可以带来以下几个好处: 提高代码质量:单元测试可以我们提前的发现代码中的潜在问题,例如边界条件、异常情况等,从而减少出错的概率。 提高代码可维护性:单元测试可以帮助开发人员理解代码的功能和实现细节,从而更容易维护和修改代码。 提高代码可靠性:修改代码后,可以通过单元测试可以帮助开发人员验证代码的正确性,从而提高代码的可靠性。 写单元测试是一种良好的软件开发实践,可以提高代码质量、可维护性和可靠性,同时也可以提高开发效率和支持持续集成和持续交付。 单元测试入门 上手单元测试,通常同时从静态测试(Static Test)开始,因为它简单,好理解,静态测试(Static Test)是指在编写测试用例时,我们提前定义好所有的测试方法和测试数据。这些测试方法和数据在编译时就已经确定,不会在运行时发生变化。Junit 中的静态测试通常的常规注解,如 @Test、@Before、@After 等。先来看看一组简单的静态测试示例。 首先,确保你的 pom.xml 文件包含 JUnit 的依赖: <dependencies> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <version>5.8.0</version> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.8.0</version> <scope>test</scope> </dependency> </dependencies> 然后,创建一个简单的计算器类,通常这里替换为你实际要测试的业务类: public class SimpleCalculator { public int add(int a, int b) { return a + b; } public int subtract(int a, int b) { return a - b; } } 然后在 /test 的相同目录下创建对应的测试类 import org.junit.jupiter.api.*; import static org.junit.jupiter.api.Assertions.assertEquals; public class SimpleCalculatorTest { // 在所有测试方法执行前,仅执行一次。这个方法需要是静态的。 @BeforeAll static void setup() { System.out.println("BeforeAll - 初始化共享资源,例如数据库连接"); } // 在所有测试方法执行后,仅执行一次。这个方法需要是静态的。 @AfterAll static void tearDown() { System.out.println("AfterAll - 清理共享资源,例如关闭数据库连接"); } // 在每个测试方法执行前,都会执行一次。用于设置测试方法所需的初始状态。 @BeforeEach void init() { System.out.println("BeforeEach - 初始化测试实例所需的数据"); } // 在每个测试方法执行后,都会执行一次。用于清理测试方法使用的资源。 @AfterEach void cleanup() { System.out.println("AfterEach - 清理测试实例所用到的资源"); } // 标注一个测试方法,用于测试某个功能。 @Test void testAddition() { System.out.println("Test - 测试加法功能"); SimpleCalculator calculator = new SimpleCalculator(); assertEquals(5, calculator.add(2, 3), "2 + 3 应该等于 5"); } // 再添加一个测试方法 @Test void testSubtraction() { System.out.println("Test - 测试减法功能"); SimpleCalculator calculator = new SimpleCalculator(); assertEquals(1, calculator.subtract(3, 2), "3 - 2 应该等于 1"); } } 以上程序,可以看到 Junit 常用注解使用说明: ...

April 25, 2023 · 4 min

从实践总结的几个 CodeReview 经验

资深的程序员都知道 Code Review 可以对代码质量,代码规范,团队代码能力提升带来很大的提升,还有著名的技术专家“左耳朵耗子”也说过: 我认为没有 Code Review 的公司都没有必要呆(因为不做 Code Review 的公司一定是不尊重技术的) 出自《程序员的练级攻略 - 修养篇》 国外很多技术公司都非常重视 Code Review 也都做的特别好,例如 Google,亚马逊,但是国内很多公司在践行 Code Review 的时候却是步履蹒跚,步步艰难,选用的方法不对,最终导致事倍功半的结果,总结一下我见过的几种情况: 因为 Code Review 导致团队成员之间相互指责,团队凝聚力产生间隙 Code Review 形式化,没有提升代码质量,减少 bug,反而降低开发效率 Code Review 确实产生了效果,但是因为流程太重,导致团队效率降低 我们也在践行 Code Review,探索的路上也遇到一些障碍和经验,总结分享一下,如果你也遇到这些问题,或许可以花一点时间读一读这篇文章,说不定会有帮助。 Code Review 能带来哪些好处,本文就不说了,大家都很熟悉了,本文主要简单说一下 Code Review 有哪几个基本的共识和原则: Code Review 高效的原则是用机器去做大部分的事情 Code Review 的时机(天时地利人和) 推行 Code Review 的关键原则 Code Review 高效的原则是用机器去做大部分的事情 不同的语言的格式和风格都是比较固定的,例如我最熟悉的 Java 语言常见的风格有以下几种规范: Order Java SE 的标准规范:https://www.oracle.com/technetwork/java/codeconvtoc-136057.html Google Java 开发规范: https://google.github.io/styleguide/javaguide.html 阿里巴巴 Java 开发手册:https://github.com/alibaba/p3c (国内常用) 还有我最近常用的 Ruby 语言,官方所推崇的几种风格规范: ...

August 25, 2020 · 1 min

技术管理者带团队的一些实践心得

前言 个人从程序员到技术 Leader 经历了不少的心路历程,我目前在带一支十几人的技术团队(控制团队人数主要是遵循亚马孙 CEO 贝索斯提出的两个披萨原则)我记得刚开始带团队的时候我是非常抗拒的,因为总觉得管理太多的“杂事”占用了我很多写代码的时间,包括目前虽然已经是一支十几人技术团队的 Leader,但是我平时也还是偏爱技术多一些,在业余时间都会抽空写写代码或者在 Leetcode 刷刷题,在从事管理工作这些时间里看过很多书,也踩过很多坑,总结了很多经验,想必也有很多程序员刚开始跌跌撞撞的走上技术 Leader 的岗位,所以想写一篇文章跟大家分享一下,希望可以帮助到需要的人,文章大纲如下: 技术管理者需要哪些综合能力? 如何才能在团队拥有 Leadership ? 从工程师到团队 Leader 有哪些转变 ? 如何提升技术团队的工作效能 ? 如何提升团队的凝聚力 ? 沟通的技巧 ? 管理者的自我认知和成长 技术管理者需要哪些综合能力? 如何才能在团队拥有 Leadership ? 既然说到管理技术团队,那么管理的对象自然就是程序员,那么程序员是一个什么样的群体?大多数程序员的特点是:“聪明且傲娇” 比如这个网上流传的段子,如何正确的向程序员提BUG: 技术 Leader 对个人综合素质要求很高(技术好的管理者,带技术团队是有一定优势的),先说说我认为技术 Leader 需要哪几个比较重要的综合能力 技术能力和基础知识(能看懂技术表象背后的原理) 沟通表达能力(逻辑,同理心,情绪控制) 业务抽象能力(架构和演化) 技术 Leader 必须要看透技术的本质,因为技术 Leader 平时的工作内容大多包含:技术选型,技术方案评审,代码审查,技术氛围的营造,如果管理者本身不是技术出身,可能无法和技术团队建立共识,沟通成本极高,最终让团队变成一个非常低效的组织,人浮于事,那么如何才能拥有这些能力,可以在技术团队拥有 LeaderShip ? 我个人总结有一下几点: 吃透基础技术和弄懂技术背后的原理(万丈高楼平地起,再流行的框架和技术,剥离华丽的外衣也离不开操作系统,网络,数据结构这些原理型的知识) 了解细节,永远在写代码(不熟悉代码就无法提出真正可落地的方案,就无法感知技术团队的痛点在哪里,也就无法团队提高效能) 持续的学习,持续的为团队带来新的知识和理解(技术 Leader 已经是团队技术问题的终结者,不可能再上传递了,所以不要成为技术团队的天花板) 有一个真心帮助大家的心态(帮助大家成长,提高效能,最终组织效能也得到提高,实现共赢的局面) 总结了以上经验和方法论之后,我们肯定会思考,上面所说的都只是过程和执行,那么管理者的目标或者说是工作的结果是以什么形式体现的? 总体概括来说的话,管理者的目标和工作结果主要体现在两方面: 做事:成本、效率、质量 带人:人才、梯队、成长 以上的方向又太抽象,其实管理者很多时间的大部分工作都在选择和权限,主要包含以下几个方面 有限资源的限定下,选择最大化的产出方案 做出符合当前环境的技术决策,帮助公司产品取得成功 用方法和工具不断优化和提升生产效率和质量 举一个实际的例子: 比如公司A在创业期,还没有稳定的市场和客户,这个时候技术管理者的决策要倾向成本 + 效率,例如:技术团队偏向全栈型,工作流偏敏捷,快速交付功能获取用户和市场的反馈用于升级和迭代产品 比如公司B在成熟期,有固定的市场和客户,行业已经没有新的蛋糕,这个时候需要比拼的就是效率 + 质量,技术团队偏向专家型,注重产品质量和客户体验用于形成行业口碑和用户粘性 从工程师到团队 Leader 有哪些转变 ? 其实工作变化还蛮大,所有很多人刚开始管理团队会出现很多的不适,我总结如下: ...

August 3, 2020 · 2 min