起因
我在做自己的年度总结的图片之后，做完发现图片实在是太大了，有79MB之大，于是为了能在某不知名的绿白色和白黑红色社交平台上发出来，我寻找有没有能切九宫格的本地工具
结果当然是没有，不然也不会有正在写这这篇文章的我了
我找到的基本都是在线 收费 这种东西， 拥有一定动手能力的我（存疑） 当然不会向这种东西低头，于是我开始查（问）文（A）档（I）
过程
最开始我就只是开发一个单纯的就我自己用的程序
↑其实就是单纯的停留在调试的阶段，能用就行的程度
过了几天之后，我突然想起来我为什么要做这个东西的契机，想到可能会有其他人和我一样需要这种纯本地的、离线的运行的工具，于是我就开始动手完善这个程序
思考的内容：
- 给别人用，总要给别人处理吧，于是我把初版的程序稍微改了一下，输入文件还是
input.png输出是output.png，起码能有人简单用一下 - 进一步我发现这样貌似对于使用者还是太麻烦了，并且上一个阶段还是一个脚本文件的状态，并不符合普通人使用程序的习惯，于是我开始问AI，做 UI 出来，给别人用
- 其实到上一步我本来就要结束了，但是我又想到了，既然做了，为什么只能处理单个的特定文件？还不能自定义输出路径？不如让它在处理上更加强大，于是我增加了多文件处理与输出文件路径自定义
- 加了多文件处理之后，我想到了图片文件常用类型还是挺多的，那我就做多点覆盖吧。于是我把原本的
png拓展到了pngjpgjpegbmp四种比较常用的图片类型 - 到此我的程序框架基本完成了，我就修改一下程序的UI配色，我在 配色表 进行的配色参考，并增加Tips，让使用者知道应该如何使用、谁开发的以及作者对这份程序持什么样的态度（因为Aria2的事情）
- 原本我就想要打包了的，但是我突发奇想，“欸！我们来搞个多线程的特性吧！不止！我还要用显卡加速工作！”，结果当然是失败了，不清楚为什么处理到我最初要处理的那张
79MB的图片的时候程序稳定的崩溃了，于是被迫放弃了 - 经过上面的一条，算了，我们来增加结算页面吧（ ， 于是我稍微多用了一点性能来计算本次处理用时，还要精确到毫秒级别，
给别人好好进行跑分排名 - 既然都有用时计算了，我们再来统计一下本次的处理文件数量吧
- 到了第8点我又想到了“对哦，我们没注意到过，既然我都支持多文件数量、类型的处理了。一会别人处理完出来，要是文件命名又不规范，一会岂不是要在一堆像垃圾堆一样的文件夹里面找哪个是哪个”，于是我多加了一个判断，判断是否需要帮他们来分类一下每种图片类型存放在我指定的分类文件夹中
好了，以上就是我在做这个程序的时候的思考
结尾
我在上课的时候来兴趣了，想看看GitHub上面到底有没有人做我这个，结果搜索出来了，发现有两个。
一个是给图片多加边框
一个是拥有预设的切割工具，是一个Android平台的app
一看到就让我不是很想接着开发完善自己这个工具了，但是处于学习，我可能会接着用这个程序来实验学习
就这样，886