思路是需要载体的，最抽象的载体我认为是数学，其次是各种应用性学科。
开发代码与实际问题之间是存在映射关系的，这也是能够用代码解决实际问题的前提。解决问题之前往往是将问题逻辑抽象出来，之后再转换为代码逻辑。
不知道有没有注意到不管是代码开发还是日常生活，比如日常交流，日常思考，日常活动......都是有大小问题的，因为有大小问题也就是大小逻辑。
这些大小逻辑在开发过程中也有体现。
举例来说，都知道或者我认为程序开发的基础是数据结构和算法。但数据结构其实还是一个大逻辑概念，不少数据结构书里面最小的数据结构是数组。但我解决某个问题我根本不需要数组，只需要声明一个或者几个变量就解决了。这样说我是不是就没有用数据结构和算法呢？
我认为不是，我觉得书里面有没说的部分，我认为最简单的数据结构不是数组，而是一个数值，而且是简单数据类型，比如布尔值。最小的问题是只有一个变量且变量为简单数据类型的问题。
有段时间笔者就很困惑，既然数据结构和算法才是编程的基础，那我日常开发中只是声明了几个变量，而且是简单数据类型，这算什么？最终我承认了开发的最小数据结构是一个简单数值，就释然了。
如果说一个简单数据类型的数值是最简单的数据结构，那么最简单的算法也不是查询或者排序算法，最简单的算法是数据当中的运算，是自操作运算。
重新明确了最小数据结构和最小算法之后，再来考虑开发代码与实际问题之间的映射就对上了。
根据业务复杂度，简单业务需求日常开发的需求可能根本用不上复杂的数据结构，比如图或者树，甚至用不到链表。算法也是，简单业务需求日常开发也用不到除了查找和排序之外更高级别的算法。
这也就是为什么有些人学了数据结构和算法之后没啥感觉，至少我很长一段时间就是这样的感觉，学完了也没用上，或者不知道在哪用。我认为根本原因还是业务简单。
这一点在我学设计模式过程中也有体会，设计模式虽然是成熟的套路，但有的设计模式我始终没有找到具体应用的场景，当然也有可能是我还需要加强练习。
写到这里想说的是想要提升使用复杂数据结构和算法的能力还是要接一些复杂需求，或者学习一些优秀的源码；或者主动优化项目，开阔思路看看是不是可以应用更优秀的思路解决问题。
本文完。