中程在线-重构-卓越程序员修炼之道(笔记1了解重构)

如果下面有任何一句话，是你想说的，那么，请来学习重构吧

（1）重构束缚了我的设计！

（2）重构？改别人的代码啊...改坏了我不负责！

（3）重构啊...那要重新测试了吧...

（4）重构？岂不是白花我的钱？

 

1.1提到重构，大家会有一个想法立即冒出：设计和重构到底什么关系?

 

重构肩负一项特殊使命：它和设计彼此互补。

没有重构，你就必须保证预先做出的设计正确无误，这个压力太大了。

如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。

　　　　　　　　　　　　----《重构-Martin》P66

 

1.2没有系统学习过重构的人，还会有以下两个疑惑：改坏代码？重新测试？

 

请先来学习重构，因为这些都是对重构无知而产生的担忧（后面会讲解代码的22种坏味道，使用那些辅助工具发现，修改他们，以及遵循什么样的重构流程），所以，请先跟我学习重构。

 

1.3软件行业潜规则

 

需求是不断变化的

设计是不断变烂的

 

1.4重构的定义

 

重构：对软件内部结构的一种调整，目的是在不改变“软件之可察行为”前提下，提高可理解性，降低其修改成本。

怎么样，是不是从定义上也解释了1.2，重构并不改变软件的可察行为，所以不需要重新测试。

 

2.那些不懂技术的人，常常会一拍脑袋，想出两个加：

 

加人：

他们由1个人，10天搬10个砖头，那么10个人，1天就能搬完了，推出1个人，这个需求要做10天，那么10个人，1天就能搞定这个需求了。

那么请问，1个孕妇，10个月生个孩子，10个孕妇，1个月能生出了孩子么？

 

加班：

一样的道理，1个人，这个需求要做10天，那么，晚上再加8小时班，5天不就搞定了。

我们是人，不是机器。

 

3.勒布朗法则

 

如果团队中出现这样的声音：我们先这样写吧，等以后再改！！！请立即用这一法则

 

稍后等于永不（Later equals never）

 

4.破窗效应

 

没修复的破窗，导致更多的窗户被打破

 

5.代码质量的评价标准

 

价值观：

Cost(total) = Cost(develop) + Cost(maintain)

Cost(maintain) = Cost(understand) + Cost(change) + Cost(test) + Cost(deplay)

所以Cost(maintain)>>Cost(develop)

 

6.什么是好的代码？

 

<敏捷设计原则-Robect C Martin>

第一职责：运行起来所完成的功能，这是模块存在的原因。

第二职责：要和阅读它的人进行沟通，对模块不熟悉的人员应该能够比较容易理解。

第三职责：他要应对变化，因为软件要变化，开发者保证应该尽可能的简单。

 

7.几个思维转变

 

否定功能完成就是code complete。

肯定代码易理解，可维护，才是code complete。

 

否定设计模式精通，算法精通，才是好的程序员

肯定重视源代码，就是好的程序员。

 

8.几个原则

开闭原则。

二八原则。

 

9.代码的坏味道

函数过长

参数过长

Null检查

超多if...else...

switch...case

 

10.其他

UML是多么的烂。