企业文化访谈第7期 责任心，就是我写代码的第一原则
前言
“责任心，是我写代码的第一原则。”从杭州到广州，从零起步参与公司信息化建设，李军始终相信：技术人的价值，不在于写出多复杂的代码，而在于用代码真正解决业务难题。2019年加入素芸，他带着对跨境电商行业的好奇与“从0到1”的冲劲，成为数字化浪潮中一名笃定的建设者。
您是如何与素芸结缘的，当时加入的初心是什么？
我叫李军，现任数字信息中心的高级Java工程师。主要负责集团的数字化信息系统开发以及其他的报表等支撑性工作。我是2019年1月2号加入素芸的。当初从杭州离职，落脚来到广州，开始最简单的想法是在白云区内找一家通勤时间可以接受的公司，当时波哥跟我沟通目前公司信息化水平基本处于一片荒芜，有很多从0到1的机会，公司业务也处于高速增长，急需IT人员加入解决问题，而且跨境电商行业整个流程链路是很复杂的，所以我也对跨境电商行业产生了兴趣，加入公司一起战斗。
回顾在公司的经历，您觉得哪些事情对您的个人成长帮助最大？
最有成就感的地方就是用我们的技术手段帮助业务人员解决实际问题，推动数字化转型。例如在白云办公区的财务核算项目，当时急需解决平台财务核算账单问题，由于数据量太大，excel又非常吃电脑内存，财务人员跑着跑着，可能电脑就卡死了，搞得整个核算期就像战壕一样，时间特别紧迫。当时天天跟PAT团队死磕Amazon平台和eBay平台业务数据和核算规则，不到一个月就做出了第一版的核算程序，第二个月核算期就直接用上了，然后再此基础上又不断迭代，完善核算规则，提升账单的准确率。现在回想来当时那一段时间确实挺辛苦的，但是成功后的那种成就感，满足感还是挺刺激多巴胺的。
遇到的比较大困难和挑战是什么？
说到遇到的挑战，我印象最深的是Creeks订单履约系统刚上线那次。
当时公司要从老的eBayHelper迁移到自研系统，我负责数据迁移和初始化这部分。听起来是个常规任务，但刚上线的时候就出事了——迁移脚本跑着跑着，报错了。
那会儿压力特别大：业务等着用新系统发货，老系统马上要停，数据不能丢，业务不能断。报错原因还不清楚，日志信息也有限。
我第一反应是：先别慌，搞清楚是什么问题。 我暂停了迁移，开始逐行看日志、分析报错。最后定位到原因：eBayHelper里有些历史数据格式不规范，比如日期字段是空的，但新系统的模型要求必须有值，一校验就中断了。
这个问题在预演阶段从来没出现过，因为测试数据是“干净”的。生产环境的“脏数据”，成了我们最大的隐形杀手。
定位到问题后，我和产品、业务方一起沟通了几个方案：是去修复历史数据？还是改迁移脚本？最后我们决定迁移脚本加容错——对异常数据做兼容转换，同时全部记录下来，迁移完再人工核对补录。
那一段时间基本是连轴转：改脚本、用生产数据备份反复验证、盯着迁移日志……最后总算顺利切完，业务没受影响，数据也没丢。
这件事让我深刻体会到两件事：
第一，生产环境永远比测试环境复杂，任何迁移类项目，都要先用真实数据预演；
第二，问题本身不可怕，可怕的是慌了手脚。只要冷静下来，一步一步拆解，总能找到出路。
在您的工作中，有没有哪件“小事”或某个细节，特别能体现您的工作态度和背后的价值观念？
一是团队人才培养 、跟产品沟通怎么把业务需求转换为可落地的方案，以及生产环境的运维保障。
二是我记得有一次Angela跟我领导沟通为什么我们公司没有一个表扬信箱之类的东西，她要写10封表扬信给我，哈哈。就是这种得到同事的认可，让我觉得我的主动性，认真的态度挺值的。
在提升工作效率、质量、客户满意度等方面，您有什么经验分享吗？
在面临重要工作或挑战时，支撑和驱动您的核心动力来源于那些方面？
责任心，主人翁精神，这个项目或者任务既然由我负责，那我就不仅仅是把它“做完”，而是要对最终的结果负责到底。作为开发人员，我写的每一行代码、设计的每一个系统，最后都会影响到业务同事的使用体验，甚至影响到消费者的下单流程。所以我心里始终绷着一根弦：绝不能让系统在我的环节掉链子。 哪怕是一个很小的功能，只要是我交出去的，我就有义务保证它稳定、好用。这种“凡事有交代，件件有着落”的责任感，驱动着我主动去多想一步、多做一层。
您认为工作中最重要的品质是什么？您是如何在工作中践行这些品质的？
换位思考。我们是一个团队、部门协作共同完成项目的，有时候只站在自己的角度考虑问题，会带来视野上的局限性，甚至“扯皮”。换位思考让我切换不同的视角看问题，在当下做出相对合理的决策。
例如：写代码的时候，我也会习惯性地站在下游同事的角度想一想。测试同学接手我的代码，好不好测？日志清不清晰？运维同学部署的时候，配置复不复杂？有没有文档？
所以我养成了一个习惯：哪怕进度紧，也要写好注释和文档，接口设计尽量规范。 因为我知道，如果我不这么做，后面接手的人就得花双倍时间来猜我的逻辑。换位思考其实就是“己所不欲，勿施于人”——我不希望接到别人难懂的代码，那我就要保证自己交出去的东西是清晰的。这种默契能让整个研发链条跑得更顺。
您如何看待“善良、互信、热爱、极致”在您工作中的体现？
善良：为下一个接手的人留一盏灯，我的理解： 在技术团队，善良不是嘘寒问暖，而是不给自己以外的任何人制造麻烦——包括未来的自己。
互信：用每一次交付积累“靠谱”的账户，我的理解： 互信不是靠喝酒吃饭得来的，是靠每一次说到做到、每一个闭环反馈攒出来的。
热爱：解决问题时的那股“上头”劲儿，我的理解： 热爱不是天天把技术挂嘴边，而是遇到难题时，你心里冒出的第一反应是“有意思”，而不是“真烦人”。
极致：对自己交出去的东西“认账”，我的理解： 极致不是完美主义，也不是无限内卷，而是对自己交付的每一个结果负责到底。
例如去年有一次线上系统深夜报警，某个核心接口响应突然变慢。说实话，当时第一反应确实是想“明天再说吧”。但躺下之后翻来覆去睡不着，脑子里一直回放各种可能性：是数据库索引失效了？还是有慢查询把连接池占满了？
凌晨一两点我还是爬起来，登录跳板机开始排查。
找到问题的时候已经快天亮了——是一个新上线的功能引入的全表扫描。修复、验证、看着监控曲线回落，那一刻的成就感，真的很难形容。
遇到压力和挫折时，您通常人会如何调整心态和应对？
第一步：先“止损”，让自己冷静下来。
就像系统出故障，第一件事不是追究谁写的Bug，而是先把服务拉起来。对我来说，遇到特别大的压力时，我会先给自己一个“冷静缓冲区”——可能是下楼走一圈，或者戴上耳机听十分钟歌。先让情绪过去，再让理性回来。
第二步：做“根因分析”，但不做“责任认定”。
冷静下来后，我会像排查线上故障一样，问自己几个问题：
问题的本质是什么？（是能力不够？是沟通没到位？）
我能控制的部分是什么？
下一步我能做什么？
第三步：拆解成“可执行的小任务”。
大的挫折往往让人无力，是因为它太模糊了。我会把它拆碎——今天先做A，明天沟通B，后天调整C。一旦事情变得具体，焦虑感就会下降。
在您取得成绩的过程中，团队或者其他同事给予了您哪些支持和帮助？
感谢产品、测试同学——他们是系统的“守门人”和“体检员”
我们开发人员有时候容易“亲儿子滤镜”——自己写的代码，怎么看怎么顺眼。
所以特别感谢产品、测试的同事们。
测试同学每次提Bug，我都当成是“系统体检报告”。有时候她们比我还细心——一个边界值没覆盖到、一个异常场景没考虑到，都是她们帮我兜住的。她们是我交付前的最后一道防线。
还有产品经理，夹在业务需求和技术实现之间，两头受气。但每次我们说要重构、要还技术债，她们都尽量帮我们去争取空间和时间。
所以如果要问“成绩是怎么来的”，我的答案是：不是我一个人跑得快，是这条流水线上的每一个人，都在自己的环节守住了质量。
您的工作方式和态度对周边的同事或团队氛围产生了怎样的影响？
说实话，我不是那种特别外向、特别会活跃气氛的人。所以我一直觉得，我对团队氛围的影响，可能不是“带动”，而是“托底”。
怎么说呢？就是我经手的事，大家不用再操心。
比如我们团队有个习惯，重要的项目上线前，大家都会填写发布记录，做checklist，互相检查一遍。但时间久了，有同事会说：这块是李军负责的？那应该没问题了，过吧。
这句“应该没问题了”，对我来说就是最高的评价。靠谱这件事，是会传染的。 当一个人做事让人放心，其他人也会不自觉地对自己手里的活儿更上心——因为谁都不想成为那个“掉链子”的人。
所以我希望自己像一颗“定心丸”：有我在的环节，大家可以少一分焦虑，多一分安心。
对未来有什么期待和规划吗？
期待在业务理解上走得更远一点。
我前面提到过“换位思考”，这个习惯让我越来越意识到：技术不能自嗨，代码最终是要为业务服务的。 同样一个功能，理解业务背景和不理解业务背景，做出来的东西完全不一样。
所以我希望未来能更深入地理解公司的业务逻辑——不只是等着产品给需求文档，而是能主动去问：为什么要做这个？用户真正的痛点是什么？有没有技术手段能帮业务做得更好？
比如James他们做新渠道拓展的时候，如果能更早地介入，用数据和技术帮他们预判风险、提效增速，那技术的价值就不只是“支撑”，而是“驱动”了。
我的目标是：成为一个“懂业务的技术人”。 当业务同事提到某个痛点时，我能第一时间想到：“这个我可以做个工具帮你解决。”——这种状态，是我觉得最有成就感的。
结尾语
从一行代码到一套系统，从一个人靠谱到一群人安心，李军用责任心筑起信任，用换位思考连接协作。在他看来，技术从来不是终点，服务业务、驱动增长才是。未来，他希望做一个“懂业务的技术人”，在每一次交付中，让技术更有温度，让改变真实发生。
请先 登录后发表评论 ~