选择做一个程序员，你后悔过吗？

关于问题选择做一个程序员，你后悔过吗？一共有 2 位热心网友为你解答:

【1】、来自网友【华为云开发者联盟】的最佳回答：

分享一个菊厂大神的故事：

不知道从什么时候起，亲戚朋友问我能不能买到打折手机时，我总会脱口而出：打折手机没有，打折基站，了解一下？说完自己都觉得有点无厘头，但似乎又是那么顺理成章。我想，无线的十年，写代码可能已经深深融入了我的生命，因为它不仅见证了我的青春年华，也见证了我不认怂的那些时刻。

这条路，我打算一头走到黑了！

程序员这辈子谁没遇到过几个 bug

爱上编码，其实很偶然。在没有钱只有才的大学岁月里，在当时追女生还停留在手写情书的年代，我用 OpenGL 写了一个 3D 的迷宫游戏，在迷宫的关键路径上放上了女神的美照。一个小小的游戏，帮助我的兄弟打败了 99%的直男，成功追到了学校的女神，我也成了我们那届男生眼中的“代码大牛”。初尝成功的滋味，让我觉得干软件这行，还行。

2007 年底，我成功应聘到华为无线，在上海接首个落地成都研究所的产品 UMTS Access Point，因为之前的游戏开发工作经历是顺风顺水，让我觉得基站软件编码没什么难的，但是进公司的第二个月，脸就被打得啪啪响。当时还是瀑布式开发，严格遵循预先计划的需求、分析、设计、编码、测试顺序进行，一个环节阻塞，所有人都得停下来。我负责的是系统广播消息的整改优化，当联调到我这时，DSP（基带子系统）却死活收不到我发的系统消息。我不停走读代码，却连续两天两夜毫无头绪，全部门 100 多号人因为我已经阻塞了 48 小时，部长不停在我座位后边转悠，盯着我屏幕那焦灼的眼神，都深深地刺痛着我，什么时候，我从别人眼中的大牛，变成了拖后腿的人了。

48 小时后，部长觉得不能再这么枯等下去，安排了部门技术大牛来帮助我梳理思路，重新走读代码，终于找到了问题根因，原来在从 CPU 向 DSP 发送消息时，需要提前 20ms 发送，我当时过于自信，不知道信令之间有严格的时序关系，发送和接收是有延迟的，想当然认为优化成实时发送，不是更节约时间，更有效率么，于是不假思索地修改成了我心目中“更美”的代码。但就是这个“更美”，实际变成了 Bug，阻塞了我们的联调。问题终于解决了，但就在那一晚，我人生中第一次失眠了，我甚至开始怀疑自己，是不是不适合干通信行业？

第二天，我找到部长，向他诉说我内心的煎熬和自信的崩塌，谁知道部长神情了然，说：“一个程序员，谁这辈子没遇到过几个 Bug 啊，都是自己亲手埋的雷，那就死活都要亲手把它挖出来。下一次，一定要由你自己来挖。”我俩相视一笑，突然间，我就释怀了。

经过这次挫折，我对做大型通信软件有了新的认识和了解。年轻的时候多少有些自负，自认为自己的代码水平不错，但实际上软件领域有太多的未知，一山更比一山高，不太懂的地方，不能想当然，得多向前辈请教。代码也不是越“美”就越好，在网运行的每一行代码都是多代华为人不断完善的结果，从表面上来看，这些代码离美还有一段距离，但是从业务场景和功能完备性上讲，它通常考虑比较周全，出问题的概率很低。

愈曲折，愈见大风景。

没有解决不了的 bug，只有没找对方法的我们

带着对编码的敬畏，后来的我一直在业务组长期深耕。在自己熟悉的业务领域，无论特性开发，还是小的模块重构，都能游刃有余，主导的模块重构还获得过公司 E2E 质量奖，但也许正因为太熟悉了，太游刃有余了，感觉激情正在一点点地褪去。就在我以为自己会麻木，甚至动了别的心思的时候，一个扩展眼界的机会，找上门来了。也正是这次机会，让我坚定了继续在软件世界遨游的信念。

当时，根据公司要求产品线需要发起 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 个月的时间，我心无旁骛全力以赴开发新架构，用老婆的话说，简直到了“魔怔”的地步，吃饭在想，走路在想，睡觉也在想，几乎没有一刻停止过思考。还记得最后一天，当新架构原型基本完成，上板性能压力测试远远超出预期，这样的结果，让我觉得，过去种种，值了。部门也终于信心十足，决定用我的新架构来启动业务层的适配修改。

2017 年 5 月，上海通信展，TUE 被集成在了汽车上，观众通过 5G 网络，在展厅遥控 30 公里外的汽车，实时控制。远程驾驶可以成为未来租车和共享汽车行业服务这种自动驾驶的补充，例如用户将车开到偏僻的场所，租车公司无需人力开回，只需利用远程驾驶就可召回、调度车辆。我和项目组的兄弟们通过网络直播，看到汽车被顺利遥控的那一刹那，我突然发现，原来我们的通信软件已经走在了世界科技的最前沿，我们正在构造未来智能化时代的通信基础，这种无与伦比的成就感和自豪感，瞬间盈满了内心。