精华内容
下载资源
问答
  • 代码腐化之路

    千次阅读 2013-07-01 13:10:05
    但是细细瞧瞧, 还有不少代码是不错的,依稀能看到漂亮代码的影子,可以想象,当初的架构应该还是优美的,只不过经过了若干程序员之手以后,代码慢慢的腐化了。   07 年做的一个项目也是这样,刚开始的时候设计...

    11年刚进入一个新部门,接手一个老项目,典型的legacy code , 一个jsp 好几千行,那叫一个乱。

    但是细细瞧瞧, 还有不少代码是不错的,依稀能看到漂亮代码的影子,可以想象,当初的架构应该还是优美的,只不过经过了若干程序员之手以后,代码慢慢的腐化了。

     

    07 年做的一个项目也是这样,刚开始的时候设计了一个漂亮的架构,大家都严格遵循规则写代码,很注意维护架构的完整性和一致性,也做Code Review,坚决杜绝 dirty code。 随着时间的推移,项目的进度压力加大,什么原则了,纪律了都抛弃了,实现功能是第一要务, 最后系统变成了一个难于理清的大怪物, 现在大家都盼望着它赶紧退休,推倒重写。

     

    联想到我2010年做的咨询项目,客户是行业的领导者,软件和产品运行在世界各地,原以为代码质量会很不错,进入项目组一看,好家伙,代码够乱的,项目组成员在实现新特性的时候,好多copy&paste , 然后就忙着fix bug 。

    我深入的看了它的代码结构, 隐隐约约的看到最初的一些好的原则,模式隐藏在代码的背后,对照现在的代码,让人无限感慨。

     

    代码腐化之路

     

    新项目来了,大家很happy,有机会从头开始构建一个东西,是很难得地,于是仔细小心的设计架构,定下规矩和原则,约定大家都要遵守,刚开始时运转正常,平安无事。

     

    渐渐的出现了一些新情况,需求变动,时间很紧张, 程序员发现有一个非常直接的办法,可以快速的实现客户的要求, 几天就可以搞定, 但是违背了架构的原则或最初的项目的编码约定, 如果想遵循的话,可能需要花费好几倍的工作量,可能需要几周才能完成,更要命的是,为了实现这个新需求,可能需要对整个架构进行调整, 真的调整了,测试跟不上,风险太大, 怎么办?

    大多数情况下,程序员都经不起诱惑,也扛不住进度的压力, 会用最直接的办法进行快速修改,“管他呢,先实现再说,反正我还记得细节”  ,实际上,改完以后我们又忙着干别的事情去了,过上几个月,自己都看不懂了。久而久之,这些脏代码没有人知道是怎么回事了, 后面接手的程序员就会骂前面的程序员 “这么烂的代码,谁写的!!!???” 

     

    代码就是这么腐化的......

    展开全文
  • 代码腐坏的味道是指在代码之中潜在问题的警示信号。并非所有的坏味道所指示的确实是问题,但是对于大多数坏味道,均很有必要加以查看,并作出相应的修改。 1. 重复的代码 如果你在一个以上的地点看到相同的...

    转自  http://www.nowamagic.net/librarys/veda/detail/1761

    代码腐坏的味道是指在代码之中潜在问题的警示信号。并非所有的坏味道所指示的确实是问题,但是对于大多数坏味道,均很有必要加以查看,并作出相应的修改。

    1. 重复的代码

    如果你在一个以上的地点看到相同的程序结构,那么当可肯定:设法将它们合而为一,程序会变得更好。

    • 同一个class内的两个函数中含有重复的代码段
    • 两个兄弟class的成员函数中含有重复的代码段
    • 两个毫不相关的class内出现重复的代码段

    注意:重复的代码是多数潜在BUG的温床!

    2. 过长的函数

    拥有短函数的对象会活的比较好、比较长。

    • 程序愈长就愈难理解
    • 函数过长阅读起来也不方便
    • 小函数的价值:解释能力、共享能力、选择能力

    原则:每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立的函数中。记着,起个好名字!

    3.  过大类

    如果想利用单一类做太多事情,其内往往就会出现太多的成员变量。

    • 提取完成同一任务的相关变量到一个新的类
    • 干太多事情的类,可以考虑把责任委托给其他类

    注意:一个类如果拥有太多的代码,也是代码重复、混乱、死亡的绝佳滋生地点。

    4.  过长的参数列表

    太长的参数列表难以理解,太多参数会造成前后不一致、不易使用,而且你需要更多数据时,就不得不修改它。

    原则:参数不超过3个!

    5. 发散式变化

    我们希望软件能够更容易被修改。一旦需要修改,我们希望能够跳到系统的某一点,只在该处做修改。如果不能做到这点,你就嗅出“坏味道:发散式变化”或“坏味道:霰弹式修改”。

    发散式变化:一个类受多种变化的影响

    • 数据库新加一个字段,同时修改三个函数:Load、Insert、Update
    • 新加一个角色二进制,同时修改四处

    原则:针对某一外界变化的所有相应修改,都只应该发生在单一类中

    6. 霰弹式修改

    如果每遇到某种变化,你都必须在许多不同的类内做出许多小修改以响应之。如果需要修改的代码散布四处,你不但难以找到它们,也很容易忘记某个重要的修改。

    霰弹式修改:一种变化引起多个类相应的修改

    7. 依恋情节

    函数对某个类的兴趣高过对自己所处类的兴趣,就会产生对这个类的依恋情节,造成紧耦合。

    原则:判断哪个类拥有最多被此函数使用的数据,然后将这个函数和那些数据摆在一起。
    原则:将总是变化的东西放在一块。

    8. 数据泥团

    有些数据项,喜欢成群结队地待在一块。那就把它们绑起来放在一个新的类里面。这样就可以:

    • 缩短参数列表
    • 简化函数调用

    9. 基本型别偏执

    代码中有很多基本数据类型的数据。

    原则:如果看到一些基本类型数据,尝试定义一种新的数据类型,符合它当前所代表的对象类型。

    10. switch惊悚现身

    面向对象程序的一个最明显特征就是:少用switch语句。从本质上说,switch语句的问题在于重复。

    原则:看到switch你就应该考虑使用多态来替换它。

    11. 冗赘类

    你所创建的每一个类,都得有人去理解它、维护它,但一个类没有存在的必要时候,就让这个类庄严扑义吧!

    原则:如果一个类的所得不值其身价,它就应该消失。

    12. 夸夸其谈其未来性

    对未来不可预知的变化考虑的过多,造成系统更难理解和维护。如果应对变化的代码都会被用到,那是值得的那么做;如果用不到,就不值得。

    原则:代码应该满足当前的需求,并留有可扩展的余地。对于未来的变化,既不要考虑的太多,也不能一点都不考虑。

    13. 令人迷惑的暂时成员变量

    有时你会看到这样的对象:其内某个成员变量仅为某种特定的情形而设。这样的代码容易让人不解,因为你通常认为对象在所有时候都需要它的所有变量。

    在变量未被使用的情况下猜测当初设置目的,会让你发疯。

    14. 无用的中间人

    过度使用委托。你也许会看到某个类的接口有一半的函数都委托给其他类,这样就过度运用了。所以,删除无用的中间人。

    15. 狎昵关系

    有时你会看到两个类过于亲密,花费太多时间去探究彼此的private成分。

    原则:过分狎昵的类必须拆散。

    16. 异曲同工的类

    如果两个函数做同一件事情,却有着不同的签名式。

    原则:删除一个,保留一个。

    17. 不完美的程序库类

    库的设计有时会不够好,不那么容易使用,可能还会有那么一点小缺陷。

    工具:

    • Introduce Foreign Method
    • Introduce Local Extension

    18. 过多的注释

    过多注释的代码段,往往都是因为那段代码比较糟糕,散发着一股恶臭。

    原则:当你感觉需要写注释时,请尝试重构,试着让所有注释都变得多余。

    展开全文
  • 你是否遇到过这样的场景呢?Code Review时: A:我在XXX类加了一个新方法来实现..... B:等等,我觉得这个地方应该改一改,blablabla.... ...代码总是随着时间的流逝,需求的增加而逐渐腐化(还有

    你是否遇到过这样的场景呢?Code Review时:

    A:我在XXX类加了一个新方法来实现.....

    B:等等,我觉得这个地方应该改一改,blablabla....

    A:呃,那是以前的代码,所以我没动,我只是在这个类里加了个新方法....


    重读Clean Code,忽然对Bob大叔提到的童子军军规深有感触:“让营地比你来时更干净”。

    代码总是随着时间的流逝,需求的增加而逐渐腐化(还有架构)!我们不希望我们的代码最终成为别人眼中的Legacy Code,正如我们自己接手如同烂泥一样的code base时心头暗骂一样,他们也会在心里问候我们这些始作俑者的十八代亲属!

    一直保持整洁的代码,我们真的做不到么?进度压力,需求膨胀,经验少的队友,blablabla,这些真的是原因么?

    其实,我们只需做很简单的一件事:让营地比你来时更干净!代码每次check in时都比check out时更干净,每个类甚至每个方法都比你留下痕迹之前更干净,哪怕只是重命名一个变量,消除了一点点重复代码,拆分了一个有点长的函数....

    让营地比你来时更干净,营地会越来越干净!

    展开全文
  • 代码腐化之路

    2011-04-15 16:19:00
    但是细细瞧瞧, 还有不少代码是不错的,依稀能看到漂亮代码的影子,可以想象,当初的架构应该还是优美的,只不过经过了若干程序员之手以后,代码慢慢的腐化了。 07 年做的一个项目也是这样,刚开始的时候设计了...

    11年刚进入一个新部门,接手一个老项目,典型的legacy code , 一个jsp 好几千行,那叫一个乱。

    但是细细瞧瞧, 还有不少代码是不错的,依稀能看到漂亮代码的影子,可以想象,当初的架构应该还是优美的,只不过经过了若干程序员之手以后,代码慢慢的腐化了。

    07 年做的一个项目也是这样,刚开始的时候设计了一个漂亮的架构,大家都严格遵循规则写代码,很注意维护架构的完整性和一致性,也做Code Review,坚决杜绝 dirty code。 随着时间的推移,项目的进度压力加大,什么原则了,纪律了都抛弃了,实现功能是第一要务, 最后系统变成了一个难于理清的大怪物, 现在大家都盼望着它赶紧退休,推倒重写。

    联想到我2010年做的咨询项目,客户是行业的领导者,软件和产品运行在世界各地,原以为代码质量会很不错,进入项目组一看,好家伙,代码够乱的,项目组成员在实现新特性的时候,好多copy&paste , 然后就忙着fix bug 。

    我深入的看了它的代码结构, 隐隐约约的看到最初的一些好的原则,模式隐藏在代码的背后,对照现在的代码,让人无限感慨。

     toothpaste

    代码腐化之路

    新项目来了,大家很happy,有机会从头开始构建一个东西,是很难得地,于是仔细小心的设计架构,定下规矩和原则,约定大家都要遵守,刚开始时运转正常,平安无事。

    渐渐的出现了一些新情况,需求变动,时间很紧张, 程序员发现有一个非常直接的办法,可以快速的实现客户的要求, 几天就可以搞定, 但是违背了架构的原则或最初的项目的编码约定, 如果想遵循的话,可能需要花费好几倍的工作量,可能需要几周才能完成,更要命的是,为了实现这个新需求,可能需要对整个架构进行调整, 真的调整了,测试跟不上,风险太大, 怎么办?

    大多数情况下,程序员都经不起诱惑,也扛不住进度的压力, 会用最直接的办法进行快速修改,“管他呢,先实现再说,反正我还记得细节”  ,实际上,改完以后我们又忙着干别的事情去了,过上几个月,自己都看不懂了。久而久之,这些脏代码没有人知道是怎么回事了, 后面接手的程序员就会骂前面的程序员 “这么烂的代码,谁写的!!!???” 

     metallic yarn

    代码就是这么腐化的......

    转载于:https://www.cnblogs.com/imadin/archive/2011/04/15/2017318.html

    展开全文
  • 2011年刚进入一个新部门,接手一个老项目,典型的遗留代码 , 一个jsp 好几千行,那叫一个乱。但是细细瞧瞧, 还有不少代码是不错的,依稀能看到漂亮代码的影子,可以想象...
  • 代码是怎么腐化

    千次阅读 2013-11-22 00:47:30
    新三年,旧三年,修修补补又三年。...会上除了几处明显的代码逻辑错误我发言指了出来外,涉及业务流程以及代码设计的问题,我 大多保持沉默。...回想当年第一版代码出炉时,它...去闻闻,你的代码腐化了没有!
  • 正文经历了几个从商业角度来看或成功或失败的项目,都会发现代码、设计都会慢慢地、在不经意间腐化。而且有一个项目开始的时候,架构是经过精心设计的,也有较为严格的代码规范,并且通过静态代码检查...
  • 写在前面:作者李子昂,阿里巴巴集团研发效能部的第一个算法工程师,目前工作主要方向是代码管理和CI。本文探讨的是:从优化研发交付流程的角度,如何根本上提升研发效能。 先说结论 现在阿里主流的分支开发模式,...
  • 人人都要懂的代码重构

    千次阅读 2020-10-09 15:31:17
    因为代码腐化2.2 为什么代码会腐化2.2.1 破窗效应(Broken windows theory)和惯性2.2.2 技术债务(Technical Debt)2.3 防止代码腐化,重构应该怎么做2.3.1 重构的技术挑战2.3.2 重构的步骤2.3.3 重构的最佳时机2.4...
  • 代码防腐

    2021-03-03 00:16:25
    代码腐化似乎注定的最初:没有谁是不想好好写的。都有一个宏伟的规划,这次一定途中:Code Review 如同“堂吉诃德”一般,根本架不住大批量大批量的修改放弃:躺平了,下次一定如此循环往复...
  • 软件腐化

    2012-11-16 23:07:04
    随着时间的推移,各式各样的修改、新增需求会使软件变得越来越难以维护。...应该是代码的耦合太厉害了。 脆弱性(Fragility) 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。导致这
  • 程序的腐化

    2018-05-28 16:27:28
    代码如同打扫屋子,有句话叫一屋不扫何以扫天下。如果单个的一个模块代码都不能管好,如何成就一个完善的软件系统?今天我们来说说,一个代码模块的代码是如何一步步腐化变质,到最...
  • 架构腐化

    2017-06-23 13:32:12
    转载《架构腐化》 前言新技术层出不穷。过去十年时间里,我们经历了许多激动人心的新技术,包括那些新的框架、语言、平台、编程模型等等。这些新技术极大地改善了开发人员的工作环境,缩短了产品和项目的面世时间。...
  • 这几天网上看到这样一则消息:其实维护过老系统的人,往往都了解,这种情况还是挺常见的。尤其是在一些10年以上的老系统上做修改的时候,因为不断的人员更替,代码腐化很严重。有时候有的开发者就会写...
  • 否则容易造成代码腐化,难于应对后续变化。 识别需求增加与需求的方向变化。 依赖注入、依赖反转应对变化的需求。 重复代码是万恶之源。 注释也是代码的一种重复,常见的随着时间的推移造成代码与注释不一致
  • 谈程序的腐化

    2017-05-10 15:46:16
    代码如同打扫屋子,有句话叫一屋不扫何以扫天下。如果单个的一个模块代码都不能管好...今天我们来说说,一个代码模块的代码是如何一步步腐化变质,到最后程序员都不愿意去维护它,然后要么重构,要么废弃换新模块的?
  • 笔者从事移动开发工作第四个年头,前前后后也接触了不少项目,在项目开发迭代的大背景下,“代码腐化“问题随着时间推移会最终显现出来; 这里不说谈为什么会出现”腐化“问题,因为原因真的很多,而...
  • 软件的腐化之路

    2020-05-03 19:18:58
    软件腐化之路 本文并不是吐槽,而是总结开发过程中软件腐化的各种原因,希望基于此思考如何解决软件腐化的问题. 需求不明确 项目已有第n个版本,现开发第n+1个版本,但是需求不明确,导致可能无法将新需求融入到现有的...
  • 架构腐化之谜

    2017-12-11 09:00:13
    架构腐化之谜 来源:http://www.uml.org.cn/zjjs/201107221.asp 前言 新技术层出不穷。过去十年时间里,我们经历了许多激动人心的新技术,包括那些新的框架、语言、平台、编程模型等等。这些新技术极大...
  • DDD应对运营活动系统腐化实践 原文:DDD应对运营活动系统腐化实践前言 任何人类的设计都会腐化,软件系统也不例外 腐化之谜 随着系统的规模增长和复杂度膨胀,系统会慢慢腐化。 于是改一个很...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,313
精华内容 925
关键字:

代码腐化