毕设日记（三）
里程碑时刻，正式地聊一聊。
距离上一篇毕设日记已经过去的整整两个月，抛开那些由于众所周知的疾病而放下工作的日子，在这一个多月的时间里，磕磕绊绊地算是大体完成了整个规划中最重要的基础设施部分，这意味着从现在开始，项目进入了一个稳定开发的阶段，所以，我想现在我可以来聊一聊这个项目本身了，但在这里我不打算探讨一些技术细节，只是来聊聊做毕设和写论文过程中自己的想法和感受。
这个毕设在做什么？
之前说过，在选题阶段我最终将范围确定在两个项目，一是数据结构算法可视化，二是web3下基于智能合约的投票系统。选择它们的理由其实也很直白，未来职业生涯的很多时间可能都是在做系统业务，所以现在我不想做那些信管系统，尤其是在对实际业务并不了解，也很难在不接触相关企业的运营流程情况下去做业务。而关于那些AI选题，纵使AI领域发展热火朝天，AI开发人员钱途一片大好，但眼下我对AI没那么感兴趣，而且导师们大都也有AI领域的研究经历，他们一定会重点关注诸如数据集、模型类别、算法细节等重点内容，但这其中凡存在一丁点儿问题，想通过毕设就不会太顺利了。此外我也看到一两个数据可视化项目，虽然我对可视化和UI交互很感兴趣，但由于接触的是系统层面的数据以及要求Python编程，这两块不是我熟悉的领域和技术，所以没有把它纳入选择范围。
最后确定毕设的选题是算法可视化，算是正合我意。在我的设想中，这个项目应当属于web app，在网页中应当存在一个代码编辑器，用户可以自行输入代码，根据编程语言的不同，系统会调用不用的编译器或者解释器得到结果。然而单纯地编译算法代码最多只能算是实现了一个所谓的在线编译器罢了，最理想的效果是系统能够识别代码中涉及算法的代码，从中分析出相应数据结构的操作并将其转化为可视化效果，不过以我目前的认知来看，或许只有ChatGPT级别的AI模型才能够拥有这样的能力。于是退而求其次，存在两个方案：
- 在前端与debugger之间建立通信机制，系统将根据用户的要求把特定变量的变化针对性地做可视化渲染。
- 通过设计一套可视化API，在算法代码中插入API调用，这样通过编译器编译运行后就可以输出可视化指令，由前端对指令进行解析，进而渲染可视化效果。为达到这一点，只需要求API与算法代码所采用的编程语言相同，而如果想要扩展API支持的编程语言范围不难，可以进一步把API总结成一套协议，任何编程语言只要实现了基于这套协议的API，生成的可视化指令就能够被前端成功解析。
经过考虑，事实上第一种方案无论在实现还是扩展上都是比较困难的：获取debugger监控的变量类型并不是容易的事情，很多编程语言有大量内置的高级类型，很难去确定要如何设计可视化实现，并且调试过程会带来巨大的性能开销，这对一个需要依靠服务器的网站来说不是什么好事。所以这个项目的最佳实践就是采用第二个方案，因此这套API的设计与实现是整个项目核心部分。
现在做了什么
由于这套API是系统所有功能的基石，截至目前，它已经顺利度过了大范围迭代修改的阶段，进入一个稳定状态，这意味着其他的上层功能都可以开始逐步实现，对我来说这绝对是新年以来能够排上名次的好消息，接下来需要做的就是更多的学习与更多的实践了。