Tag Archives: 重构

15 讨论会议

让老妈告诉你如何编程

今天在开发人员的周例会上,大家吵的不可开交,我们在讨论在敏捷开发中是否应该将“故事点(story point——敏捷开发中的一种工作量单位)”分配给bug和代码整理工作

Posted in 批评评论 | 3 Comments
39 Michael Feathers

当一个对象方法什么都没干时

重构的方式千差万别。当在分析一个很大的方法时,我会首先看一下它的整体结构,心里对如何分解它有了一个初步的感觉。里面的条件判断代码块通常都会是我认为有问题、可以入手的地方。

Posted in 技术技巧 | 5 Comments
62 slide-1-728

代码重构方向原则指导

重构是一种对软件进行修改的行为,但它并不改变软件的功能特征,而是通过让软件程序更清晰,更简洁和更条理来改进软件的质量。代码重构之于软件,相当于结构修改之于散文。每次人们对如何对代码进行重构的讨论就像是讨论如果对一篇文学作品进行修订一样无休无止。

Posted in 技术技巧 | 15 Comments
145 一团糟 面条

你需要的不是重构,而是理清业务逻辑

最近我遇到了一位以前公司的同事。他提到了数年前我在那个公司曾经开发过的项目。他说这个项目现在已经变成了“职业杀手”。基本上,任何接触过这个“职业杀手”项目的人最终都会离开这个公司。如果公司想让名下的程序员人数>0,唯一的办法就是花数月时间完全重构这个系统。

Posted in 批评评论 | 2 Comments
243 重构

如何避免重构带来的危险

重构代码很危险,它会给测试工作增加巨大的负担。除非你的程序需要重构,一定不要轻易重构代码。我这里所说的并不是把一个for循环改成while循环,或把一个StringBuffer改成StringBuilder,我说的是大动作,例如重写

Posted in 心得体会 | 1 Comment
84 思考者

写最少的代码,避免给自己找麻烦

软件开发的一个最基本的事实是:我们必须要写代码,但对于这样的一个事实的最大一个误解是:我们的工作就是写代码。

Posted in 批评评论 | 6 Comments
34 1617380

什么是重构,什么不是重构

  有时候,会有程序员跑到我这里说他们不喜欢某个东西的设计,“我们需要给它来个全面的重构”,来纠正里面的错误。哦,哦。这听起来可不是个好主意。而且这听起来也不是重构…

Posted in 技术技巧 | 2 Comments

请修改这段程序,立刻!

  你们正在开发一个新项目,你在一个地方看到一段有问题的代码。错误的处理方式是,“啊,别人写的,我最好别碰它”,“我没有时间去改它——我有自己的事要做”,“如果我修改它,肯定会改出问题”。

Posted in 批评评论 | 11 Comments

好程序需要你写(至少)两遍

最近这些年,越来越多的人开始转向敏捷开发。各种敏捷开发技术并不新鲜,大多是在80 和 90年代发展形成。但只是在最近这些年,程序员和(更重要的是)一些商业顾问,架构师,客户开始变得喜欢和拥抱敏捷开发。

Posted in 心得体会 | 9 Comments

为了写出好程序,有时候你需要先写出烂程序

我并不是在教唆你写烂程序。 例如,昨天,我绞尽脑汁想要写出一段程序,结果发现,它比我想象的要困难的多。这是一种很少见的情况。这段程序应该如何的运行,我已经思考的很清楚,我能够清楚的解释给任何人听,但是,当把思想转化成代码时,我发现自己的才智还不足以完成任务。

Posted in 心得体会 | 12 Comments

代码修整

我们这个行业里有大量的专业术语被使用。不幸的是,我们并没有对每个术语表达的究竟是什么意思达成共识。我经常听到人们误用“重构(Refactoring)”这个词,导致这种编程方法在很多企业里变成可怕的事情而被拒绝采用。怕什么?据我的观察,大部分都是因为错误的使用了这个术语。

Posted in 批评评论 | 3 Comments

程序员最容易犯的几个技术上的错误

请在评论里分享你的想法和经验,因为我们都需要从这些错误中吸取教训。 为钱而编程 如果你对编程不感兴趣,你的代码一定会写的很烂。结果不仅仅你的事业没有任何前途,你的团队也会因此而痛苦不堪。

Posted in 批评评论 | 9 Comments

天堂里没有程序员![漫画]

幸亏我是信马克思的,不担心自己进不了天堂! 查看大图

Posted in 幽默讽刺 | 3 Comments

每个应用程序都有一个恐怖地下室

一个设计人员对于一个成熟的产品要花很长时间才能意识到这个应用程序的用户界面的各个部分并不是一致的稳定可靠。在应用程序不断改进的数年中,会有一些极其重要但又异常脆弱的组件被开发出来,很多其它功能依赖它们。我把程序里这样的一个特征描述为恐怖地下室:黑暗,陈旧,神秘,性能不稳定但对整个程序操作至关重要的代码之躯就躺在里面。恐怖地下室难以清理,不好维护——有些东西只有团队中最资深的、最中坚的工程师才能处理的了,其他人唯恐避之不及。

Posted in 心得体会, 技术技巧 | 5 Comments