于开源之夏后
双选会上下定的决意
双选会博文片段传送门这篇文章是接续着双选会博文段后的内容,建议没看过前文的读者先去补充一下上下文。
在双选会结束后我很快的投身于鸿小易的开发,毕竟是挑战杯的项目,ddl追的还是比较紧的。开发、写博客、改bug、给队友当顾问……这样的循环充满了我的四月,虽然忙碌,但却让我的内心异常的充实,我非常享受这种感受,一方面是对于技术的狂热,另一方面我能清醒的认识到这是在让我自己成长,在沿着自己所选的道路前进,实现自我价值的感觉让我感到满足。
开发完成,材料上交。似乎一切都告一段落。走出信息楼,那道夕阳因丁达尔效应而拉出的一道金光照在我身上,让我仿佛被拉回到了双选会结束时那充满希望,满心憧憬的傍晚。我没有过多的停下脚步,因为这段经历本就不让我感到疲惫,反而,我内心的悸动开始难以抑制的推着我开始思考接下来该做些什么。优化鸿小易的话,我可以在agent上下功夫,去认真学习一下比较成熟的工作流,去优化我生成回答的速度,去优化我知识库的索引标签;也可以在客户端,做更多的页面,加入华为账号一键登录,设置对话历史列表,开发同账号云同步功能等等,一大堆todolist出现在我脑海中带来的不是压力与焦虑,而是强有力的心跳所带来的兴奋与期待。
我开始实施不久后,我发现开源之夏2025开始报名了,我本来打算说用暑假好好完善一下我的鸿小易之后直接用这个项目去找一个实习,用实习时间上的领先来去创造优势,所以犹豫了一下决定先不去报名,先做着手上的事,稳步推进。就这样我在实验室沉浸式的开发了一段时间,突然我收到了来自子安学长的微信。
说是要推荐我去报开源之夏,里面有开源鸿蒙的相关项目,还有他导的项目,我就说去看看是否是我力所能及的内容,毕竟当时的我还没有那么深的VibeCoding功底。

上面这张图是同期的另一个开鸿项目PIEditor,这个项目和我最后选择的NowInOpenHarmony我其实并没有过多由于。PIEditor这个项目主要是对于开鸿的插件的一个开发,这方面我并没有相关经验,同时我并不认为这个东西做出来之后很易于向面试官展示,相比于NowInOpenHarmony来说它的领域更加深入细化,这种细化的领域对于生态的发展来说可能比做一个新闻软件更有用,但是对于那时我自身的情况来说并不适合。有着清晰架构,属于传统前后端软件开发的NowInOpenHarmony很显然对于新手来说更加友好,且更加易于展示。
软件工程的全流程实践
开发前的准备
此前我还没有很正规的去进行过完整的软件开发流程,有需求,大概明白要做出来个啥就上了,有点像是快速原型的感觉,但实际上又差得远,因为很多时候都是需求并没完全明确就开始了,“先做着再说,不行就改”的这种思想充斥着我的大一大二。由于写的东西都是很小的项目,而且也没有什么标准答案、甲方的刁难之类的,所以哪怕做出来的是一坨屎也没啥实际影响就是了。
但是这次不一样,首先是在申报的时候就需要基于这个项目的需求进行方案的设计,并撰写申报书由导师审核,审核通过之后才能动工,这彻底抹杀了我过去的开发习惯,虽然我那时还没有上软件工程这门课,但我还是知道这样做是有意义的、是正确的、也是我应当掌握的。所以我也是借助AI的力量,在期末考试期间急速补全了我对于PY服务端的知识缺失,并决定使用VibeCoding的力量来助力我去完成对于我并不熟悉的后端开发,同时要精心按照一多的三层架构以及MVVM架构去手搓鸿蒙客户端。
计划书中的部分内容当时我还是不太明白,但为了得到这个项目的机会,我还是硬着头皮投了这份方案书。在通过邮件和导师进行了一些沟通以及问题的询问后我有了信心,剩下的只剩等待中选结果了。
开发中的实践
中选后导师没有急着让我去直接开始写代码,而是先进行整体的时间规划设置ddl,这让我来了兴趣,有ddl的开发和无ddl的开发对于我来说完全是不一样的体验。在设计方案估算开发周期的时候说实话是遇到了挺大阻力的,因为我在后端的开发这一块还没有过很深度的实践,对于爬虫的可行性来说我属于是7成以上都是未知的状态。所以我先让AI给我依据正常的开发进度去设置了一个ddl先去逼一逼自己再说,然后找导师确认了一下说是先去写一份详细的计划书还是先去进行可行性验证。导的意见是先去进行可行性验证,如果验证通过我们才能进行下一步的开发,才能更好的规划时间。
开源鸿蒙官网的接口分析进展的比较快也比较顺利,因为其接口并没有设置严密的token验权,也没有进行很多的反扒,我直接通过开发者工具找到了接口也跑通了请求。但CSDN、51CTO的反扒还是比较严苛的,我试着写了几版爬虫但都在跑了一两次后就被ban了。
于是我决定去砍掉过于冗杂的爬虫,转头去实现一下将数据源爬虫接入到后端服务框架并对外提供服务的部分。又发现了单线程服务在爬取时会阻塞并且让客户端长时间等待的情况。于是又开始研究多线程以及对于多线程之间数据冲突的控制问题,避免响应的同时数据发生更新导致数据错误。等等等的问题我就不再列举了。
在实践中学习,用BUG来考试,这套逻辑对我来说异常的适用,其实回望初学编程时会发现也是这样的一个过程。
开发后的测试与结项报告
在开发完后我尽可能全面的玩弄我的软件,去多个设备频繁的请求我的后端,最后确实是发现了不少问题,服务器CPU被打满,客户端退至启动页后无法操作,首次加载无数据等等问题,都是在最后测试阶段发现的,毕竟没有人能确定自己的逻辑是无瑕的,没人能确定自己的代码是完美的,所以测试是必要的。
而对于结项报告。










