今天在开发人员的周例会上,大家吵的不可开交,我们在讨论在敏捷开发中是否应该将“故事点(story point——敏捷开发中的一种工作量单位)”分配给bug和代码整理工作
重构的方式千差万别。当在分析一个很大的方法时,我会首先看一下它的整体结构,心里对如何分解它有了一个初步的感觉。里面的条件判断代码块通常都会是我认为有问题、可以入手的地方。
重构是一种对软件进行修改的行为,但它并不改变软件的功能特征,而是通过让软件程序更清晰,更简洁和更条理来改进软件的质量。代码重构之于软件,相当于结构修改之于散文。每次人们对如何对代码进行重构的讨论就像是讨论如果对一篇文学作品进行修订一样无休无止。
最近我遇到了一位以前公司的同事。他提到了数年前我在那个公司曾经开发过的项目。他说这个项目现在已经变成了“职业杀手”。基本上,任何接触过这个“职业杀手”项目的人最终都会离开这个公司。如果公司想让名下的程序员人数>0,唯一的办法就是花数月时间完全重构这个系统。
重构代码很危险,它会给测试工作增加巨大的负担。除非你的程序需要重构,一定不要轻易重构代码。我这里所说的并不是把一个for循环改成while循环,或把一个StringBuffer改成StringBuilder,我说的是大动作,例如重写
我并不是在教唆你写烂程序。 例如,昨天,我绞尽脑汁想要写出一段程序,结果发现,它比我想象的要困难的多。这是一种 […]
我把程序里这样的一个特征描述为恐怖地下室:黑暗,陈旧,神秘,性能不稳定但对整个程序操作至关重要的代码之躯就躺在里面。恐怖地下室难以清理,不好维护——有些东西只有团队中最资深的、最中坚的工程师才能处理的了,其他人唯恐避之不及。