昨天,一位老上级邀请我一起吃午餐。当坐在哪里等待上菜时,我们缅怀起早期这个公司的往事。他有一句话让我心里一虚:
啊,你这个判官…我记得当你看到Dan(公司的第一位程序员)写的代码时的样子。你说:“这代码写的真烂,需要重写!”
我恐怕是没有足够的勇气告诉他,我这“代码需要重写”的主张是错误的。不错,我认为这代码写的很乱。但是,据过去历次的经验,我感觉大部分的程序员看着别人写的程序时都会想:这代码写的真烂。事实上,当一个程序员数年后再看自己写过的程序时也会想:这代码写的真烂。也许他们想的是对的;这代码确实很烂。
但是,如果你认为代码需要重写,你将犯下一个低级错误。
公司里有一些想当然的看法会让你可能现在不能认识到这点。大量的不成文的想当然的观点可能会让你无法解释清楚。
我喜欢Joel Spolsky说的关于这种事情的话,有些事情你永远不要去做:
我们是程序员。程序员,在他们自己的心里,是建筑师,当他们来到一个地点,第一件想要做的事情就是:把这地方推平,盖上辉煌的建筑。他们对慢慢的修缮没有兴趣:小修小补,改善,培植花草。
有一种不可捉摸的原因让程序员们总是希望丢掉这些代码、重新再写。原因是他们认为老的代码是混乱的。可是,你会观察到一种非常有趣的现象:他们的判断通常是错的。他们之所以会认为老的代码很烂的原因来自于一个重要的、基本的编程定律:
读代码比写代码要难。
这就是为什么代码很难重用的原因。这就是为什么每个团队喜欢用自己不同的函数来做把字符串拆分成数组操作的原因。他们要写自己的方法,这更容易,更有趣,不需要弄清楚老的函数的工作原理。
根据这种定律必然得出这样的一个结论,你现在可以问一问任何一个程序员,问他们对正在写的程序感觉如何。“乱的不能再乱了,”他们会这样告诉你。“我宁愿把它们都删了重新再写。”
当你招募来了一个程序员,如果他想重写看来工作的不错的程序,你要抵制。他也许会说Java过时了,太慢,Ruby on Rails如何的酷。也许他会向你抛了一大堆专业名称术语。不管他如何做,你要三思而行。
你觉得呢?
额,读得我有点茫茫然、清醒一下再来
有的情况下确实不适合重写。
但如果需要增加新的框架,并且如果重构的话代价和重写一样大,那我觉得大可以重写
有些警醒,不过究竟什么时候可以重写/重构呢?
当代码不能满足需求,并且更改他会影响整个框架的时候。
文中提到的,应该是说不要对工作的正常,但是读起来很烦的代码进行重写。
问题是很多时候在设计上花的时间太少以至于现有框架不能满足功能,再添加新的功能时花费代价太大
国内公司大多比较矛盾,架构上画的时间很少,很快成型,尽快进入编码阶段,编完后发现扩展性不行,然后推倒架构,重新设计,重新编码…………然后无限循环~~~~
领导看不到架构的重要,看到的只是功能的实现和进度的推进,其实我自己也不知道如何解开这个矛盾。也许只能领导们提高自己的水平和看问题的层次才行了~~~而国内缺少的正是这种管理者~~~
多跟领导沟通,多提意见,告诉他们设计的重要性,特别是告诉他们好的构架节约钱,多谈关于资金的问题。不要尽扯技术问题,他们听不懂。
重构能够发现的问题价值大于重写
深有同感
我比较赞同局部重构。我也犯过一些重构代码的错误,造成项目延期等。当然,有些代码整体都很烂,越早停止越好。