回复内容:
是时候祭出这两张图啦!
也许你有很强的编程能力,能驾驭1000行,5000行甚至10000行代码的重写,短时间内可以完成,并且bug不多,但是10万行呢,100万行呢,甚至数千万行呢?个人的能力总是有极限的。
团队的力量呢?2-3个人或许好找,但是去哪里找50-100个愿意去重写代码的人,并且还能保证质量呢?
更难的是,到哪里找到经理或老板愿意等你半年甚至一年不响应需求,不改bug,而是去重写代码,去用一套新代码完成和老代码一样的功能,甚至可能更多的bug。
抛开程序员的完美主义情怀,理性地看待分析旧代码,问自己几个问题:
是不是继续维护的成本真的比重新开发还要高?
是不是新的团队在设计开发能力上比原有团队上了一个台阶?
是不是有一些硬需求在旧代码上无论如何都无法做到?
是不是没有竞争对手在穷追不舍而不能停止更新维护?
是不是重写能提供些杀手级功能压制竞争对手?
分别对旧代码和新架构做下 SWOT分析,看看优势,劣势,机会,威胁都是什么。
旧代码或许在架构,接口设计,变量命名和缩进风格上不如人意,但是它是可以工作的,可以工作的代码意味着解决了很多问题,而这些问题在新重写的代码里并不会因为代码写得漂亮就自动得到解决,仍然要把前辈们踩的坑再踩一遍。
那么是不是就不能重写代码呢?不是,要等机会,看缘分的。
个人认为,如果我上面问的五个问题至少三个问题的答案是“是”,SWOT分析的结果里至少三项是有利于重写的,那么可以说也许缘分来了。
先看懂,一段很难看的代码可能是编程水平问题,也可能是为了避开某个坑所做的妥协,要有耐心,不懂就不动。
看明白了,再根据现有需求做决定,设计上有问题,不能满足需求,那就重写,不要妥协。需求能满足,没严重bug,就是代码乱,那就不要轻易动它,宁可在外边加个wrapper,把它包起来。
从毕业到现在5年时间,接触公司各种以前的N手代码(无任何什么文档),练就一身阅读代码神功,首先大家不要想着怎么去重写之前人写的代码,
有些看起来不是特别美观代码,通常都是各种业务妥协的结果。 重构之前请自己掂量一下时间和自己的能力,没准下一个程序员就想着怎么重构你的代码。
没想到有一篇文章想法和我一样《
抵制代码重写 》
昨天,一位老上级邀请我一起吃午餐。当坐在哪里等待上菜时,我们缅怀起早期这个公司的往事。他有一句话让我心里一虚:
啊,你这个判官…我记得当你看到Dan(公司的第一位程序员)写的代码时的样子。你说:“这代码写的真烂,需要重写!”
我恐怕是没有足够的勇气告诉他,我这“代码需要重写”的主张是错误的。不错,我认为这代码写的很乱。但是,据过去历次的经验,我感觉大部分的程序员
看着别人写的程序时都会想:这代码写的真烂。事实上,当一个程序员数年后再看自己写过的程序时也会想:这代码写的真烂。也许他们想的是对的;这代码确实很
烂。
但是,如果你认为代码需要重写,你将犯下一个低级错误。
公司里有一些想当然的看法会让你可能现在不能认识到这点。大量的不成文的想当然的观点可能会让你无法解释清楚。
我喜欢Joel Spolsky说的关于这种事情的话,有些事情你永远不要去做 :
我们是程序员。程序员,在他们自己的心里,是建筑师,当他们来到一个地点,第一件想要做的事情就是:把这地方推平,盖上辉煌的建筑。他们对慢慢的修缮没有兴趣:小修小补,改善,培植花草。
有一种不可捉摸的原因让程序员们总是希望丢掉这些代码、重新再写。原因是他们认为老的代码是混乱的。可是,你会观察到一种非常有趣的现象:他们的判断通常是错的。他们之所以会认为老的代码很烂的原因来自于一个重要的、基本的编程定律:
读代码比写代码要难。
这就是为什么代码很难重用的原因。这就是为什么每个团队喜欢用自己不同的函数来做把字符串拆分成数组操作的原因。他们要写自己的方法,这更容易,更有趣,不需要弄清楚老的函数的工作原理。
根据这种定律必然得出这样的一个结论,你现在可以问一问任何一个程序员,问他们对正在写的程序感觉如何。“乱的不能再乱了,”他们会这样告诉你。“我宁愿把它们都删了重新再写。”
当你招募来了一个程序员,如果他想重写看来工作的不错的程序,你要抵制。他也许会说Java过时了,太慢,Ruby on Rails如何的酷。也许他会向你抛了一大堆专业名称术语。不管他如何做,你要三思而行。
你觉得呢?
为什么千万不要重写代码?
抵制代码重写
上上周改了一个500行左右的小代码,C语言,全都塞在一个文件里,一堆全局变量,代码重复一大堆(之前那个人不会用sprintf,一份自己实现的atoi复制了三份),功能互相交织,变量名各种一个字母的
然后我给拆成了7个分管不同功能的源代码,有的函数直接重写,改变量名,根据全局变量的范围调作用域,最后都改成了static的文件作用域,加访问接口,顺便中途还被傻x编译器坑了一个多小时
然后发现还不如我自己重新写一个
重写或者辞职。。
慢慢改,一块一块慢慢重写,最终整个重写掉了。
重写
一般是立刻重写,然后一堆bug,解决完发现又是一坨需要重写的烂代码,然后突然明白了它为什么一开始这么烂
一般来说是重写。看下输入输出,大概就明白是干嘛的了,人家写了100行,觉得自己90行搞定就不管了,觉得30行能搞定,果断注释掉重写
Stellungnahme: Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn