2025.05.27 代码探索中 错误的路线
今天还是比较开心的，延续多年的问题，经历多日的漫漫长夜，解决方案管理器基本功能的最后一个模块终于实现了。主要是补充了编辑器的切换，做成了类似于操作系统打开文件的效果，可以选择文件的打开方式。
讲述之前，必须要先肯定一个事情，那就是这个功能模块，在我现在的软件系统中是没有用的。
在最开始的时候，设计了后续的分析模块，分析模块要基于这个功能模块。但后续因为各种情况，数据存到数据库之后，本地的分析系统就被简化到了打开，查看，以及一些基础的模块操作。复杂的分析模块就无掉了。
按理来说，这个完全没有人的模块，在我之前提到的设计理论中，就应该及早的剔除，但实际是，我花了巨量的事情，做和这个模块相关的东西。
实际上，在多次迭代的过程中，比如反射，属性、模板，编辑器、插件，都是在这个模块的迭代中，最先探索和应用的。需求决定代码的构建方式，而这块的需求实际上最开放，最顶级的。
比如现在功能模块中最重要的两个部分，是模板管理以及服务管理，其框架结构设计，都脱胎自不断迭代的解决方案管理器的设计。因为就这些功能模块本身的设计需求，是比较简单的，不足以支撑探索发现更高级的构建方案。
原定设计中，文本编辑器，在后续的业务迭代中，被用在模板模块中对于json的编辑和修改上。
又比如图像编辑模块，以及自定义文件相关的一系列逻辑,基本是构建这套软件的基础。光是一个图像编辑器做了得有大半年的时间。而这个编辑器又事实性的做了原本在分析模块应该做的工作。而且，在后续的迭代中，这个模块又事实性的成为其他特化代码的基础，并且为了实现业务需求做了一定程度魔改，而且这个业务还在用。自定义文件的预览效果也是由这个模块提供的
我想要表达的东西是什么呢？
在知识的传递中，最难的是Know Why,就是为什么这么做?构建思路是什么?迭代的可行性有哪些?你希望推动这个项目的走向是什么?
一方面工程代码杂糅了业务、性能甚至是政治博弈。另一方面只有决策者能够写下他们的思路，而且思路比结果难写太多了。
真实的世界不是按部就班的。
失败的作品并非毫无价值。