云知识竞赛小程序开发时，写多考试场景排序时，有一些复杂性，卡了一段时间，类似的情况在写其他小程序也出现过，现总结一下。

1 复杂性类型

1.1 算法复杂性

这类一般具有通用性，往往有人已经造了轮子，只是你没有找到。

1.2 业务复杂性

  • 业务需求变化较快，需求变化时，需要修改的地方较多
  • 业务逻辑复杂，交叉关联较多，需要考虑的情况较多

2 解决思路

2.1 算法复杂性

  • 除搜外，建议直接上Github copilot，写好需求，直接出代码，往往比自己写更简洁、更具执行效率；
  • 阅读真实项目源码，开发中遇到的所有问题，均可能是别人曾经的问题；
  • 代码库或知识库的积累，一是减少bug；「二是减少重复造轮子的时间」；

2.2 业务复杂性

下面「」之间的内容是github copilot生成的

  • 需求均是自己提的，需求变化是因为：「快速迭代，快速验证，快速反馈的要求」；
  • 数据结构优先，初期可以低功能上线，但需要在数据结构上做好全功能设计，以便后续扩展；改数据结构是致命的，甚至导致重构；另一个问题是：新版小程序导致老版用户使用不了；
  • 业务逻辑复杂，「交叉关联较多，需要考虑的情况较多，可以通过状态机来简化，状态机是一种设计模式，可以将复杂的业务逻辑简化，降低复杂度，提高可读性，降低维护成本；」（这一行是github copilot生成的，引入状态机概念）；引伸阅读：什么是状态机？；
  • 使用金字塔原理，梳理业务逻辑，将复杂的业务逻辑拆分为简单的业务逻辑，再逐步组合，最终实现复杂的业务逻辑；在金字塔的基础上，进行快速迭代；工具MindNode；
  • wxml与js交互，可以「使用自定义组件，将复杂的业务逻辑封装在自定义组件中，降低复杂度；引伸阅读：自定义组件」；
  • wxml与js交互，可以使用大的对象变量，减少小变量的使用，降低复杂度；
  • 把大函数转换成大函数引用小函数，减少重复代码，降低复杂度，增加代码清晰度；使用Bookmarks在函数间跳转；
  • 注释，注释是最好的文档；js文件头部注释主要功能；函数注释功能及输入输出接口；代码块注释具体功能；使用Prettier辅助；
  • 辅助js文件，记录数据库设置、数据结构及字段、变量的作用意义；

3 其他

  • 对象或数组的引用，导致修改了原对象或数组；
  • 在重要节点，设置console.log()，查看数据结构，或功能提示，以检查运行路径是否正确；

没有银弹，复杂业务、复杂代码是门工程学，这门工程学也在不断地迭代。

阅读参考：一文教会你如何写复杂业务的代码，这是大的架构思路，也提到了金字塔原理。