文章目录每日一句正能量一、实习第一天我以为最大的难题是写代码二、项目背景设备巡检与异常工单模块三、第1周我修复的第一个 Bug不是加一行空值判断3.1 问题现象3.2 复现报告3.3 问题代码3.4 修复方案3.5 第一次导师反馈四、第2周第一次 Code Review让我意识到“能运行”远远不够五、第34周从修 Bug 到交付第一个小需求5.1 状态映射六、第5周我第一次因为“重复请求”导致测试失败6.1 问题示例6.2 请求序号方案七、第68周我开始负责离线同步7.1 离线操作模型7.2 队列处理八、第8周技术成长曲线开始出现变化九、代码贡献统计为什么我没有用提交数证明自己十、第910周我第一次独立负责模块10.1 需求拆解表10.2 风险清单十一、导师指导最有价值的不是答案而是工作方法第2周第5周第8周第11周十二、团队协作我的成长不只来自代码十三、一次失败我没有提前暴露接口风险十四、转正答辩我怎样证明自己能独立负责14.1 业务交付14.2 代码质量14.3 性能和稳定性14.4 团队协作14.5 未来计划十五、转正答辩的15分钟结构第12分钟项目和职责第37分钟成长里程碑第810分钟一个技术难点第1112分钟失败复盘第1315分钟未来计划十六、我的转正心得转正不是“实习期间没犯错”十七、给准备进入鸿蒙生态企业实习的同学几点建议17.1 第一周先学工程不急着学所有平台能力17.2 修 Bug 要建立证据链17.3 每个需求至少准备三种状态17.4 Code Review 不是否定17.5 记录每天的贡献17.6 不要公开企业内部信息十八、成长的真正标志从“有人告诉我做什么”到“我知道怎样把事情做完”十九、总结每日一句正能量稳定情绪既能滋养自己也能温暖他人。情绪稳定不是压抑而是内心有锚点。自己不被情绪裹挟时能量有余裕自然能平和地对待他人。先安己后及人。标记参与方向三「毕业季 · 鸿蒙同行」文章投稿。一、实习第一天我以为最大的难题是写代码正式进入鸿蒙生态企业实习前我做过智慧校园导航、实验室预约元服务和设备巡检三个项目也能独立使用 ArkTS 与 ArkUI 完成页面、路由、网络请求和本地数据存储。因此我对实习的第一印象是只要尽快熟悉团队代码就可以开始开发需求。真正进入项目后我才发现学校项目与企业工程最大的差别不是代码量而是每一次改动都有边界。在学校项目中我可以自己决定字段、接口和发布时间在企业项目中一个看似简单的页面状态修改可能涉及服务端接口旧版本兼容本地缓存多设备表现权限和账号日志自动化测试发布节奏回滚方案多个团队的联调。我的导师没有在第一周让我开发新功能而是给了我一个 Bug某些设备在网络恢复后进入巡检详情页页面偶现空白。当时我以为这是一个简单的空值判断。两天后我才真正理解Bug 修复不是找到一行报错代码而是建立一条完整证据链。二、项目背景设备巡检与异常工单模块我参与的是一个匿名化的“智能设备巡检应用”。它面向园区和企业设备维护人员主要流程包括查看当天巡检任务到达设备现场读取设备状态填写巡检结果发现异常时创建工单网络不稳定时先保存本地网络恢复后同步管理者查看完成率和异常趋势。为了保护企业信息本文只保留通用工程结构不展示任何真实客户、接口地址或内部代码。项目核心技术包括ArkTSArkUIStage Model网络请求本地数据通知离线同步日志和测试。三、第1周我修复的第一个 Bug不是加一行空值判断3.1 问题现象设备从离线恢复网络后用户进入巡检详情页偶尔只看到空白页面。退出重进后又能正常展示。我最初的猜测是接口返回空页面状态没有更新路由参数丢失。导师让我先不要改代码而是提交一份复现报告。3.2 复现报告设备环境 网络状态 账号状态 操作步骤 出现概率 日志时间范围 请求是否成功 页面生命周期 本地缓存状态 是否可稳定复现经过多次测试我发现问题只在以下条件同时满足时出现用户曾经离线打开过该任务本地存在旧缓存网络刚恢复页面aboutToAppear先读到缓存网络请求完成后状态对象被错误地重置。3.3 问题代码下面是简化后的教学示例Statedetail?:InspectionDetailStateloading:booleanfalseasyncaboutToAppear():Promisevoid{this.loadingtruethis.detailawaitthis.repository.readCache(this.taskId)constremoteawaitthis.repository.fetchDetail(this.taskId)this.detailremotethis.loadingfalse}当fetchDetail()在网络恢复阶段返回临时空结果时已经读取的缓存被覆盖页面条件渲染又没有空状态最终表现为空白。3.4 修复方案exporttypeDetailState|{status:loading}|{status:success,data:InspectionDetail,source:cache|remote}|{status:empty}|{status:error,message:string}Statestate:DetailState{status:loading}privateasyncloadDetail():Promisevoid{this.state{status:loading}constcacheawaitthis.repository.readCache(this.taskId)if(cache){this.state{status:success,data:cache,source:cache}}try{constremoteawaitthis.repository.fetchDetail(this.taskId)if(remote){this.state{status:success,data:remote,source:remote}awaitthis.repository.saveCache(remote)}elseif(!cache){this.state{status:empty}}}catch(error){if(!cache){this.state{status:error,message:加载失败请稍后重试}}}}这次修改不只是增加空值判断而是明确页面状态区分缓存和远端来源远端失败时保留可用缓存增加空状态和错误状态补充弱网回归测试。3.5 第一次导师反馈导师对我说修复结果没有问题但以后先提交复现证据再提出根因假设。看到报错就改代码很容易修复表面现象又引入新的问题。这是我实习中最早形成的工作习惯先复现再定位先证明再修改。四、第2周第一次 Code Review让我意识到“能运行”远远不够修复完成后我提交了第一次合并请求。评审意见包括状态类型应该放到独立文件日志缺少任务 ID错误分支没有测试缓存写入失败不应影响页面展示页面方法过长应拆分日志中不能输出完整用户信息。我一开始觉得这些都是“细节”。后来导师让我思考当问题出现在用户设备上团队怎样通过日志知道是哪一个任务、哪一个阶段失败当另一个人接手模块时他能否快速看懂状态当缓存模块改动时页面会不会被连带影响我开始理解 Code Review 不是检查语法而是在检查可读性可测试性维护成本安全和隐私团队协作边界。五、第34周从修 Bug 到交付第一个小需求我的第一个需求是“在巡检列表中展示设备健康状态并支持快速创建异常工单”。功能很简单但实际需要处理正常、异常、离线和未知状态服务端旧数据为空状态筛选列表刷新详情页入口工单参数重复点击埋点与日志UI 测试。5.1 状态映射exporttypeDeviceHealthNORMAL|WARNING|OFFLINE|UNKNOWNexportclassDeviceHealthMapper{staticfromCode(code?:string):DeviceHealth{switch(code){case0:returnNORMALcase1:returnWARNINGcase2:returnOFFLINEdefault:returnUNKNOWN}}statictoText(health:DeviceHealth):string{switch(health){caseNORMAL:return正常caseWARNING:return异常caseOFFLINE:return离线default:return状态未知}}}第一次提交时我把映射逻辑直接写在 ArkUI 组件里。导师要求我移到独立业务模块并给未知状态补测试。这让我学会了一个非常重要的原则UI 展示可以变化但业务含义应该稳定、可测试。六、第5周我第一次因为“重复请求”导致测试失败列表筛选和页面返回会触发多次刷新。测试同事发现快速切换筛选项时可能同时发出多个请求旧请求后返回覆盖新筛选结果。6.1 问题示例asynconFilterChange(filter:string):Promisevoid{this.currentFilterfilterthis.tasksawaitthis.service.list(filter)}假设先请求“异常”再请求“离线”但异常请求最后返回就会覆盖正确结果。6.2 请求序号方案exportclassTaskListController{privaterequestVersion:number0asyncload(filter:string):PromiseTask[]{constcurrentVersionthis.requestVersionconstresultawaitthis.service.list(filter)if(currentVersion!this.requestVersion){return[]}returnresult}}页面层只有在当前请求仍然有效时才更新状态。我同时增加防抖加载状态错误重试请求耗时日志快速切换 UI 测试。这次缺陷让我第一次真正理解异步问题不是“有没有await”而是多个任务之间的顺序和状态一致性。七、第68周我开始负责离线同步园区地下设备间网络不稳定巡检记录不能因为网络失败而丢失。因此模块需要支持本地暂存网络恢复后补传防重复提交过期策略冲突处理同步状态展示。7.1 离线操作模型exportinterfacePendingOperation{id:stringbusinessId:stringtype:SUBMIT_RECORD|CREATE_WORK_ORDERpayload:stringcreatedAt:numberretryCount:numberexpireAt:number}7.2 队列处理exportclassOfflineQueue{privateitems:PendingOperation[][]enqueue(item:PendingOperation):void{constexistedthis.items.some((current:PendingOperation)current.iditem.id)if(!existed){this.items.push(item)}}asyncflush(sender:(item:PendingOperation)Promiseboolean):Promisevoid{constremained:PendingOperation[][]for(constitemofthis.items){if(item.expireAtDate.now()){continue}constsuccessawaitsender(item)if(!success){remained.push({...item,retryCount:item.retryCount1})}}this.itemsremained}}导师继续追问应用重启后队列是否还在同一个工单重复发送怎么办服务端已经成功、客户端超时怎么办记录过期后如何提示用户多设备同时编辑如何处理我因此补充队列持久化请求幂等 ID服务端结果查询最大重试次数用户可见的同步状态冲突记录。这也是我第一次从“完成一个需求”转向“设计一个可以承担异常情况的模块”。八、第8周技术成长曲线开始出现变化前四周我的主要目标是看懂代码修复问题通过评审避免重复错误。第六周以后我开始做更多主动工作在开发前画数据流提前列出接口风险向测试确认验收范围给需求拆任务记录性能数据主动补文档评审其他同学的小改动。成长的标志不是我写得越来越快而是返工次数减少需要导师兜底的场景减少问题描述更清楚风险暴露更早提交内容更完整。九、代码贡献统计为什么我没有用提交数证明自己文中的提交、评审和缺陷数据是匿名化教学样例不是任何真实企业仓库统计。实习中提交数量可以反映参与度但不能直接代表价值一个大提交可能难以评审很多小提交可能只是格式修改删除重复代码可能比新增代码更有价值补测试和日志不一定增加很多业务代码提前发现接口风险可能没有代码提交却减少大量返工。因此我在转正答辩中把代码贡献拆成四类贡献类型证据功能交付需求、验收单、录屏质量改进测试、缺陷、Code Review稳定性日志、异常、弱网与回归测试团队资产文档、组件、问题复盘十、第910周我第一次独立负责模块独立负责并不等于所有代码都自己写而是需要对模块的结果负责。我负责的巡检模块包含需求澄清页面状态接口定义本地缓存离线同步日志测试联调版本验收。10.1 需求拆解表任务1确认状态字段与兼容规则 任务2实现任务列表与筛选 任务3实现详情和异常工单入口 任务4增加缓存与离线队列 任务5增加日志和错误提示 任务6单元测试与UI测试 任务7服务端联调 任务8验收和问题关闭10.2 风险清单风险服务端状态枚举可能变更 方案集中映射并保留 UNKNOWN 风险弱网重复提交 方案请求幂等ID 本地队列去重 风险缓存与远端不一致 方案版本字段 用户可见同步状态 风险多次筛选请求覆盖 方案请求序号 防抖导师对我的评价从“能完成分配任务”变成了“可以独立推进一块小业务”。十一、导师指导最有价值的不是答案而是工作方法本文中的反馈是匿名化复合评价不代表真实导师原话。第2周先把问题复现清楚不要看到报错就改代码。我开始提交完整复现步骤、日志和环境信息。第5周页面能运行不等于需求完成要考虑异常、旧数据和测试。我开始把异常状态和回归范围写入需求任务。第8周不要在组件里堆业务规则离线队列应有幂等和过期策略。我完成了业务层、数据层和 UI 层拆分。第11周独立负责模块还要能提前暴露风险并协调联调。我建立了每周风险清单和接口变更记录。十二、团队协作我的成长不只来自代码这张图是团队合影场景示意不是真实企业或真实员工照片。实习后期我越来越意识到模块负责人需要做大量“非编码工作”与产品确认需求边界与服务端确认字段和错误码与测试确认验收场景在评审中解释方案发现风险后及时同步记录变更跟踪缺陷复盘发布问题。一次接口字段变化如果没有及时同步可能让客户端、测试和文档同时返工。主动沟通不是“打扰别人”而是在减少团队整体成本。十三、一次失败我没有提前暴露接口风险第10周服务端计划调整巡检状态字段。我认为改动不大没有立刻通知测试同事。联调时才发现测试数据仍使用旧枚举缓存中存在旧值统计页面没有兼容文档没有更新。虽然最终完成了修复但版本验证被推迟。我的复盘结论是技术上能兼容不等于协作上没有风险接口变化必须同步影响范围需要明确负责人和截止时间变更记录要可追踪模块负责人不能只盯自己的代码。十四、转正答辩我怎样证明自己能独立负责我的答辩没有从“我学会了哪些 API”开始而是围绕五类证据。14.1 业务交付完成的需求负责范围验收结果上线或测试版本。14.2 代码质量Code Review 意见重构记录测试覆盖缺陷关闭。14.3 性能和稳定性弱网场景离线队列列表加载请求覆盖日志定位。14.4 团队协作接口联调风险同步文档复盘。14.5 未来计划继续补齐 ArkTS 并发深入 ArkUI 性能学习发布和监控承担更完整业务域。十五、转正答辩的15分钟结构第12分钟项目和职责介绍业务场景、团队分工和本人负责范围。第37分钟成长里程碑按 Bug 修复、小需求、离线同步和独立模块四阶段讲述。第810分钟一个技术难点重点展示离线队列、幂等、缓存和弱网处理。第1112分钟失败复盘说明接口变更沟通不足及改进方法。第1315分钟未来计划说明转正后的30-60-90天目标。十六、我的转正心得转正不是“实习期间没犯错”我曾经担心答辩时展示失败会影响评价。导师告诉我团队并不期待实习生没有问题而是看你是否能及时发现、诚实说明、完成改进并避免重复犯错。转正评估更关注是否可以稳定交付是否遵守工程规范是否能接受反馈是否能说明技术取舍是否能提前暴露风险是否有持续成长空间。“没有犯错”往往只意味着任务难度不够或者问题没有被看到。十七、给准备进入鸿蒙生态企业实习的同学几点建议17.1 第一周先学工程不急着学所有平台能力先跑通环境、日志、分支、测试和构建流程。17.2 修 Bug 要建立证据链问题现象、复现条件、日志、根因、修复和回归必须完整。17.3 每个需求至少准备三种状态成功、失败和异常边界。17.4 Code Review 不是否定评审意见是团队在把个人代码变成可维护工程。17.5 记录每天的贡献转正答辩不应靠记忆临时拼接。17.6 不要公开企业内部信息项目可以匿名化描述但不能展示未经授权的源码、数据、客户和员工照片。十八、成长的真正标志从“有人告诉我做什么”到“我知道怎样把事情做完”实习第一周我需要导师告诉我去哪里看日志、怎样复现问题、提交前检查什么。第十二周我已经能够接收一个需求澄清边界拆分任务识别风险设计状态完成实现补充测试联调验收关闭问题输出复盘。这并不意味着我已经成为资深工程师而是意味着我开始具备初级工程师最重要的能力可预测地完成一块工作。十九、总结这段实习经历让我真正理解了“从 Bug 修复到独立负责模块”的含义。它不是代码数量增加也不是从改一行代码变成写几千行代码而是工作闭环逐步完整修 Bug 时建立证据开发需求时考虑异常提交代码时考虑评审设计模块时考虑维护联调时考虑团队交付之后完成复盘。HarmonyOS 和 ArkTS 是我进入项目的技术工具但让我获得转正机会的是更通用的软件工程能力问题定位、分层设计、测试意识、风险沟通和持续复盘。“毕业季 · 鸿蒙同行”对我来说不只是毕业后找到一份工作而是第一次从学生项目走进真实团队学会对代码之外的结果负责。转载自https://blog.csdn.net/u014727709/article/details/163001158欢迎 点赞✍评论⭐收藏欢迎指正
