没人教你的编程原则

中文العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어PortuguêsРусский
TThe Coding Koala
Computing/SoftwareManagement

Transcript

00:00:00你知道为什么有些人即使在这一领域工作了多年，
00:00:04却似乎永远无法成长为一名优秀的开发者吗？其中涉及多种因素。
00:00:09而其中一个原因就是不懂编程的底层原理。
00:00:14这些不仅仅是你学过一次就会忘记的理论概念。它们是真正能让你作为开发者成长得更快的核心内容。
00:00:19让我们从第一个原则——童子军规则开始。这个原则源自美国的童子军。
00:00:25简单来说，他们有一个简单的原则：离开营地时要比发现时更整洁。
00:00:31不知道在座的有多少人了解“鲍勃大叔”（Uncle Bob），他是将这个概念
00:00:36引入编程社区的人，即在离开代码时使其比你发现时稍微整洁一点的做法。
00:00:41当修改现有代码库时，代码质量往往会下降，这可能会
00:00:47增加技术债。而通过持续的改进，
00:00:52无论改进有多小，都能减少技术债。举个例子，假设
00:00:57你被分配了一个任务，要修改这个函数中的数值。
00:01:03你完成了修改，但你可以看出变量命名不够清晰。
00:01:08像大多数开发者一样，你本可以直接忽略并提交任务。
00:01:12但如果你遵循这个原则，你会把变量名改得更
00:01:18易懂。这只是一个简单的例子，不仅是变量名，如果你看到任何
00:01:24可以改进的地方，就去改。仅仅这个简单的举动对代码库来说就非常有价值。
00:01:30第二个原则：避免过早优化。这意味着，不要试图让你的
00:01:36代码在真正需要提速之前就变得很快。首先要实现功能。只有在必要时才进行优化。
00:01:42唐纳德·克努特（Donald Knuth）有一句名言：过早优化是万恶之源，
00:01:47这是对的，因为程序员常常浪费大部分时间去担心程序中
00:01:51非关键部分的执行速度。因为一直有一种要
00:01:57优化一切的错误概念。这个原则并不是反对优化你的代码库。它是关于
00:02:03理解什么需要优化，以及最重要的是，何时进行优化。我认为这是
00:02:08大多数开发者的弱点，因为我见过有人明明只有100个用户却使用微服务，
00:02:14或者为根本不需要的功能添加缓存。第三个原则：
00:02:19为维护者编写代码，这意味着当你编写代码时，你应该以
00:02:23让未来维护代码的开发者不会感到难以管理和
00:02:29理解的方式去编写。这是因为你今天写的代码以后将由其他开发者或
00:02:35你自己来维护。如果你现在只关注实现功能，而不关注清晰度，那么将来如果
00:02:39你需要回过头来看这段代码，你会很难理解到底发生了什么。看看
00:02:45这个例子。两者都能工作并实现完全相同的功能。
00:02:50但你更倾向于在代码库中看到哪一个呢？所以结论是，无论你何时编写或通过AI生成代码，
00:02:55在提交工作之前，一定要确保它易于理解且可维护。
00:03:01我们的第四个原则叫做YAGNI，它是“你根本不需要它”（You Aren't Gonna Need It）的缩写。
00:03:06这个原则简单来说就是，你不应该构建你现在并不需要的东西，或者仅仅因为
00:03:10也许将来会用到就去构建它。因为大多数开发者都有预测
00:03:16未来可能需要什么的习惯。但大多数时候，这些代码永远不会被使用，只会给项目增加额外的
00:03:21复杂度。永远记住这一点。如果你在做一件未来可能需要的事情，
00:03:27你就是在浪费你处理当前真正需要的事情的时间。第五个原则：做可能奏效的最简单的事情。
00:03:32这意味着无论你面对什么问题，都要选择
00:03:38能真正奏效的最简单的解决方案。不要过度思考。不要过度工程化。
00:03:43问问你自己，现在能解决问题的最简单的方法是什么？这个想法源自极限
00:03:48编程，它告诉我们要先构建简单的东西，然后再重构为
00:03:53更好的方案。大多数开发者没有意识到这一点，但他们往往试图从一开始就构建完美的方案，
00:03:59这最终会使他们的解决方案变得过度复杂。遵循这个原则，你可以更快地得到可运行的
00:04:04代码，即使以后需要修改，通常也比修复一个错误的复杂设计要容易得多。
00:04:10相信我，作为一名开发者，意识到自己何时在过度工程化某件事
00:04:14是非常重要的。那么，以上就是你应该立即开始
00:04:19付诸实践的五个编程原则。除了这些，还有其他原则我没有在
00:04:24本视频中涵盖。如果这有帮助，请在评论中告诉我，我会制作第二部分内容。

Key Takeaway

通过遵循童子军规则、避免过早优化、坚持YAGNI原则以及选择最简方案，开发者可以显著降低技术债并提升代码的长期可维护性。

Highlights

  • 童子军规则要求开发者在离开代码库时，使其比发现时更加整洁。

  • 过早优化通常是导致程序员浪费时间处理非关键执行速度问题的根源。

  • 代码的可读性对未来维护者至关重要，应优先于实现功能后的随意提交。

  • YAGNI原则建议停止构建仅仅是为了“未来可能需要”的功能，以避免项目不必要的复杂度。

  • 选择实现目标的最简单方案，随后再进行重构，可以有效防止过度工程化。

Timeline

童子军规则与技术债

  • 童子军规则主张每次修改代码时，将其整理得比原来更整洁。
  • 持续的微小改进能有效减少代码库中的技术债。

该原则源自童子军关于离开营地时保持整洁的习惯。在编程中，这具体体现为即使只是修改一个数值或重命名一个变量，只要发现不清晰之处就立即改进，而不是仅完成任务后直接提交。

避免过早优化

  • 优先实现功能，只有在必要时才执行优化。
  • 过度优化往往导致资源浪费，例如为仅有100个用户的项目使用微服务架构。

唐纳德·克努特认为过早优化是万恶之源。此原则并非反对优化，而是要求开发者明确判断优化的时机与必要性，避免在非关键路径上消耗研发精力。

为维护者编写代码

  • 代码编写应以未来维护者易于理解为首要目标。
  • 不论是手动编写还是通过AI生成，提交前都必须确保逻辑清晰。

代码的生命周期远长于编写过程。忽视代码清晰度会增加后续维护和理解的难度，因此必须保证方案在功能实现之外同样具备可维护性。

YAGNI原则与简单方案

  • YAGNI原则指出不要构建现在不需要的任何东西。
  • 构建最简单的方案有助于更快速地运行代码，后续重构往往比修正错误的复杂设计更省力。

针对未来预测的过度工程化会引入无谓的复杂度。遵循极限编程理念，从最简单、能奏效的方案起步，能避免陷入过度思考和设计的困境。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video