2017.12.1 产品代码经手多名程序员BUG查询费劲如何处理？ (1).docx

《2017.12.1 产品代码经手多名程序员BUG查询费劲如何处理？ (1).docx》由会员分享，可在线阅读，更多相关《2017.12.1 产品代码经手多名程序员BUG查询费劲如何处理？ (1).docx（4页珍藏版）》请在第一文库网上搜索。

1、今日话题：产品代码经手多名程序员，BUG查询费劲，如何处理？刚到一家外企，产品的代码很多,经年累月，经多了很多程序员开发出来的。最要命的是注释太少，而且风格不一样。需要加新功能或是有BUG查起来很费劲。请问这种情况应该如何解决？精彩点评：PM圈子1班:学习委员-龙沙:作为一个项目来规划：代码重构项目。然后开始干了。项目评审，如果确实影响效率和安全，那就重构，如果乱七八糟过分了，那就新开发。如果成本限制,那就加班呗。广州PM-新人：从项目管理的角度讲，组织参与过代码编写的程序员重新注释，虽然现在工作量大，但是长痛不如短痛；或者组织超级大牛，重读代码并注释；不能注释,就另外开发，重新编写代码并注释

2、。PM子2班:深圳-pm-豆芽：增加新功能，老代码看的懂的就拿来用，没写注释的帮忙写上，看不懂的就不要动它了，也不要想着别人的代码写的很烂，很垃圾，就手痒去修改，可能到头来，代码你给改好了，产品的业务不能正常工作了，不能好心办“坏事上海-pM有明：我们平台就是这样的现状，2年多了人员换了很多次了，没啥好办法的呀,夕匕东四。1 .找专人负责梳理代码及补注释（代码逻辑层面要求）；2 .补文档，梳理逻辑。3 .统一代码规范，另外定期的做代码走查。4 .交接把控，不能只走形式交接。5 .梳理完成后找测试及业务员把控方向，以免出现失误。（实际业务逻辑层面要求）成都技术波仔：我觉得有几种方式来处理，如果新

3、业务，直接在系统上加自己模块的代码,如果要优化以前的业务。这个在做项目计划的时候，需要预留一定的熟悉老代码的时间，实际需要区开发的人员，在开发之前去吃透以前的业务模块的代码，然后整理成册。以供后人使用，然后再进行开发，开发中所处理的变更，也需要记录起来。当然这种情况属于系统架构不能动的情况，还有就是公司允许你去动架构的，这种没话说，先安排吃透系统各个业务，然后重新做计划，安排架构，重新来一次了。但是一般情况，老大是不允许重新去弄架构的，或许，可以新的模块，使用新的架构，重新部署一套服务，新旧系统通过各种接口互相通信，待老系统功能逐步淡化，新系统逐渐成熟的时候，砍掉老系统。卫生委员仰望星空：1

4、.维护当前版本，架构新版本；2 ,做好加班绩效；3 .每天晚上在会议室、吃饭、工作、讨论到12点；4 .经历二个月的研发，我们采用新框架给公司带来了销量翻备的成果。总结：所以做为一个leader ,以自己的能力是否能想到未来1年的方向，未来业务能不能在我们这边有突破，新框架的培训与代码规范，组一群可以一起挑战的人突破突破在突破。有魄力的拼一把，多有意义。而我带着刚来我们企业的工作人员，就一直主动思考如何把它突破了，而不是不敢动他!PM圈子3班：杭州-PM-Surmountx:这个话题的内容从软件质量的角度来看，集中体现一个质量特性上，可维护性差。为什么导致这个原因，主要有以下原因：1、没有开发

5、规范，没有注释或注释太少，代码可读性差。代码是写给人看的,不是写给机器看的,产品的生命周期中，软件维护的时间远比开发的时间长。2、缺乏软件质量控制过程或者说做的比较差，这样的开发输出成果居然大范围存在3、缺乏产品交付物的输出，产品的生命周期中，换人很正常，频繁的换人也不是没有可能，后来者怎么去学习原来的程序，最好的方式就是从文档入手,比如说需求文档，设计文档，开发文档，测试文档等。项目经理要做的事就是在后面的工作中把前面缺失的工作补上去，针对这个问题场景应该：1、对现有产品存在问题进行分析，归类，看问题是集中在哪里，如注释没有？程序结构差？程序逻辑冗长？某些模块BUG乱飞？根据分析数据来决定如

6、何处理这些问题。2、建立开发规范，后续的产品维护按这个规范来执行。3、如果没有资源做到所有功能输出产品文档，核心产品功能必须有输出物且需要监控输出物质量，并持续更新。成都-技术-JC:注释太少、风格不一致、bug太多，最好的方案就是重构了。在即将倒塌的楼顶再建，会崩塌的，神来了都救不了。确定风格、划分功能块。分配任务按照标准分别重构。模块功能测试、嵌入测试、整体功能测试、稳定性测试等。我做的项目百分之60的时间都在重构。因为新功能的叠加很多时候会导致原有逻辑块不明确。没有什么框架能完全适应后续功能的叠加的。只能拆解重构,因为你不能保证你项目上人会呆很长时间不会离开。人员变动大的，项目根本就维护

7、不了，这种情况。我司之前有个项目就是班长说的这种情况，代码质量差、逻辑复杂、维护成本太高，最后直接推倒重做的。重构都没办法了，框架有问题。当然也看项目和公司具体情况，人员缺乏的话，哈哈。PM圈子4班：郑州-兵：这个问题我最有发言权,我现在就在维护一个08年的项目，到我接手时，已经是第五改造了.使用的是最原始的JDBC+Servleto没有注释,一个方法最长能达到三千行，有的类超过1万行。按照我的经验：1 .如果是这个BUG不是很急，了解一下最原始的需求，重新实现一下,在重新实现时，一定要加注释，如果逻辑复杂彳亍内注释绝对要有。2 .如果很急,配置真实的测试环境，如果配不了，力求最真实，用数据重现BUG场景,然后调试代码，找到问题,解决。3 .如果维护这个项目的程序员资格够高，和公司领导建议重新研发，在建议前，把你的理由组织好，最好能用一些数据来支撑，同时告诉领导，重新研发的各种资源，成本也罗列上。和现在的维护进行对比，然后让领导自行决断。4 .回绝，不修改这个BUG。