大四刚到公司实习，开发任务很少，大部分工作就是改bug,优化代码。听听各位大佬日常改代码的经验

当然是改代码难，好比，一个是你自己从头做一份蛋炒饭，另一个是煲仔饭要你改成蛋炒饭，你说哪个难？

如果你写的是狗屎 那写代码难

如果别人写的是狗屎 那改代码难

感兴趣的话可以关注一下我的专栏，会写一些计算机方面的东西~

z?

zhuanlan.zhihu.com图标

对新手来说从头开始写比较难，改别人的代码通常只需要改很少的地方，或是把原来的部分代码复制粘贴再修改，然后跑一跑测试一下结果就ok。至于你要修改的代码以前写得好不好、你复制以后重复度高不高，管不了那么多，满足功能最重要。

对老手来说自己从头写比较简单，因为自己经验丰富知道怎么写，而且对别人的代码未必满意。

一般来说，读代码改bug更容易一些，因为多数情况下都是比较简单的bug，并且只需要读懂相关的几处代码就可以改好bug了，只是局部要求。可能几天就修复完一堆bug了。

例如 开源软体 wifidog 源代码大约一万行，准备应用，测试有bug，例如内存泄露，有内存重复释放，无法处理一些特殊情况，如设备网关地址正在初始化，获得空地址的情况，上行介面地址未分配或正在分配中，上行介面掉线重新上线，介面地址变化了等等情况下有bug，修复完主要bug只花了2周时间，就达到了商用标准。

认真写代码需要对从头规划，需要对全部代码框架和自己负责的模块完全理解，一些 corner case ，看上去很普通的需求，要做好的话，也很考验作者的功力。需要既兼顾全局，有大局观，又能深入微观，写大量琐碎的代码块，还要反复重构，因为很难一次把所有代码以最佳实践的方式表达出来，大量代码的重构不可避免，重构改善代码的质量。开发项目往往以数月时间才能完成。

例如，最终由于 wifidog 有一些定制化开发要求，以及还有少量内存泄露未定位影响稳定性，创建和析构多线程开销过大，去年决定从头弄一个自研C++版本出来，大约花了几个月时间，才开发测试完成一个功能更多，性能更优，没有内存泄漏的版本。项目写代码开发很花时间。

另外，万事都有特例，代码原生产者的技术水平和当时开发任务安排紧不紧，公司开发流程是否正规等等，如果当年就是拼凑著上线，什么规划都没有，没有文档，没有注释，各种bug层出不穷，当年的开发人员已经全部辞职跑路，那种典型的垃圾山的话，读代码改bug真的很难，因为你不知道对方的脑洞有多大，当时为什么要用这么奇怪的写法，变数名没有什么规律，要连猜带蒙这个变数是干什么用的，读代码要累死人的那种，也许重新开发更容易一些。

别说改别人的，就是改自己的都难啊，o(╥﹏╥)o

前段日子改一段代码花了三周时间，偶发的ping不通链路坏掉，涉及的整个链路处理的代码有个几万行，好多信号处理编解码看也看不懂，也不想看，因为状态机太复杂，函数太长，好多函数上千行，一堆查表的代码都不知道咋算的。

我第一周周末大概框定了问题，但是我周五没有很好的描述它记笔记就出去玩了，玩了两天回来周一已经全忘了，在另外一个轨道上打了一大片log, 恶心了自己一个礼拜，这种问题单步工具没有屁用，打log 几十秒就能打几G, 到周末我只好加班了，周日我在哪里眯缝著眼一边喝酒一边看log忽然想起我一周前框定的范围，我又试了几下确认应该有个状态机是不好的，我就回家了，周一白板上画了下推了下改了三行代码就完事了。

这种不是太难复现的不算难的了，有些仨月也改不过来，有些人干脆就加个功能让它崩了自己再重启。

刚好有篇文章写了类似的问题（读代码而非改代码，不过原理是一样的，改之前肯定要先理解清楚代码，然后才能动手），摘录一部分 姜太公：如何阅读代码

为什么读代码很难

读代码并不比写代码简单，阅读代码的困难源自以下几个方面。

