fangang
- 浏览: 881204 次
- 性别:
- 来自: 北京
-
最新评论
-
Junjing：
非常感谢楼主的分享，受益匪浅！我是一位从业务规划和运营转需求分 ...
我们应当怎样做需求确认：评审与签字确认会 -
kersky：
感谢楼主的辛苦输出，半天看完了整个系列。对于一个转从开发转需求 ...
我们应当怎样做需求确认：评审与签字确认会 -
DEMONU：
必须要顶
谈谈软件开发的那些事儿 之 软件开发的轮回 -
dripstone：
非常感谢楼主，用了大半天的时间，一口气读完了需求分析阶段。好多 ...
我们应当怎样做需求确认：评审与签字确认会 -
Codepoe：
做了一些开发，看了楼主的文章，我深有感触，为自己的做法找到了理 ...
我们应当改变我们的设计习惯
文章列表
毫无疑问，系统重构是一件如履薄冰、如坐针毡、你必须时时小心应对的工作，你就像走在钢丝上的人，每一步你都必须要保证正确，一个不经意的失误就可能让你万劫不复。尽管如此，只要你掌握了正确的方法，即使站在钢丝 ...
软件，自从被我们开发出来并交付使用以后，如果它运行得好好的，我们是不会去修改它的。我们要修改软件，万变不离其宗，无非就是四种动机：
1.增加新功能；
2.原有功能有BUG；
3.改善原有程序的结构；
4.优化原有系统的性能 。
第一种和第二种动机，都是源于客户的功能需求，而第四种是源于客户的非功能需求。
软件的外部质量，其衡量的标准就是客户对软件功能需求与非功能需求的满意度。它涉及到一个企业、一个软件的信誉度与生命力，因此为所有软件企业所高度重视。但是，就在所有企业高管把软件外部质量放在高于一切的高度的同时，软件内部质量却长期为人所漠视。企业没有保证软件内部质量的措施，甚至因为需要赶工而肆 ...
以往我们在重新设计一个系统时，总是喜欢大布局。全面地整理系统需求，全面地分析系统功能，再全面地设计系统、开发、测试。这样一个过程往往会持续数月，花费大量的工作量。但是，不到最后设计出来，谁都不知道会不会存在问题。这就是“大布局”的弊病。
正因为如此，软件大师在讲述系统重构时总是强调，系统重构应当避免大设计，而应当尽量采用一个一个连续不断的小设计。这就是我们所说的“小步快跑”的设计模式。
小步快跑体现出了敏捷软件开发的特点——简单与快速反馈。不要想得太多了，活在今天的格子里，因为你永远不可能预知今后会发生什么。所以，做今天的设计，解决今天的问题，完成今天的重构，让明天见鬼去吧。要知道，简单对于 ...
当我们开始系统重构的时候，不是着手去修改代码，而是首先建立测试机制。不论什么程序，只要是被我们修改了，理论上就可能引入BUG，因此我们就必须要进行测试。既然是测试就必须要有一个正确与否的评判标准。以往的测试，其评判的标准就是是否满足业务需求。因此，测试人员往往总是拿着需求文档测试系统。
与以往的代码修改不同，重构没有引入任何新的需求，系统原来什么功能，重构以后还是这些功能。因此，重构的测试标准就只有一个，就是与之前的功能完全保持一致，仅此而已。
然而在许多经典的重构书籍中，大师们总是建议我们首先建立自动化测试机制，这已经被我在无数次实践中证明是不现实的。要知道我们现在重构的是一个遗留系统，它 ...
前面我们提到了，面对软件工业时代的到来，我们的软件企业陷入了一种更深的迷茫之中，一种“后有追兵，前有悬崖，进退两难”的境地。后有追兵：面对维护了数十年之久的大型遗留系统，我们到底改还是不改？不改，面对越来越多的需求变更，我们维护的成本越来越高，变更变得越来越困难；面对不断涌现的新技术，使我们的系统显得越来越丑陋与落后；面对越来越多的竞争者，使我们面临着被市场淘汰的风险。前有悬崖：原本运行得好好的软件系统，凑合一下还可以运行几年。一不小心改出问题了，企业立马就歇菜儿了，面对大量的用户投诉，企业四处救火，竞争对手趁火打劫，这是任何软件企业都不能承受的巨大风险。难倒真的“熊掌和鱼不能兼得”吗？真的没有 ...
我常常感到幸运，我们现在所处的是一个令人振奋的时代，我们进入了软件工业时代。在这个时代里，我们进行软件开发已经不再是一个一个的小作坊，我们在进行着集团化的大规模开发。我们开发的软件不再是为某个车间、某 ...
我是怎样改善遗留系统的呢？这里给大家卖个关子，6月14日我会借助火龙果这个平台免费给大家讲课，破解遗留系统改善之道，到时候一定要来哟！
相关链接：http://www.uml.com.cn/communicate/ex_soft_refactor.asp
本讲座关注5个问题：
1.为何遗留系统维护越来越困难？
2.遗留系统都有哪些问题导致软件质量下降？
3.重构方法是怎样一步一步改善遗留系统的？
4.运用重构方法是怎样让遗留系统能够拥抱变化？
5.实践重构改善遗留系统应当注意什么？
本讲座讲解以下内容：
1.分析目前遗留系统的特点与面临的问题
2.演示一个遗留系统逐步退化的过程
3.一步一 ...
《大话重构》免费送书活动开始啦
- 博客分类：
- 杂谈
我的新书《大话重构》免费送书活动开始啦！参与方式：
一.进入该活动并免费试读本书：
http://bbs.51cto.com/viewthread.php?tid=1104445&page=1&extra=#pid5624458
二.在该活动中完整回答以下四个问题的读者可获得抽奖机会：
1、你自认为你的编程水平是：A初级 B中级 C高级 D不好说，但别人都叫我大师
2、你在平常工作中是否进行重构：A经常 B有时 C几乎从不
3、这本书从目录和试读上看，你感觉怎样：A任督二脉通了 B很有收获 C呵呵
4、就目录而言，你认为哪几章最有用？如果还有所欠缺，你认为还应该增加什么 ...
我的新书《大话重构》终于要出来啦！这是一本讲咱程序员应该怎样开发高质量代码的书，它用大量精彩的故事，讲解高质量的代码是怎样一步一步开发出来，其设计的过程、心理的历程、遇到的问题、解决的思路……
这是一本解惑的书，它通过故事向你阐述许多深邃难懂的设计难题；这又是一本故事会，它将那些枯燥的技术问题通过故事娓娓道来。它让你告别游击队转变为正规军，远离劣质代码走向精妙设计，真正明白专业级的软件开发是怎样的，真正明白重构是怎样一步一步进行的。
你也许会问，设计高质量的代码跟重构有什么关系呢？为什么你一边在谈高质量的代码设计，一边又在谈重构？其实我们一直在谈高质量的代码，它已经成为许多人的梦想，但似乎总 ...
中国五千年文化造就了我们诸多的性格，其中之一就是好大喜功，这尤其反映在中国的软件产业。不错，我们确实拥有数量巨大的网民，拥有无与伦比的庞大市场与用户需求，但这并不足以让我们的步入世界领先行列。在巨大的 ...
前面我们谈到了功能扩展对维护一个软件的巨大作用。实际上，正是因为功能在不断地扩展，才使得我们的很多软件质量在下降。因此，如何进行功能扩展，我们不得不察。每当新功能到来的时候，不用急急匆匆就开始编码，我 ...
在所有关于软件维护的故事中，功能的扩展是一个永恒的话题。正因为软件系统需要功能的扩展，需要新功能的加入，才使我们的编程需要那么多的设计。可以说，正是因为新功能的扩展，使得原有的系统质量下降；正是因为软件质量的下降，才使我们需要进行深入的分析与研究，制订设计原则，总结设计模式；正是因为要解决软件质量下降的问题，经过一番艰苦卓绝的摸索过程，我们才认识到系统重构才是解决该问题的最佳方案。
然而，事情总是这样的，每个系统当我们进行初次的设计时，设计思路、程序结构总是比较完美的。可是当初次设计结束后，我们在日后的维护中，开始往系统里添加新功能时，系统开始不完美了，甚至开始出现问题了，新增的功能总是或多或 ...
前面我们用了那么多示例讨论了代码复用。毫无疑问，几乎所有人都明白代码复用的重要意义，知道要写好代码必须要合理地复用代码。然而，曾经有一份真挚的感情放在你面前你却没有珍惜，那就是你应该复用代码了。等你失 ...
但假如被合并的代码所在的类具有某种并列关系，甚至是同一个父类下的多个子类，或者同一接口的多个实现类，则我们可以采用继承的方式解决代码复用的问题。
具体做法是这样的，第一步还是整理原有的代码，通过比较， ...
以上是对一个对象中各函数间的代码复用。另一种情况是这被比较的两份或者多份代码不在同一个对象中，这应该怎么办呢？我们可以采用的办法比较多，首先一种比较直观的办法就是运用“抽取类”将共同的部分抽取到一个工具类中，为其它各类所调用。比如，看看这个例子：
我们有个遗留系统在大量地方需要获取当前服务器时间，该功能在过去版本中这样写：
Date now = new Date();
后来JDK升级以后该方法被废掉了，所有获取当前时间的代码都要被改成这样：
Calendar calendar = Calendar.getInstance();
Date now = calendar.getDate();
但 ...