养成坏习惯真是分分钟的事儿，而养成好习惯却很难。

我发现，把那些对我有用的习惯写下来，能让我坚持住已经花心思养成的好习惯。

下面就是总结出来的十个能提高速度又保持质量的小技巧，顺序不分先后。

1、保持提交小而精

每次提交代码都要小到你觉得自己是不是有点“过分”了，这样做有个好处——万一出了问题，回滚时你就能精准找到问题的源头。

比如，六天前引入了一个 bug，只需要撤回那一次提交，而不用担心一大堆合并冲突。

我的经验法则是：代码编译通过，就可以提交。

例子： 提交时每次只做一个功能或者一个小的修复。

# 错误的做法：一次提交多个更改
git commit -m "修复登录逻辑、优化数据库查询、添加用户认证"

# 正确的做法：每次提交一个小的更改
git commit -m "修复登录逻辑"
git commit -m "优化数据库查询"
git commit -m "添加用户认证"

2、持续小规模重构

践行Kent Beck的“简化再改动”法则，他有句名言：为每个想要的更改，先让更改变得简单，然后再做简单的更改。

所以，尽量让一半的提交都是重构。持续重构的关键是找出那些十分钟内能改进的小地方。这样做的好处是，当有大的需求来了，你会发现自己只需要做个小改动就搞定了，而这要归功于之前的那些小改进。大规模的重构是个雷区，最好避免。

大规模的重构则通常是个坏主意。

例子： 将一个复杂的函数拆分成多个小函数，每次重构一部分。

# 错误的做法：复杂函数未拆分
def process_data(data):
    cleaned_data = clean_data(data)
    validated_data = validate_data(cleaned_data)
    processed_data = calculate_result(validated_data)
    return processed_data

# 正确的做法：每次小规模重构，将函数分解
def clean_data(data):
    # 清理数据逻辑
    pass

def validate_data(cleaned_data):
    # 验证数据逻辑
    pass

def calculate_result(validated_data):
    # 处理数据逻辑
    pass

def process_data(data):
    return calculate_result(validate_data(clean_data(data)))

3、未上线的代码是债务

所有代码都是一种负担，特别是那些未上线的代码。

如果没上线，我就不知道它是否能正常工作，或者会不会破坏其他东西。

测试能让我有信心，但只有上线才能得到真正的验证。

频繁部署虽然可能会增加一些托管费用，但这代价和进度停滞比起来简直是小巫见大巫。

敏捷原则之一就是“工作软件是衡量进度的首要标准”。

我自己给这句话定义了下：“工作”指的是能上线，“进度”是指代码在上线后带来了新的功能。

例子： 每次确保代码可以部署，并添加相应的自动化测试。

# 错误的做法：代码写完不测试，不上线
git commit -m "完成功能"  # 但没有部署

# 正确的做法：每次代码变更后部署到测试环境
# 使用 CI/CD 流程，自动化部署和测试
git commit -m "完成功能"
git push origin main

# CI 脚本触发自动测试和部署

4、别测试框架的功能

如果你在测试框架的功能，比如 useState() 这样的 Hook，停下别做了。

框架的功能已经被更懂行的人测试过了，你得信任他们。如果你的组件足够小，框架就能完成大部分工作，你也就不用写一堆测试代码。如果组件太大，就会引入复杂性，迫使你写更多的测试。

例子： 不测试 React 的 useState() 钩子，只测试业务逻辑。

// 错误的做法：测试框架内部实现
test('useState hook works', () => {
    const [count, setCount] = useState(0);
    expect(count).toBe(0);
});

// 正确的做法：测试业务逻辑
test('increments counter', () => {
    const { result } = renderHook(() => useCounter());
    act(() => {
        result.current.increment();
    });
    expect(result.current.count).toBe(1);
});

5、不知道函数该放哪？那就创建一个新模块吧

如果某个函数暂时找不到合适的归宿，那就直接新建一个模块（类或组件）吧，之后总会找到合适的地方。

如果实在找不到地方放，那它独立存在也没什么大不了的。

例子： 当一个函数不适合现有模块时，将它独立出来。

# 错误的做法：强行将不相关的逻辑放在一起
def user_utils(user):
    if user.is_active:
        return send_email(user)  # 发送邮件的逻辑不属于 user_utils

# 正确的做法：将发送邮件逻辑移到新的模块
def send_email(user):
    # 发送邮件逻辑
    pass

6、先写测试再写 API

如果不确定 API 应该是什么样子，那就先写测试。

这样你会从“使用者”的角度去思考，发现那些自己不写测试就容易忽略的边缘情况。

虽然不需要死守 TDD（测试驱动开发），你也可以写多一点代码再让它通过，但写测试先行有助于明确思路。

例子： 先编写测试用例，再根据测试结果设计 API。

# 测试用例
def test_get_user():
    response = client.get("/users/1")
    assert response.status_code == 200
    assert response.json() == {"id": 1, "name": "John"}