首先，实现一个功能，存在多种具体的实现方式。即使是同一个思路的演算法，最终产生的代码也有多种表现形式，不同代码的风格、变数的命名、if嵌套或者for/while的选择都会影响最终呈现的代码。阅读代码时，人脑充当了编译器的角色，不过通常意义上的编译，而是反向从代码的表现去理解代码的意图。眼睛看著代码，根据它在做什么反向推导它要做什么。更复杂的是，不仅要看静态的代码，还要在头脑中构造一个运行时的状态转换。

举个简单的例子，看到下面这段代码，你能分析出它在做什么吗

void do_somthing(){
x := A[(hi + lo) / 2]
i := lo - 1
j := hi + 1
loop forever
do
i := i + 1
while A[i] &< x do j := j - 1 while A[j] &> x
if i ≥ j then
return j
swap A[i] with A[j]
}

上面的代码其实是快速排序的一次partition，很多人都熟悉，可能还比较容易猜得到它的目标。确定了一个目标，实现代码有好有坏，但是给出一个能正常工作的代码并不算很困难。例如实现一个排序功能，对大多数人来说可能都不是问题，但是从代码去反推行为反而更困难，写代码是顺著自己的思路，读代码是顺著作者的思路。

其次，一段代码的输入并不只是其参数，输出也不只是返回值。代码执行过程还会依赖各种外部状态：全局变数、进程外数据甚至网路上的数据。阅读代码时不仅要关注眼前的一段代码，还要考虑各种外部数据，考虑这些数据的结构以及能够对数据施加的各种操作，还有每种操作所导致的数据变化。代码运行过程中也会修改外部状态，阅读代码的过程中不仅要关注代码中自身数据的状态变化，还要考虑对外部数据的修改。

最后，实际的项目代码通常不是上面快速排序这么简单单纯，而是包含了复杂的概念和数据结构，众多的模块，各种各样的介面，冗长复杂的数据转换逻辑。每一段代码并非独立存在，而是作为一个更庞大整体的一部分。最要命的是代码里通常充斥著各种神奇补丁，以解决某个特定场景特定时间特定输入数据时才会遇到的问题，除非你能从其他渠道（例如注释或cvs log），否则想破脑袋也没法理解为什么这些代码的意图（别忘了读代码的目的就是分析意图）。

当然，有些代码由于作者能力问题，写出来的代码完全不具备可读性，这种情况不在讨论之列。

当然是改，每个项目每个人的设计思路不一样啊。

取决于任务目标，例如：

任务1: 调整应用的字体大小

  • A 直接修改一个应用的字体大小
  • B 重写做一个应用来满足对于的字体大小

任务2: 业务需求变更，对几年前的一个功能模块重构

  • A 在原来很多人维护的模块基础上重构。
  • B 自己重新设计，重写代码。

看那坨更香

改代码难，写别人容易看懂的代码更难

最容易的就是改bug了，新人都是先安排改bug。

改bug为啥说容易呢？因为你几乎可以不懂任何业务，框架，对著测试用例把开发环境搭建起来复现bug就可以进行下一步工作了。无需培训立即上岗。

通过改bug来看你水平，水平可以的转正开发新功能，水平高的提前转正（比如我，当然我提前转正也跟会和领导勤反馈又听话有关）。

水平不行的，就一直改bug吧。我们那有个女生进来几年了，就没开发过新功能。

不是难不难的问题，主要是自己写代码可控，改别人的代码，甚至改自己很久之前写的老代码，不大可控。

改代码难

改自己代码都难-。- 有时大的思路错了，宁愿重写都不想改

虽然他已经离开了公司，但程序里处处都有他的身影。

自己写代码就是拉一坨屎，改别人的代码就是把别人的屎吃下去再拉出自己的屎。

改别人代码要看对方的代码水平与注释文档

如果没有注释没有文档……我觉得改自己的毕竟容易

改代码难

就像番剧一样，第一部是最好画的，前面的一般只管自己爽，留下无数坑，后面的就要来填了

我是菜鸡新手，我觉得自己写比改难几个量级感觉要考虑的东西太多了

推荐阅读：
相关文章