不想做软件开发了,为什么想做软件开发( 二 )


也正是这次机会,让我坚定了继续在软件世界遨游的信念 。当时,根据公司要求产品线需要发起VxWorks切换Linux的hert 8.0性能攻关,每一年增加的10万 代码,会成为产品性能的包袱,所以每一年的性能攻关,都是项目的重中之重,但是平台切换和性能优化了多年,能想到的、该用的招式都用过了,大伙有些黔驴技穷了,怎么才能让性能KPI继续往上升呢?尤其是在4个月内要提升XX%,能按期达标吗?部长找到我,问我愿不愿意接受这个高难度的挑战,支援项目组完成性能优化,支撑至少每秒1500次链路建立 。
这是我从未涉及的性能优化领域,我,行吗?老婆给我打气,“这,不就是你正在寻找的,突破的机会吗?拿出你当年运动员的精神来,坚持、突破!你要相信自己,你可是‘百米飞人’哦 。”这里要说明一下,我从小学就参加校田径队,一直到高中,从一个只是爱运动的小破孩,硬是练到了国家二级运动员,练成了研究所的“百米飞人” 。
有了老婆这个坚强的后盾,我欣然进入了攻关组,并利用所有的业余时间,从各种渠道、多个维度,补充相关知识的学习 。同时,也向产品线架构部专家请教攻关方向,向底层平台专家请教消息通信优化方向,向已经成功优化的部门请教Ans1编解码优化方法等等,一切可以想到的,有一线希望的方式方法,我都主张尝试一遍 。从业务流程、业务算法、模块部署、热点代码、编译器选项等多个维度同时进攻,4个月后,我们如期顺利攻下了这个山头 。
一时间,我百感交集,我认识到软件的路更宽了,曾经的我单纯认为软件开发不就是垒代码吗?谁让代码更简洁实用,谁就是大牛,其实不然,它更是合作,是探索,是智慧的碰撞 。当我们费尽千辛万苦,齐心协力冲破“暴风骤雨”时,我心中的迷茫如乌云散开,我感受到了沐浴阳光的爽快与自信 。这让我更加坚定了软件开发的选择,没有解决不了的Bug,只有没找对方法的我们 。
主管被我大胆的想法吓到了5G TUE(测试终端)落地成都,部门要成立软件架构优化组,鉴于我以往的表现,部门希望我担任技术负责人,从一开始就解决未来可能出现的性能问题 。我先后分析了号称世界最快的“并发框架Disruptor”,公司外研所开发的JSF,以及面向异构系统的OpenCL等各类并发框架后发现,其实取各家所长,开发一套全新的并发调度框架,更加有好处,能让TUE/CPE在生命周期内,都不用再考虑性能问题 。
这个架构可以结合TUE/CPE高负载,超低时延,多板多框共存,产品硬件单板每年更新,以及多产品OneTrack的业务特点,达成每秒百万级任务处理的性能规格 。我把全新开发并发框架这个想法跟部门主管简单说了下,主管吓了一跳,“这个想法太大胆了 。” 原计划只是优化小改,现在却要完全重写,我们的软件实力是否足够?风险到底在哪里?能不能按时交付版本?性能会不会变得更差?会不会影响公司5G整体发布节奏?一连串的问号,让他的心里完全没底 。
我却坚信这个新框架如果做出来完全可以“碾压”原有架构,而且新架构会让整体更简洁,就像那张著名的印度街道电线图,只有重新铺设,架构才不会腐化,更有利于后面的开发和维护 。但主管仍然不同意,认为风险还是太大 。我想到架构大师Till Adam曾经说过,优秀的架构师必须首先是一个推销员 。于是我整理了新架构的各种优缺点分析,开始向主管、MDE游说,从进度分析、性能分析、架构预演、风险预判等维度,一一解决了他们的疑虑和担心 。
经过2周十来次密集的技术PK,部门终于同意,兵分两路,我一个人先开发架构原型,另一组人在原有架构上优化,谁先验证成功,提升更大,就用谁的架构去适配修改产品代码 。是时候用上以前积累的知识和技能了 。我心中燃起一团火,只想着要拼尽所有将想法变成现实 。3个月的时间,我心无旁骛全力以赴开发新架构,用老婆的话说,简直到了“魔怔”的地步,吃饭在想,走路在想,睡觉也在想,几乎没有一刻停止过思考 。

推荐阅读