# 根据测试设计 API
@app.route("/users/<int:user_id>")
def get_user(user_id):
    user = get_user_from_db(user_id)
    return jsonify({"id": user.id, "name": user.name})

7、复制粘贴可以，但别超过一次

第一次复制粘贴是可以接受的，但第二次（即出现第三个副本）就该停下来，开始考虑如何抽象出复用的部分。

多次实现几乎相同的功能很容易导致代码发散，而稍微有点“丑陋”的参数化也总比一堆重复代码要好。

下一次再遇到类似情况，改进参数比合并多个实现要容易得多。

例子： 当有多次重复时，创建抽象函数。

# 错误的做法：多次复制粘贴
def calculate_discount(price):
    return price * 0.9

def calculate_premium(price):
    return price * 1.1

# 正确的做法：创建一个通用的计算函数
def calculate_price(price, multiplier):
    return price * multiplier

8、设计总会过时

重构可以延缓过时的速度，但终究有一天你得改变设计。

不要对过去自己觉得很棒的设计感到难过，当时做的是对的，不代表现在不会有更好的方法。

写代码的过程，其实就是不断改变代码。

接受它，前进。不存在完美的设计，开发的核心是变化，适应变化的能力决定了你开发的能力。

例子： 重新设计结构，尽管旧的设计曾经有效。

// 旧的设计
function fetchUserData() {
    fetch('/api/user').then(response => response.json()).then(data => {
        console.log(data);
    });
}

// 新的设计（使用 async/await）
async function fetchUserData() {
    const response = await fetch('/api/user');
    const data = await response.json();
    console.log(data);
}

9、技术债务有三种类型

技术债可以分为三类：

1、阻碍你现在做事情的；

2、未来可能会阻碍你做事情的；

3、以后可能会成为阻碍但现在不重要的。

尽量减少第一种，关注第二种，忽略第三种。

任何其他形式的技术债都可以归结为这三类。

10、可测试性是好设计的标志

如果代码不容易测试，那可能设计出了问题。有时问题出在测试设计上。

比如，如果你发现很难 mock 数据库查询（比如 em.getRepository(User).findOneOrFail({id})），那可能需要把这个调用提取到一个独立的函数中，方便 mock，或者创建一个测试工具来简化对实体管理器方法的 mock。

写测试的难度越大，越容易让人放弃测试。

例子： 当代码难以测试时，重新设计以提高可测试性。

原始代码（难以测试）：

// 错误的做法：难以测试，因为数据库调用嵌入在逻辑中
class UserService {
  constructor(private em: EntityManager) {}

  async getUser(id: number): Promise<User> {
    // 直接使用实体管理器进行数据库查询
    const user = await this.em.getRepository(User).findOneOrFail({ id });
    if (!user) {
      throw new Error('User not found');
    }
    return user;
  }
}

改进后的代码（提高可测试性）：

// 正确的做法：将数据库调用抽象成独立函数，便于 mock
class UserService {
  constructor(private userRepository: UserRepository) {} // 注入一个独立的存储库服务

  async getUser(id: number): Promise<User> {
    // 将查询逻辑放到独立的仓库类中
    const user = await this.userRepository.findUserById(id);
    if (!user) {
      throw new Error('User not found');
    }
    return user;
  }
}

// 创建一个独立的 UserRepository 类
class UserRepository {
  constructor(private em: EntityManager) {}

  async findUserById(id: number): Promise<User | null> {
    return this.em.getRepository(User).findOne({ id });
  }
}

测试代码：

import { UserService } from './UserService';
import { UserRepository } from './UserRepository';

describe('UserService', () => {
  let userService: UserService;
  let userRepository: UserRepository;

  beforeEach(() => {
    // 创建一个 mock 的 UserRepository
    userRepository = {
      findUserById: jest.fn()
    } as any;
    userService = new UserService(userRepository);
  });

  it('should return user when user is found', async () => {
    const mockUser = { id: 1, name: 'John' };
    (userRepository.findUserById as jest.Mock).mockResolvedValue(mockUser);

    const result = await userService.getUser(1);
    expect(result).toEqual(mockUser);
  });

  it('should throw an error when user is not found', async () => {
    (userRepository.findUserById as jest.Mock).mockResolvedValue(null);

    await expect(userService.getUser(1)).rejects.toThrow('User not found');
  });
});

改进后的优点：

1. 更容易测试：通过将数据库逻辑抽象到UserRepository中，UserService的测试变得更加简单。你只需要mock UserRepository，不再需要直接处理数据库实体管理器。
2. 职责分离：查询逻辑与业务逻辑分离，使代码结构更清晰，符合单一职责原则。
3. 灵活性：未来如果数据库实现发生变化，你只需修改UserRepository，不影响 UserService，增强了代码的可维护性。

这种重构使得代码不仅可测试性提高，也使代码更加模块化、清晰易懂。

参考：https://zarar.dev/good-software-development-habits/