人到中年，哪怕这个节日没有任何仪式感，也是一定要过的。
先祝自己节日快乐~
这是我工作的第十三个年头，也是入行的第十三个年头，更是写了十三年Bug。时至今日，除了年龄的增长外，我没什么变化，仍然是个一线码农。写代码从当初的爱好，变成了混口饭吃的途径，时间久了难免枯燥乏味，也会有打开解决方案后盯着发呆的时候，也许是思路断了，也许是真的写不动了吧。
回想起工作那会儿，在部门里闲了两个月没进组，那叫一个轻松，每天的工作就是坐等下班，实在无聊就逛逛内部BBS，水几个帖，完全颠覆了我认知中的程序员工作。毕业前听老师说起过，刚入行的新人一般都是从敲代码做起，所谓“敲代码”就是拿到项目后不需要过多理解结构，分配的任务也只是一些很简单的功能，按照前辈设计好的思路把代码一行行敲出来，不需要思考。初入职场，我不求一下就能上手项目，故而对“敲代码”的很是期待。入职两个月后，我进了一个为其两个半月的项目组，那日子再也不想经历第二遍。的确，设计书写的就跟伪代码似的，连变量名都定义好了，完全不用动脑子，写完一块逻辑后还是不知道实现了什么样的功能，巨大的工作量一下子适应不过来，每天过着朝九晚十、上六休一的生活，连欣赏下班时的落日都成为一种奢望。
来远大以后，除开头两年有加班外，基本上正常上下班。入了C#的坑，做了十一年数采软件，见证了从常规的采集、存储、上传到结合业务对数据进行分析、应用的蜕变，某种意义上来说称其为“现场平台”更贴切。功能越推越多，软件架构也从单体应用过渡到前后端分离的C/S模式，更是引入跨平台的UI框架以适应信创要求，总之一个字——卷。为了更快熟悉linux，也为了更方便地调试，从七月份开始就把开发环境转向Ubuntu，记住一些常用命令后，配合GNOME桌面上手并不难，甚至有一种“在linux下开发更优雅”的感觉。
下午老同学问了我一个WPF的问题，其实我已经相当长一段时间不用，只知道可以这么来实现，却忘了具体怎么写，从曾经的项目中找出来发给他。后面的讨论值得深思，老同学所处的行业侧重性能，我的应用场景则没不需要考虑那么多，为了一个写法发表各自的意见。现在想来，之前做的视频流不就很吃资源嘛，用FFmpeg转码RTSP流，接第三、第四路时就会吃满CPU，如果有办法降低资源占用岂不美哉。
这么些年一直使用一种技术路线，不是说不想学别的技术栈，在.NET世界待久了，很难适应其他语言。之前有个小项目想用Kotlin+Ktor，总是带着.NET的惯性思维去找Ktor的替代的实现方式，最后发现这是完全不同的两个技术栈，从出发点开始就错了，在没有技术积累的前提下赶项目不可取，无奈放弃继续使用.NET。说通俗点，习惯面向对象的思维后，看什么都是类、继承和重写，怎么用面向过程来写，不知道。为什么总有人说Javaer的代码满满Java味，Springboot那一套Mapper、IService、ServiceImpl、Controller的分层结构早已深入人心，想来我的代码也是一股C#味。
翻看曾经的代码，我的思维模式并没有太大改变，可能是长期在同一个行业导致的，代码的逻辑不复杂，却时而能爆出新的Bug，有的只是逻辑上的小问题，有的能直接导致软件宕机，还有的Bug从逻辑上讲不通，只有极少数发生过，但只要发生一次后就偶尔会有第二次、第三次……我称之为惊天大Bug，至今悬而未决。
写了这么多，去微博逛了一圈，今年超话的热度明显不及往年，在这个没有任何气氛的节日里，还是许个小愿望：接下来一年里，少写Bug，多写有意义的代码。
2025年10月24日星期五・乘航
