从菜鸟到大师：编程必须遵循的三个基本原则-Toy模板网

这篇具有很好参考价值的文章主要介绍了从菜鸟到大师：编程必须遵循的三个基本原则。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

任斗转星移，原则恒定

在软件开发的世界里，虽然技术日新月异，但有些原则是经久不衰的。就像建房子需要坚实的地基，软件开发也有其基础原则。它们像是指南针，帮助开发者在变化莫测的技术海洋中保持方向。接下来，我们就来聊聊这三个基本原则：DRY、KISS和YAGNI。

DRY —— 重复是编程之敌

1.1 概念：Don't Repeat Yourself

想象一下，你你在家自己做土豆丝夹饼，如果你家有三口人需要做三个，你不会每次都重新和面、烤饼、切土豆丝，调配同样的调料吧？这不仅效率低下，而且很难保证味道一致。你会一次性准备好所有的面饼，然后一次性切好所有的土豆丝，预先调制好所有的调料，这样更高效。这就是DRY原则的精髓——不要做重复的事情。

从菜鸟到大师：编程必须遵循的三个基本原则

1.2 为何要DRY？

通过将重复的逻辑提取出来，形成独立的模块或函数，我们的代码变得更加整洁、易于管理。这就像我们制作每一个土豆丝夹饼时，因为已经提前做好了准备，只需要从烤箱中把饼拿出来，从菜盆中夹出土豆丝，从调料盒中挖出调料，而不是每次从和面烤饼开始。这样的组织让做饭过程更加高效和一致。

1.3 遇到的挑战

技术人员对业务理解不够深入，难以在恰当的时机做出合适的抽象，就像是一个大厨对如何高效准备土豆丝夹饼的材料不熟悉，不知道何时应该提前准备。
在紧迫的deadline前，临时的业务变更可能导致我们做出临时妥协，这就像是客人临时要求变更土豆丝夹饼的配料，而厨师只能急中生智，可能会牺牲味道。

1.4 代码示例

public class Calculator {

    // DRY - 将加法逻辑提取到一个方法中，避免在多处重复
    public int add(int a, int b) {
        return a + b;
    }

    // 其他操作也应该遵循DRY原则
    public int subtract(int a, int b) {
        return a - b;
    }
}

KISS —— 保持简单的艺术

2.1 概念：Keep It Simple, Stupid

让我们继续用美食做比喻。如果你的土豆丝夹饼食谱需要30种配料，而实际上只需要3种就能做出美味的饼，那这个食谱显然过于复杂了。KISS原则告诉我们，保持简单直接非常重要。

从菜鸟到大师：编程必须遵循的三个基本原则

2.2 简单的力量

一个简单的设计意味着更少的错误，更容易的维护，就像简单的食谱更容易掌握，结果也更加可靠。

2.3 遇到的挑战

当项目涉及多方面的参与人员时，每个人都可能带来自己的关注点，这时候很容易忽视了用户的核心需求，就像厨师忙于展示烹饪技巧而忘记了食物是用来吃的。
受限于过去的决策，我们可能会一直在现有的基础上打补丁，最终导致系统复杂难以维护，就像一个本来简单的土豆丝夹饼因为不断添加配料变得复杂而难以下咽。

2.4 代码示例

public class SimpleTask {
    
    // KISS - 使用简单直接的方法来计算两个整数的和
    public int add(int a, int b) {
        return a + b;
    }

    // 这个方法违反了KISS原则，因为它过于复杂
    public int add(int a, int b) {
        // 使用一个数组来存储参数
        int[] numbers = new int[2];
        numbers[0] = a;
        numbers[1] = b;
        
        // 使用流来计算和，这在这种情况下是不必要的复杂性
        return Arrays.stream(numbers).reduce(0, (subtotal, element) -> subtotal + element);
    }
}

YAGNI —— 未雨绸缪还是过度设计？

3.1 概念：You Ain't Gonna Need It

如果你只是做几个土豆丝夹饼，你不会去买一个和面机吧？除非你打算经常自制烧饼，否则这显然是不必要的。这就是YAGNI原则的核心——不要添加当前不需要的功能。

从菜鸟到大师：编程必须遵循的三个基本原则

3.2 实践YAGNI的智慧

YAGNI原则鼓励我们专注于当前的需求，而不是过度设计未来可能也可能不会用到的功能。这就像是在购物时，只买你当天晚餐需要的材料，而不是囤积一大堆可能永远不会用到的食材。

3.3 遇到的挑战

技术人员有时会被新技术吸引，就像看到新出的厨具就想买来试试，即使它们对于目前的需求并不必要。
我们对未来的预测往往不准确，过度设计的功能可能最终成为累赘，就像买了太多食材最终导致浪费。

3.4 代码示例

public class UserService {

    // 当前只需一个方法来添加用户
    public int add(String userName,int age) {
        ...
    }

    // 不要预先添加额外的方法，例如删除用户，除非有明确的当前需求
    // public double delete(int userId) {
    //     ...
    // }
}