编程六月定律

上周,我被迫对一个很老的项目做一些修改。麻烦是,当开始着手时,我真的记不清这个项目究竟有多老了。

这实际上是我使用Codeigniter实现的第一个MVC项目。打开项目文件后,很多东西都让我头晕。首先,没有版本控制,第二,没有注释。

WTF

读起代码,我的“F*CK/分钟”的值一直冲破屋顶。

项目里面的Model很少。Controller层有大量重复的代码,View层肥大的令人毛骨悚然。我相信View层里的逻辑实际上比Model层和Controller层的加起来都要多。

我该为此感到羞耻吗?

答案是NO。(如果是的话我也不会写这篇博客里。)

为什么不?

因为有个六月定律。六月定律说的是,每个程序员都应该回头看看自己6个月前写的代码,并且应该会唾弃当时写的那些代码。

这就引出了本文的重点:如果你是个程序员,当你看6个月前写的代码时,如果发现跟现在写代码的水平一样,请别写了,你应该学习一些新东西了。

这就是为什么当我看到以前的代码写的奇丑无比时反而很高兴的原因。非常高兴。这说明我进步了。所以,与其为那些丑陋的代码感到羞耻,不如高兴的接受它们,这意味着你在成长。

[英文原文:The six months rule ]
分享这篇文章:

15 Responses to 编程六月定律

  1. 消失风雨中 says:

    是不是有点绝对了呀?如果是写一个非常复杂的功能或软件的话,也许是这样,但是如果只是写一个非常简单的功能的话,应该不是这样的吧!

  2. 忧郁 says:

    这也能叫文章,瞎写什么呀

  3. 优优 says:

    的确是这个道理。经常回过头来看看以前写的代码,发现那个时候真是幼稚,却以为自己写的很好。所以,程序员们,请不要装逼,现在你自以为正确和牛逼的,过段时间,你自己回头看看,会发现多么可笑和幼稚。学会谦虚,不断学习。。。。

  4. Eric Wang says:

    你要知道, 影响 程序质量 的因素里, 人本身的素质 比 技术能力 甚至更重要,
    所以 有的人写一辈子代码都很烂, 有的人从一开始写代码就尽量让代码易读好看,

  5. 徐风子 says:

    『如果你是个程序员,当你看6个月前写的代码时,如果发现跟现在写代码的水平一样,请别写了,你应该学习一些新东西了。』

    汗颜呀…… 除了最开始编程前2、3年,中间偶尔有一段时间。 其他时间要想达到这种标准真的好难!

  6. yulaurence says:

    挺有道理的。 但人是有惰性的, 国内公司的压力比较大, 需要最快时间去实现demo, 拿下单子, 更看重业务领域模型相关的积累。 相对的, 技术层面上, 若时效性不高, 并发压力不大, 数据冗余不是很在乎, 沿用半年前的烂代码, 还是有存活空间的。

    此外, 技术的学习进步, 不仅仅是程序员个人的事情, 更是公司需要思考的事情。

  7. Lewis says:

    一般来说我对因兴趣而开发的个人项目比较注重结构设计和代码层次的分离,对代码本身的兴趣可能会高于对项目本身的兴趣。如果是公司的项目则不会这么注重了,只求功能的完成,原因有三:
    1. 任务繁重,功能实现的计划表可以排到明年;
    2. 协作困难,每个参与者都有个人的编码方式和设计模式,为了保险起见,复用代码十分正常,除非有一个靠谱的技术主管,否则还是自己维护自己这一块的代码更好;
    3. 需求变更频繁,而且每次变更都可能涉及整个业务流程,因此有大量的逻辑代码都是在后期直接追加到原位置的,而且一般来说为了方便都不全盘修改源代码,最终导致代码越堆越多

  8. wocow3 says:

    挺好的,另一种思考问题的角度

  9. 小白 says:

    来唱反调的:
    你六个月后的 Hello world 还能有多少进步?
    难道每本讲编程书都在六个月后过时了吗?

  10. 郭佳赫 对这篇文章的反应是很实用

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据