如果我们给你半个故事来继续它，你会怎么做？你将如何进一步进行并在那里添加你的故事情节？
首先，你需要了解完整的故事，你会搜索所有的字符，他们在不同章节或部分故事中的字符，你需要把哪些角色带到最后或者哪些角色只有几章，你还需要了解故事的不同部分是如何联系在一起的，以告诉您故事中到底发生了什么。
编程就像讲一个故事一个老乡程序员，其中变量是字符在你的故事，一些扮演自己，直到结束和中间部分结束了的角色，不同的功能都在讲你的故事的不同部分，连接所有类或函数一个特定的顺序只能完成故事。要进一步写下故事，您希望所有内容都按特定顺序排列，以便您可以轻松理解故事并继续从原处添加台词。
无论您是一名多么优秀的编码员，在编程中，您的工作不仅是编写有效的代码并为您提供所需的输出，而且还要编写可维护、可扩展且易于理解的代码，以便以后继续或维护您的代码项目可以理解它，他/她不必经历一个让他/她做噩梦的恐怖故事。
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
-Martin Golding
学习一些编程原则并在您的代码中使用它们会使您成为更好的开发人员。它提高了代码的质量，以后添加其他功能或对其进行更改对每个人来说都变得更加容易。让我们讨论一些基本的编程原则以及使用它的好处。
7个常见的编程原则
1. KISS：编程中没有人喜欢调试、维护或更改复杂的代码。 “ Keep It Simple, Stupid (KISS) ”指出，大多数系统在保持简单而不是使其复杂的情况下工作得最好，因此当您编写代码时，您的解决方案不应该是复杂的，需要花费大量的时间和精力来理解。如果您的代码很简单，那么其他开发人员在理解代码逻辑方面不会遇到任何问题，他们可以轻松地进一步处理您的代码。因此，始终尝试使用不同的方法来简化您的代码，例如将复杂的问题分解为更小的块或删除一些您编写的不必要的代码。
The purpose of software engineering is to reduce complexity, not to create it.
-Pamela Zave
2. DRY：代码中数据、逻辑或函数的重复不仅使您的代码冗长，而且在维护、调试或修改代码时会浪费大量时间。如果您需要对代码进行小的更改，则需要在多个地方进行更改。 “Don’t Repeat Yourself (DRY)”的主要目标是减少代码的重复。它指出一段代码应该只在源代码的一个地方实现。与 DRY 原则相反的是 WET（“将所有内容写两次”或“浪费每个人的时间”），如果您在多个地方编写相同的逻辑，则打破了 DRY 原则。您可以创建一个通用函数或抽象您的代码以避免代码中的重复。
3. YAGNI：如果您正在编写一些将来可能需要但现在不需要的代码，那么您的软件或程序可能会变得更大和更复杂。 “你不需要它（YAGNI）”原则指出“除非有必要，否则不要实施某事”，因为在大多数情况下，你将来不会使用那段代码。大多数程序员在实现软件时都会考虑未来的可能性，并为一些他们目前不需要的其他功能添加一些代码或逻辑。他们添加了所有不必要的类和功能，这些类和功能将来可能永远不会使用。这样做是完全错误的，你最终会写出臃肿的代码，你的项目也会变得复杂且难以维护。我们建议所有程序员避免这个错误，以节省大量的时间和精力。
4. SOLID： SOLID 原则代表五个原则，即单一职责、开闭、Liskov 替换、接口隔离和依赖倒置。这些原则由Robert C. Martin给出，您可以详细查看这些 SOLID 原则。
5. 关注点分离 (SoC)：关注点分离原则将复杂的应用程序划分为不同的部分或域。每个部分或域解决一个单独的问题或有一个特定的工作。每个部分都是相互独立的，这就是为什么每个部分都可以独立处理的原因，而且维护、更新和重用代码也变得更容易。
例如，应用程序中的业务逻辑（网页的内容）是不同的关注点，而用户界面是 Web 应用程序中的不同关注点。 SoC 的一个很好的例子是 MVC 模式，其中数据（“模型”）、逻辑（“控制器”）和最终用户看到的东西（“视图”）分为三个不同的部分，每个部分都是独立处理的.将数据保存到数据库与在 Web 上呈现数据无关。
6. 避免过早优化：优化确实有助于加快程序或算法的速度，但根据此原则，您无需在开发的早期阶段优化算法。如果您进行过早的优化，您将无法知道程序的瓶颈在哪里，并且维护对您来说会变得更加困难。如果您在一开始就优化您的代码，并且在需求可能发生变化的情况下，那么您的努力将被浪费，您的代码将成为垃圾。因此，最好在正确的时间优化算法以获得正确的好处。
Premature optimization is the root of all evil in programming.
–Donald Knuth
7. 得墨忒耳定律：该原理由Ian Holland于 1987 年在东北大学首次提出。它也被称为最少知识原则。这一原则划分了不同类别或不同单位的职责，可以概括为三点。
- 每个单元应该对其他单元只有有限的了解：只有与当前单元“密切”相关的单元。
- 每个单位应该只和它的朋友交谈；不要和陌生人说话。
- 只和你的直接朋友交谈。
德米特法则有助于维护独立的类并使您的代码减少耦合，这在软件开发中非常重要，使您的应用程序灵活、稳定、可维护和易于理解。