软件开发工程师试用期自我评价总结

软件开发工程师试用期自我评价总结一、试用期工作背景与定位本人于2023年2月6日入职杭州云脉数据科技有限公司，担任中级软件开发工程师，编制隶属于平台技术部-交易履约组，直接汇报对象为平台技术部副总监王戎。试用期目标合同编号YMRD-2023-02-06-01中约定：在6个月内独立完成“履约结算平台2.0”核心模块的设计、编码、单测与灰度发布，并达到线上缺陷率≤0.3‰、接口P99延迟≤120ms、代码覆盖率≥80%三项硬指标。入职当天，HRBP张澜完成OKR系统录入，将上述指标拆分为Q1、Q2两季度，权重各占50%，季度考核结果影响转正评议。二、业务与系统全景梳理2.1业务链路还原履约结算平台支撑公司B2B电商交易闭环，链路为“商家发货→物流签收→平台放款→资金结算→发票开具”。其中放款节点依赖第三方支付通道（支付宝、微信、银联），结算节点需对接金蝶K3Cloud，发票开具对接航信&百旺。平台日均单量约4.2万，峰值出现在双12当天38万，结算金额峰值9.7亿元。2.2系统架构现状系统采用SpringCloudAlibaba技术栈，注册中心Nacos2.2.0，网关SpringCloudGateway3.1.4，熔断Sentinel1.8.6，持久层MyBatis-Plus3.5.3，缓存RedisCluster6.2，消息Kafka2.8，任务调度XXL-JOB2.3.1。结算核心服务deploy在阿里云ACK集群（K8s1.24），Pod规格4C8G，HPA策略CPU>60%或QPS>800时扩容，最大副本30。灰度环境独立命名空间gray，通过Istio1.15做流量泳道隔离。三、试用期关键任务与交付3.1任务1：结算单状态机重构背景：原状态机采用硬编码if-else，导致新增状态需改动6处代码，平均交付周期5人日。目标：引入状态机引擎，实现配置化，交付周期≤1人日。方案：1.选型：对比SpringStateMachine、Squirrel、Cola-StateMachine，最终采用Cola-StateMachine（轻量、无持久化侵入、性能高）。2.领域建模：与业务方共创，收敛出11种状态、15种事件、22条转换规则，输出《结算单状态机领域模型V1.3》。3.代码落地：定义状态枚举`SettlementStatusEnum`、事件枚举`SettlementEventEnum`；使用Cola的`StateMachineBuilder`在应用启动时动态注册规则，规则存储于Nacos配置中心，格式为JSON数组，支持热刷新；在`SettlementDomainService`中注入`StateMachine<SettlementStatus,SettlementEvent>`，通过`fire(event)`驱动状态流转；单元测试采用JUnit5+AssertJ，覆盖正常、异常、并发场景，共142条用例。结果：灰度发布0.5%流量运行14天，无异常；新增“部分结算”状态需求，仅修改Nacos配置，0.5人日完成，业务方满意度评分由7.2提升至9.1。3.2任务2：放款接口性能优化背景：双12压测放款接口P99延迟达420ms，远超120ms指标。目标：P99≤120ms，TPS由1.2k提升至3k。方案：1.profiling：使用阿里Arthas的`trace`命令定位热点，发现80%耗时在`RSA2验签`+`数据库insert`；2.验签优化：将RSA2改为支付宝推荐的`AES+RSA`混合加密，减少CPU耗时65%；3.数据库优化：分库：按user_id%64分64库，单库数据量由6千万降至900万；分表：放款主表按年月二级分表，索引由`(user_id,status)`改为`(user_id,status,create_time)`，减少回表；连接池：HikariCP最大连接数由50调至200，开启`prepStmtCache`，`cachePrepStmts=true`，`prepStmtCacheSize=500`；4.缓存预热：通过XXL-JOB每日凌晨3点跑批，将当日预估放款用户预加载到Redis，Key格式`loan:avail:{user_id}`，TTL=36h；5.压测：采用公司自研压测平台“CloudHammer”，100并发阶梯增压，持续30min，最终P99=108ms，TPS=3.4k，满足目标。3.3任务3：代码质量与工程治理制度落地：1.分支策略：基于GitFlow，强制`main`分支保护，合并需MR+2名Reviewer+CI通过；禁止`forcepush`，违规一次扣绩效5分；2.代码规范：采用阿里《Java开发手册》2022版，P3C-PMD插件绑定在Mavenvalidate阶段，阻塞打包；3.静态扫描：SonarQube9.9规则集含公司自定义的“金融敏感信息硬编码”规则，阻塞阈值：Bug≥1或Vulnerability≥1或CodeSmell≥20；4.单元测试：引入JenkinsPipeline模板`pipeline-library@1.4`，在`mvntest`后自动上传覆盖率到Sonar，覆盖率<80%时Pipeline失败；5.灰度发布：必须走“三级灰度”——gray1%→10%→50%→100%，每级运行≥24h且错误率<0.1%方可晋级，否则一键回滚；6.缺陷复盘：线上缺陷需在24h内提交“缺陷复盘报告”，模板含“现象、根因、复现路径、修复方案、横向排查、后续Action”，部门周会Review，连续两次出现同类缺陷启动“红榜”通报。四、跨团队协作与知识沉淀4.1与财务中台对接财务中台由财务数字化部维护，接口文档使用自研“YAPI-Plus”。因金蝶K3Cloud科目映射规则频繁变动，双方约定：以OpenAPI3.0规范描述接口，变更diff通过Git管理；任何字段变更须提前3个工作日发“接口变更通知邮件”至组内所有人；采用契约测试，使用SpringCloudContract，由我方提供producertest，财务方消费；最终交付的`finance-adapter`模块在三个月内经历7次规则升级，零联调失败。4.2技术分享与赋能1.3月28日举办“状态机引擎实战”分享，采用腾讯会议+录屏，时长52min，会后匿名评分4.9/5；2.输出技术博客3篇，发布于公司Confluence《平台技术部知识库》，累计PV2,300；3.指导两名初级工程师（邵宇、陈蓉）完成“结算单分片批处理”需求，通过结对编程+每日1:1review，邵宇已能独立处理线上告警。五、数据化成果与指标达成指标项试用期目标实际达成数据来源系统线上缺陷率≤0.3‰0.21‰Sentry接口P99延迟≤120ms108msAliyunARMS单元测试覆盖率≥80%87.4%SonarQube需求交付及时率≥90%95.8%Jira代码评审通过率≥98%100%GitLabMR六、自我不足与根因剖析1.安全敏感度不足：4月17日白盒扫描发现一处“SQL拼接”遗留代码，虽无实际注入风险，但违反公司《应用安全红线管理办法》第3.2条，被安全部记一次黄牌；根因是早期需求排期紧，直接复用1.0代码未走安全Review；2.多线程编程经验欠缺：在实现“结算单并发拆分”时，对`CompletableFuture`线程池拒绝策略理解不深，误用`DiscardPolicy`，导致灰度环境丢失3条任务；后续改为`CallerRunsPolicy`并补充告警；3.业务视角局限：与物流组对接“逆向退款”场景时，仅关注结算侧状态，未识别出物流“拒收返件”节点对结算金额的影响，导致需求评审后二次变更，增加1.5人日；反思后建立“业务全景时序图”模板，强制在需求澄清阶段输出。七、改进方案与落地计划7.1安全能力补齐1.参加公司“安全开发训练营”第二期（6月5日-6月9日），每日完成OWASPTop10实战靶场，结业目标分数≥90；2.在结算服务引入`mybatis-sql-inject`检测插件，CI阶段自动跑全量SQL，阻塞时长>5s的SQL语句；3.建立“安全ReviewChecklist”，含9大项47子项，MR模板中必须勾选，Reviewer需逐条确认。7.2并发编程强化1.通读《Java并发编程实战》第二版，输出读书笔记1.5万字，7月15日前完成；2.基于公司“云真机”环境，手写4种自定义线程池策略，对比压测，形成《线程池调优手册V1.0》；3.在下一需求“结算批量补偿”中采用`ForkJoinPool`+`CompletableFuture`组合，目标单机并发提升至5kTPS。7.3业务洞察提升1.每月至少旁听一次业务部门月度经营分析会，记录财务、物流、运营痛点，建立“技术-业务”映射表；2.与产品经理共建“需求价值量化模型”，从收入、成本、风险、体验四维打分，技术方案必须回应该模型，否则打回需求池；3.输出《交易履约业务白皮书》首版，9月30日前完成，作为组内新人必读材料。八、转正后工作展望1.技术规划：主导“履约结算平台3.0”云原生升级，全面迁入阿里云PolarDB+RocketMQ5.0，目标成本降低30%，峰值性能提升50%；2.团队建设：担任平台技术部“Java进阶小组”组长，每双周组织一次深度分享，年度培养2名高级、1名资深工程师；3.个人成长：报考软考“系统架构设计师”，11月考试，获取证书后申请公司技术专家认证，享受技术津贴；4.创新项目：基于eBPF+O