fangang
- 浏览: 861408 次
- 性别:
- 来自: 北京
-
最新评论
-
Junjing：
非常感谢楼主的分享，受益匪浅！我是一位从业务规划和运营转需求分 ...
我们应当怎样做需求确认：评审与签字确认会 -
kersky：
感谢楼主的辛苦输出，半天看完了整个系列。对于一个转从开发转需求 ...
我们应当怎样做需求确认：评审与签字确认会 -
DEMONU：
必须要顶
谈谈软件开发的那些事儿 之 软件开发的轮回 -
dripstone：
非常感谢楼主，用了大半天的时间，一口气读完了需求分析阶段。好多 ...
我们应当怎样做需求确认：评审与签字确认会 -
Codepoe：
做了一些开发，看了楼主的文章，我深有感触，为自己的做法找到了理 ...
我们应当改变我们的设计习惯
我的论坛
作为优秀开发人员，重构应当成为一种习惯，自然而然地运用重构的开发模式，自然而然地在优化和调整我们的代码。它首先要求我们掌握重构的开发模式，就是“小步快跑”的开发模式，运用“两顶帽子”的设计顺序，去开发 ...
- 2014-08-04 10:03:44
- 浏览 4176
- 评论(2)
下面我们来盘点一下系统重构工具箱里都有什么，也就是看一看系统重构到底都有哪些方法。系统重构总是在不同层次上调整我们的代码，因此重构方法也就分为了多个层次。从总体上看，重构方法分为以下几个层次：方法的重构、对象的重构、对象间的重构、继承体系间的重构、组织数据的重构与体系架构的重构。
前面那个例子我们可以清楚地看到方法的重构过程。方法的重构往往发生在一个对象的内部，是对一个对象内部的优化。从这个例子中，我们首先看到了增加注释、调整顺序、重命名变量、进行分段等操作，这些虽然不是什么重构方法，却是我们进行前期准备的常用技法。随后我们将通过注释分段存放的各个代码段提取出来，形成单独的函数。这种重构方法被 ...
- 2014-07-27 21:55:56
- 浏览 2700
- 评论(0)
慢慢来，这里只是先给不同了解的朋友扫扫盲，介绍重构方法，后面会有大量篇幅探讨重构的测试问题，详见大话重构主页
- 2014-07-27 21:35:40
- 浏览 2827
- 评论(2)
经过前面的一番讲解，相信你已经对系统重构有了一些初步的认识了。一切的一切仿佛在告诉我们，系统重构总是与需求变更无关。但此时，我不得不告诉你这是真实的谎言。
我们的软件系统总是处于一种变化之中，并且往往是一种由浅入深、由易到难的过程。但是，当系统复杂程度发生变化时，我们应当及时调整我们的设计，来适应新的变化。然而我们没有做到这一点，所以我们的系统维护变得越来越困难。要解决我们的问题必须通过系统重构去优化我们的程序，使之重新适应业务需求。毫无疑问，需求变更才是我们去重构的主要动因。
然而，系统重构要求我们不能改变软件的外部行为，这意味着在重构的过程中不能为软件添加任何新功能，重构仿佛与变更无关。 ...
- 2014-07-22 08:46:09
- 浏览 2348
- 评论(0)
毫无疑问，系统重构是一件如履薄冰、如坐针毡、你必须时时小心应对的工作，你就像走在钢丝上的人，每一步你都必须要保证正确，一个不经意的失误就可能让你万劫不复。尽管如此，只要你掌握了正确的方法，即使站在钢丝上也能如履平地，而这个正确的方法，就是那些被证明是正确的重构方法。说了那么多，你一定开始好奇，系统重构到底都是一些什么方法呢？行了，我也就不卖关子了，我们来看看重构方法工具箱里都有些什么东东。
系统重构要求我们对代码的每一步修改，都不能改变软件的外部行为，因此在系统重构中的所有方法，都是一种代码的等量变换。重构的过程，就好像在做数学题，一步一步地进行算式的等量变换。经过一系列等量变换，最终的结果虽 ...
- 2014-07-22 08:37:06
- 浏览 2827
- 评论(2)
软件，自从被我们开发出来并交付使用以后，如果它运行得好好的，我们是不会去修改它的。我们要修改软件，万变不离其宗，无非就是四种动机：
1.增加新功能；
2.原有功能有BUG；
3.改善原有程序的结构；
4.优化原有系统的性能 。
第一种和第二种动机，都是源于客户的功能需求，而第四种是源于客户的非功能需求。
软件的外部质量，其衡量的标准就是客户对软件功能需求与非功能需求的满意度。它涉及到一个企业、一个软件的信誉度与生命力，因此为所有软件企业所高度重视。但是，就在所有企业高管把软件外部质量放在高于一切的高度的同时，软件内部质量却长期为人所漠视。企业没有保证软件内部质量的措施，甚至因为需要赶工而肆 ...
- 2014-07-09 10:58:44
- 浏览 2220
- 评论(0)
以往我们在重新设计一个系统时，总是喜欢大布局。全面地整理系统需求，全面地分析系统功能，再全面地设计系统、开发、测试。这样一个过程往往会持续数月，花费大量的工作量。但是，不到最后设计出来，谁都不知道会不会存在问题。这就是“大布局”的弊病。
正因为如此，软件大师在讲述系统重构时总是强调，系统重构应当避免大设计，而应当尽量采用一个一个连续不断的小设计。这就是我们所说的“小步快跑”的设计模式。
小步快跑体现出了敏捷软件开发的特点——简单与快速反馈。不要想得太多了，活在今天的格子里，因为你永远不可能预知今后会发生什么。所以，做今天的设计，解决今天的问题，完成今天的重构，让明天见鬼去吧。要知道，简单对于 ...
- 2014-07-07 17:47:04
- 浏览 2650
- 评论(0)
当我们开始系统重构的时候，不是着手去修改代码，而是首先建立测试机制。不论什么程序，只要是被我们修改了，理论上就可能引入BUG，因此我们就必须要进行测试。既然是测试就必须要有一个正确与否的评判标准。以往的测试，其评判的标准就是是否满足业务需求。因此，测试人员往往总是拿着需求文档测试系统。
与以往的代码修改不同，重构没有引入任何新的需求，系统原来什么功能，重构以后还是这些功能。因此，重构的测试标准就只有一个，就是与之前的功能完全保持一致，仅此而已。
然而在许多经典的重构书籍中，大师们总是建议我们首先建立自动化测试机制，这已经被我在无数次实践中证明是不现实的。要知道我们现在重构的是一个遗留系统，它 ...
- 2014-07-02 19:06:12
- 浏览 3664
- 评论(0)
你关键是还没有理解什么是重构。毫无疑问，重构与迭代开发都是敏捷开发的重要组成部分，敏捷开发将他们有机地组织在一起，你中有我、我中有你。但重构不等于迭代开发，它们各自描述的是敏捷开发的两个方面：迭代开发是一种项目组织形式；重构则关注于代码应当如何修改与维护。
- 2014-06-30 08:39:30
- 浏览 13122
- 评论(33)
前面我们提到了，面对软件工业时代的到来，我们的软件企业陷入了一种更深的迷茫之中，一种“后有追兵，前有悬崖，进退两难”的境地。后有追兵：面对维护了数十年之久的大型遗留系统，我们到底改还是不改？不改，面对越来越多的需求变更，我们维护的成本越来越高，变更变得越来越困难；面对不断涌现的新技术，使我们的系统显得越来越丑陋与落后；面对越来越多的竞争者，使我们面临着被市场淘汰的风险。前有悬崖：原本运行得好好的软件系统，凑合一下还可以运行几年。一不小心改出问题了，企业立马就歇菜儿了，面对大量的用户投诉，企业四处救火，竞争对手趁火打劫，这是任何软件企业都不能承受的巨大风险。难倒真的“熊掌和鱼不能兼得”吗？真的没有 ...
- 2014-06-29 04:19:07
- 浏览 4397
- 评论(0)