#Bug解决

1个月前

以前都给你们讲兵王的故事今天给你们讲一下将军解决超大规模软件研发的故事软件工程从本质上来说就是小房子和大厦的区别，很多AI编程的规模都在小房子的范畴，今天将的是大厦的工程量以及超大规模软件工程管理的事情时间拉回10年前，在上一次创业遇到的最大挑战就是超大软件工程的挑战，那是2015年，我们团队一要做整个桌面环境的重写，还要做国产芯片的底层适配，还要做应用的开发。我们一年总共的项目超过100多个，看板任务超过3万多个，每天最少要搞定100多个任务才能完成目标。这里面桌面的后端，比如电源、磁盘、网络、触摸板、输入法、账户、安全、权限等后端，都要面临前端重写和底层后端极限优化，一些在X86上跑得很好的后端和前端，在国产芯片上要慢20倍，X86秒开的场景，国产芯片要等好几秒才有反应。所以，年初的时候开会，我先聚集公司写代码最厉害的将领，包括技术大牛和丰富研发背景出身的项目经理，大家一起先把大方向讲了，回去和产品经理把所有功能的思维导图画了。研发管理最重要的就是技术、时间、资源和时间规划，很多做研发不行的原因是脑袋是糨糊，糨糊的原因不是研发不懂逻辑和思考，而是做项目的时候，完全不做任务分解，一个项目到底有多少任务，只有非常模糊的方向，而没有清晰的方向。我的要求是，思维导图的分解要细到每个任务可以一天完成，这里不光是模块，还有前端、后端的页面和接口，这样要求的前提是这是锻炼研发项目经理最好的机会，一个项目到底多少时间完成，可以清楚的知道一个项目到底有多少任务，每个自己做大概要多少时间，而且在分析的过程中发现如果分解不了，要不就是带头人对需求的理解模糊，要不就是有技术障碍没有攻克不知道怎么分解。当带头人把任务分解对以后，每个项目都应该像一颗大树一样，非常枝繁叶茂。这时候大家开会对每条任务，没有问题，剩下的事情就很简答，把思维导图导出成看板条目，每天晨会5~10分钟对清楚当天的问题。上面都是研发管理，今天我想分享的是，这种超大规模的软件工程会遇到很多现实的问题，解决这些问题的方法才是值得学习的。 1. 一个bug的锅在多个团队中转，都转了几圈了还下不来，这种问题一般都是bug的根源是链条型的，需要跨越部门，直接按照项目的方式，把bug的前后“犯罪者”都聚到一起才能解决，解决的根本就是要解决链条的衔接型问题。解决这种问题需要领导的魄力，传统的流程不助于解决这种链条型问题 2. 软件工程有一个特点，他的任务数和bug数不会越开发越少，而是会像正态曲线一样，bug数会爬坡，一般是前后端衔接的问题，更大的问题是有架构设计的问题。如果一个架构设计不够清晰，各个模块都只能用，最后就是💩山越堆越夸张，所以，打仗的时候，要经常把牛逼的人拉到一起去审视项目是否有架构性的问题？而没有超大规模的研发管理会恐惧这个爬坡的过程，只要架构对，这个爬坡是非常正常的，等bug到顶峰以后就会进入质量收敛的过程，越开发越稳了 3. 遇到一些疑难的bug，有时候要跳出局部技术问题看全局，产品能否去改设计绕过？因为不同产品使用方式背后的技术实现难度是不一样的，有时候产品轻微改一下，很多障碍就扫除了 4. 一些中层管理者经常抱怨任务太多，人员不好管理，压力太大，其实这时候不要期望有啥绝招，就是抗。就和健身一样，所有阵痛都是在成长的经历，这些经历才是成长成为帅才的必经之路，轻轻松松的经历就没感觉，也没法成长为独当一面的人超大研发管理过程中，最重要的是心态，前期的状态基本上就是马蜂窝的状态，bug超级多；中期主要里程碑和架构设计的检查甚至是产品细节的调整，帮助团队扫清楚障碍，让团队的信心可以扛过正态bug峰；后期主要是功能选择，选择局部的功能的取舍和版本的管理，做不完的下一个版本做，因为特定时间完成一个版本比遥遥无期更重要。好了，喜欢我创业故事的，欢迎点转转发喜欢我们团队的，欢迎购买懒猫微服支持我们，你们的支持是我创作的动力！

#超大规模软件工程 #研发管理 #Bug解决 #国产芯片适配 #团队协作

6个月前

来自 Reddit 一位拥有30多年经验的前FAANG（Facebook、Apple、Amazon、Netflix、Google）高级工程师被一个C++ Bug困扰了4年，花了约200小时却毫无进展。而Claude Opus 4竟然成功地解决了这个问题，并且是唯一能做到的AI智能体。以下是 Reddit 上的帖子： *** Claude Opus 今天帮我解决了折磨我四年的「白鲸」级Bug 背景我是一名拥有超过 30 年经验的 C++ 开发者，曾任职于 FAANG 公司担任高级工程师。我通常是团队里的问题终结者，当其他工程师卡住一周都解决不了问题时，他们来找我，我往往在他们站在我办公室里的时候，就能轻松搞定。但今天，我被 Claude Opus 4 彻底折服了。折磨了我四年的难题四年前，我曾做过一次重构，对约 6 万行的代码进行了重新架构。重构解决了大量问题，但也带来了一个极端情况的 Bug。当某个特定着色器（Shader）以特定方式使用时，这个 Bug 就会显现。以前这个功能是好的，但重构之后，这个特定场景就坏了。过去几年，我断断续续地花了至少 200 个小时想找到原因，但一直无功而返。这个问题非常恼人，但并不是特别紧急，没法完全停下手头的工作专心处理。 Claude Opus 4 的神奇表现今天，我决定用 Claude Code 跑一下 Opus 版本来解决这个难题。我把新旧代码都给了它，告诉它：“去查一查，当年的重构到底是怎么导致这个问题的。” 让我没想到的是，它真的找到了！原来，这个功能在旧架构里之所以能正常运行，纯粹是因为偶然的巧合。重构后的新架构并没有考虑到这个巧合情况，因此就产生了问题。所以严格意义上讲，这并不是简单的逻辑错误，而是新架构的设计本身遗漏了旧版特有的边界条件。整个过程我一共向 Claude 提出了大约 30 个提示，中间重启过一次。之前我也尝试过 GPT 4.1、Gemini 2.5 和 Claude 3.7，都没有任何进展。最终只有 Claude Opus 4 解决了这个困扰我四年的难题。

#FAANG #C++ #Claude Opus #AI #高级工程师 #编程 #Bug解决