解决复杂编码问题的 7 个强大原则😤

长评论🥴

最近我接到一个任务，要修复一个非常复杂的组件中的一个 bug，其中涉及到一些令人费解的递归操作。我花了好几天才弄清楚所有事情，但最终还是搞定了。

这 7 条强有力的原则帮助我解决了这个问题：

1. 先思考，再编码
我的第一个建议是先退一步思考问题。如果可以的话，可以画个草图，画个图表，写下你的想法，或者找个人讨论一下。

将编码环境与思考环境分开，也就是说，关闭编辑器并在纸上、白板上或图表工具中工作。

只有当您完全理解了问题并有明确的解决策略时，才该深入研究代码。

2. 分解问题。
复杂性其实就是一堆简单问题串联起来的结果。试着将你的任务分解成更易于管理的小块。

这部分比较难，因为需要一些训练才能理解更大的问题是如何构成的。唯一真正有帮助的是之前见过很多简单的问题，并尝试从中识别出规律。

3. 首先修复数据
很多问题都是因为底层数据的结构会导致不必要的问题。当然，修改底层数据集并不总是可行的，但你可以对其进行规范化，以避免遇到极端情况。

有时，只需用空值填充可选参数即可减少即将出现的麻烦。或者，您只需添加一个额外的参数即可简化代码库。

因此，如果这在您的项目中是可能的，请花时间思考您所从事的功能之外的事情，并尝试考虑调整您的数据以避免极端情况。

4. 从 MVS 开始
你的 MVS 就是问题的 MVP，也就是“最小可行解”。这个词是我刚想出来的，所以现在先别去谷歌搜索。

你的 MVS 应该仅仅展示你的修复或功能是否有效。可以把它想象成 MVP 的迷你版。有意跳过边缘情况，只关注问题的核心。

例如，在我遇到的编程问题中，递归函数调用了 10 个其他函数。一开始，我把所有函数都注释掉，只专注于核心功能。之后，我慢慢地添加了更多逻辑。

5. 忽略你所知道的关于干净代码的一切

抛开你学到的所有关于如何编写简洁代码的知识。快速行动，打破常规。你是否把某个逻辑重复了三遍？很好。你的函数代码快要 300 行了吗？没问题！

你可以稍后再清理所有这些。专注于问题的本质。那 80% 才是最重要的，而不是拖延思考如何以逻辑方式对函数进行分组，或者争论如何命名变量。

6. 抽象是你的敌人
。你的问题已经够复杂了。不要通过抽象类或工厂设计模式来引入额外的复杂性……当然，有时候这些东西是有益的，但这里的首要任务是简单性。除非万不得已，否则不要抽象任何东西！

7. 别忘了清理。
虽然这些原则或许能帮你快速找到问题的解决方案，但它们也可能会给你留下一些小麻烦。所以事后清理很重要。一定要考虑你的同事，最好把代码留在那里，这样别人就不会遇到你遇到的麻烦。彻底测试所有内容，并记录你的发现。

概括

解决复杂问题可能会令人沮丧，但如果你能够坚持下去，也会获得丰厚的回报。希望这些建议对你有所帮助，我期待听到你关于如何处理复杂编码问题的建议。

附注：如果您需要 Vue/Nuxt 项目的专业支持，请通过https://nuxt.wimadev.de与我联系