- 浏览: 1757473 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (528)
- java基础 (35)
- oracle (23)
- 项目管理 (10)
- 代码架构 (27)
- java线程与进程 (2)
- 盈利模式 (10)
- 性能测试 (1)
- Ophone (2)
- web (6)
- asp (0)
- php (1)
- c# (1)
- Ruby (0)
- jboss (4)
- java基础之面试篇 (7)
- 数据查询优化 (1)
- weblogic (3)
- EJB (1)
- EXT (6)
- jquery (8)
- struts2 (2)
- struts1 (1)
- css (1)
- javascript (4)
- SSI (9)
- linux (9)
- c++ (6)
- 网络安全 (3)
- swing (2)
- 嵌入式 (1)
- 图像处理(机器人智能技术) (1)
- vb (2)
- mysql (2)
- sqlserver (10)
- dephi (0)
- Android (4)
- hadoop (1)
- maven (4)
- mybatis (1)
- html5 (1)
- 算法 (0)
- 高并发架构总结 (1)
- 时事评论 (4)
- 有些话不能不说 (35)
- 琴棋书画 (0)
- 教育 (1)
- 创业需要的 (4)
- 产品经理需要的 (4)
- 小南那些青涩的文章 (9)
- 如何创新 (4)
- 历史借鉴之秦汉 (1)
- 历史借鉴之三国 (1)
- 历史借鉴之魏晋 (1)
- 历史借鉴之隋唐 (1)
- 历史借鉴之南北宋 (1)
- 历史借鉴之近现代史 (1)
- 好工具我来推荐 (4)
- 汇编 (14)
最新评论
-
bilimeng:
求教,ConcurrentHashMap不是线程安全的么,为啥 ...
架构师之jdk8-----------------ConcurrentHashMap快速构建本地缓存和单例模式 -
baiducctv5:
wtaisi 写道wtaisi 写道|||||||||
spring aop中的propagation的7种配置的意思 -
zhangdong92:
另外内存泄漏一般也不是指计算时溢出。而是指某些对象已经不再使用 ...
java基础之面试篇三---int,float,long,double取值范围,内存泄露 -
zhangdong92:
Long.MAX_VALUE应该是(2^63)-1,而不是64 ...
java基础之面试篇三---int,float,long,double取值范围,内存泄露 -
nannan408:
java-lxm 写道好湿好湿好湿谢谢: )。
游南巅之晚秋
1.重构要求:
1)安全第一,尤其是关键部分,应先做出一demo,各环节正常测试运行后无缝割接。
周五和下班前提交更要小心,更改后的代码一定要及时放cvs,并在提交时注明修改的地方或原因,告同组的项目组员。
2)重构要先有接口测试,重构后必须保证通过接口测试,因为现在的系统是一个正常运行的系统,如果把未测试通过的代码放服务器,势必会给公司带来损失。
所以要求:小步进行,意思是每做改动,均要测试和可回朔。
3)重构完成后,向服务器提交代码时,需采用更保险的方法,将原文件备份为以***.class.20060809.jeff的文件,不能简单的覆盖,否则那是很危险的。
4)遇正常工作任务时先做正常任务,完成后继续重构,不能以重构为借口推工作。
5)这次总结的方式方法,经验形成文档,要求以后在工作中是随时做的,当增加功能时,修改bug时或复审代码时都应该想到是否将原有的代码重构,以提高系统的可复用性和可扩展性。
2.重构的工作:
1) 名字重构,修改原有不合理的名字。(参考java开发技术规范)
2) 包,结构重构,重整原有的结构,合并和细分。(参考java开发技术规范)
3) 方法体重构,长方法抽取,方法公用
4)在正确的类里计算值,不要在别的类里计算和写逻辑有本类的东西。
5)配置文件的重整
6)编码效率的重构:
a) 循环内不许声明变量
b) 尽可能不要在循环内做判断
c) StringBuffer
d) 连接池
e) 缓存
7) 非有用文件的及时删除
8)log的整理
9)文档的整理
10)异常的处理 (参看下面的例子)
11)参考java开发技术规范
3.代码的bad smell
1) 重复的代码: Extract method
2) 过长函数: 重构成small method 后要能取个好名字。
有这样一个原则:每当感觉需要以注析来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中,并以其用途(而非实现手法)命名,我们可以对一组甚至短短一行代码做这件事。
如何确定该提炼哪一段代码呢,一个很好的技巧是:寻找注析。
条件式和循环常常也是提炼的信号。
3)过大类,一个class做太多事情,分开,提炼时应该选择class内彼此相关的变量,将他们放在一起。
4)过长参数列: 改成传对象,谨慎。
5)发散式变化:当你看着一个class说:o,如果新加入一个数据库,我必须修改这三个函数...,那么此时也许将这个对象分成两个会更好,这样一来每个对象都可以只因一种变化而需要修改。
6)霰弹式修改:如果遇到某种变化,你都必须在许多不同的classes内做出许多小修改以响应之,你不但很难找到他们,也很容易忘记某个重要的修改,可以把需要修改的代码放进同一个class.
7) 依恋情节:
我们看到某个函数为了计算某值,从另一个对象哪儿调用几乎半打的取值函数(getting method),疗法是把这个函数移至它该去的另一个地方,Move method.
8) 数据泥团 你常常可以看到很多地方有相同的三或四笔数据项:两个classes内的相同值域,许多函数中的相同参数,这些总是绑在一起出现的数据,真应该放进属于他们自己的 对象中。
处理java异常的例子:
你觉得自己是一个Java专家吗?是否肯定自己已经全面掌握了Java的异常处理机制?在下面这段代码中,你能够迅速找出异常处理的六个问题吗?
1 OutputStreamWriter out = ...
2 java.sql.Connection conn = ...
3 try { // ⑸
4 Statement stat = conn.createStatement();
5 ResultSet rs = stat.executeQuery(
6 "select uid, name from user");
7 while (rs.next())
8 {
9 out.println("ID:" + rs.getString("uid") // ⑹
10 ",姓名:" + rs.getString("name"));
11 }
12 conn.close(); // ⑶
13 out.close();
14 }
15 catch(Exception ex) // ⑵
16 {
17 ex.printStackTrace(); //⑴,⑷
18 }
反例之一:丢弃异常
代码:15行-18行。
这段代码捕获了异常却不作任何处理,可以算得上Java编程中的杀手。从问题出现的频繁程度和祸害程度来看,它也许可以和C/C++程序的一个恶名远播的问题相提并论??不检查缓冲区是否已满。如果你看到了这种丢弃(而不是抛出)异常的情况,可以百分之九十九地肯定代码存在问题(在极少数情况下,这段代码有存在的理由,但最好加上完整的注释,以免引起别人误解)。
那么,应该怎样改正呢?主要有四个选择:
1、处理异常。针对该异常采取一些行动,例如修正问题、提醒某个人或进行其他一些处理,要根据具体的情形确定应该采取的动作。再次说明,调用printStackTrace算不上已经“处理好了异常”。
2、重新抛出异常。处理异常的代码在分析异常之后,认为自己不能处理它,重新抛出异常也不失为一种选择。
3、把该异常转换成另一种异常。大多数情况下,这是指把一个低级的异常转换成应用级的异常(其含义更容易被用户了解的异常)。
4、不要捕获异常。
结论一:既然捕获了异常,就要对它进行适当的处理。不要捕获异常之后又把它丢弃,不予理睬。
反例之二:不指定具体的异常
代码:15行。
许多时候人们会被这样一种“美妙的”想法吸引:用一个catch语句捕获所有的异常。最常见的情形就是使用catch(Exception ex)语句。但实际上,在绝大多数情况下,这种做法不值得提倡。为什么呢?
要理解其原因,我们必须回顾一下catch语句的用途。catch语句表示我们预期会出现某种异常,而且希望能够处理该异常。异常类的作用就是告诉Java编译器我们想要处理的是哪一种异常。由于绝大多数异常都直接或间接从java.lang.Exception派生,catch(Exception ex)就相当于说我们想要处理几乎所有的异常。
再来看看前面的代码例子。我们真正想要捕获的异常是什么呢?最明显的一个是SQLException,这是JDBC操作中常见的异常。另一个可能的异常是IOException,因为它要操作OutputStreamWriter。显然,在同一个catch块中处理这两种截然不同的异常是不合适的。如果用两个catch块分别捕获SQLException和IOException就要好多了。这就是说,catch语句应当尽量指定具体的异常类型,而不应该指定涵盖范围太广的Exception类。
另一方面,除了这两个特定的异常,还有其他许多异常也可能出现。例如,如果由于某种原因,executeQuery返回了null,该怎么办?答案是让它们继续抛出,即不必捕获也不必处理。实际上,我们不能也不应该去捕获可能出现的所有异常,程序的其他地方还有捕获异常的机会??直至最后由JVM处理。
结论二:在catch语句中尽可能指定具体的异常类型,必要时使用多个catch。不要试图处理所有可能出现的异常。
反例之三:占用资源不释放
代码:3行-14行。
异常改变了程序正常的执行流程。这个道理虽然简单,却常常被人们忽视。如果程序用到了文件、Socket、JDBC连接之类的资源,即使遇到了异常,也要正确释放占用的资源。为此,Java提供了一个简化这类操作的关键词finally。
finally是样好东西:不管是否出现了异常,Finally保证在try/catch/finally块结束之前,执行清理任务的代码总是有机会执行。遗憾的是有些人却不习惯使用finally。
当然,编写finally块应当多加小心,特别是要注意在finally块之内抛出的异常??这是执行清理任务的最后机会,尽量不要再有难以处理的错误。
结论三:保证所有资源都被正确释放。充分运用finally关键词。
反例之四:不说明异常的详细信息
代码:3行-18行。
仔细观察这段代码:如果循环内部出现了异常,会发生什么事情?我们可以得到足够的信息判断循环内部出错的原因吗?不能。我们只能知道当前正在处理的类发生了某种错误,但却不能获得任何信息判断导致当前错误的原因。
printStackTrace的堆栈跟踪功能显示出程序运行到当前类的执行流程,但只提供了一些最基本的信息,未能说明实际导致错误的原因,同时也不易解读。
因此,在出现异常时,最好能够提供一些文字信息,例如当前正在执行的类、方法和其他状态信息,包括以一种更适合阅读的方式整理和组织printStackTrace提供的信息。
结论四:在异常处理模块中提供适量的错误原因信息,组织错误信息使其易于理解和阅读。
反例之五:过于庞大的try块
代码:3行-14行。
经常可以看到有人把大量的代码放入单个try块,实际上这不是好习惯。这种现象之所以常见,原因就在于有些人图省事,不愿花时间分析一大块代码中哪几行代码会抛出异常、异常的具体类型是什么。把大量的语句装入单个巨大的try块就象是出门旅游时把所有日常用品塞入一个大箱子,虽然东西是带上了,但要找出来可不容易。
一些新手常常把大量的代码放入单个try块,然后再在catch语句中声明Exception,而不是分离各个可能出现异常的段落并分别捕获其异常。这种做法为分析程序抛出异常的原因带来了困难,因为一大段代码中有太多的地方可能抛出Exception。
结论五:尽量减小try块的体积。
反例之六:输出数据不完整
代码:7行-11行。
不完整的数据是Java程序的隐形杀手。仔细观察这段代码,考虑一下如果循环的中间抛出了异常,会发生什么事情。循环的执行当然是要被打断的,其次,catch块会执行??就这些,再也没有其他动作了。已经输出的数据怎么办?使用这些数据的人或设备将收到一份不完整的(因而也是错误的)数据,却得不到任何有关这份数据是否完整的提示。对于有些系统来说,数据不完整可能比系统停止运行带来更大的损失。
较为理想的处置办法是向输出设备写一些信息,声明数据的不完整性;另一种可能有效的办法是,先缓冲要输出的数据,准备好全部数据之后再一次性输出。
结论六:全面考虑可能出现的异常以及这些异常对执行流程的影响。
改写后的代码
根据上面的讨论,下面给出改写后的代码。也许有人会说它稍微有点罗嗦,但是它有了比较完备的异常处理机制。
OutputStreamWriter out = ...
java.sql.Connection conn = ...
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(
"select uid, name from user");
while (rs.next())
{
out.println("ID:" + rs.getString("uid") + ",姓名: " + rs.getString("name"));
}
}
catch(SQLException sqlex)
{
out.println("警告:数据不完整");
throw new ApplicationException("读取数据时出现SQL错误", sqlex);
}
catch(IOException ioex)
{
throw new ApplicationException("写入数据时出现IO错误", ioex);
}
finally
{
if (conn != null) {
try {
conn.close();
}
catch(SQLException sqlex2)
{
System.err(this.getClass().getName() + ".mymethod - 不能关闭数据库连接: " + sqlex2.toString());
}
}
if (out != null) {
try {
out.close();
}
catch(IOException ioex2)
{
System.err(this.getClass().getName() + ".mymethod - 不能关闭输出文件" + ioex2.toString());
}
}
}
本文的结论不是放之四海皆准的教条,有时常识和经验才是最好的老师。如果你对自己的做法没有百分之百的信心,务必加上详细、全面的注释。
另一方面,不要笑话这些错误,不妨问问你自己是否真地彻底摆脱了这些坏习惯。即使最有经验的程序员偶尔也会误入歧途,原因很简单,因为它们确确实实带来了“方便”。所有这些反例都可以看作Java编程世界的恶魔,它们美丽动人,无孔不入,时刻诱惑着你。也许有人会认为这些都属于鸡皮蒜毛的小事,不足挂齿,但请记住:勿以恶小而为之,勿以善小而不为。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/alexjjf/archive/2006/10/29/1355272.aspx
1)安全第一,尤其是关键部分,应先做出一demo,各环节正常测试运行后无缝割接。
周五和下班前提交更要小心,更改后的代码一定要及时放cvs,并在提交时注明修改的地方或原因,告同组的项目组员。
2)重构要先有接口测试,重构后必须保证通过接口测试,因为现在的系统是一个正常运行的系统,如果把未测试通过的代码放服务器,势必会给公司带来损失。
所以要求:小步进行,意思是每做改动,均要测试和可回朔。
3)重构完成后,向服务器提交代码时,需采用更保险的方法,将原文件备份为以***.class.20060809.jeff的文件,不能简单的覆盖,否则那是很危险的。
4)遇正常工作任务时先做正常任务,完成后继续重构,不能以重构为借口推工作。
5)这次总结的方式方法,经验形成文档,要求以后在工作中是随时做的,当增加功能时,修改bug时或复审代码时都应该想到是否将原有的代码重构,以提高系统的可复用性和可扩展性。
2.重构的工作:
1) 名字重构,修改原有不合理的名字。(参考java开发技术规范)
2) 包,结构重构,重整原有的结构,合并和细分。(参考java开发技术规范)
3) 方法体重构,长方法抽取,方法公用
4)在正确的类里计算值,不要在别的类里计算和写逻辑有本类的东西。
5)配置文件的重整
6)编码效率的重构:
a) 循环内不许声明变量
b) 尽可能不要在循环内做判断
c) StringBuffer
d) 连接池
e) 缓存
7) 非有用文件的及时删除
8)log的整理
9)文档的整理
10)异常的处理 (参看下面的例子)
11)参考java开发技术规范
3.代码的bad smell
1) 重复的代码: Extract method
2) 过长函数: 重构成small method 后要能取个好名字。
有这样一个原则:每当感觉需要以注析来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中,并以其用途(而非实现手法)命名,我们可以对一组甚至短短一行代码做这件事。
如何确定该提炼哪一段代码呢,一个很好的技巧是:寻找注析。
条件式和循环常常也是提炼的信号。
3)过大类,一个class做太多事情,分开,提炼时应该选择class内彼此相关的变量,将他们放在一起。
4)过长参数列: 改成传对象,谨慎。
5)发散式变化:当你看着一个class说:o,如果新加入一个数据库,我必须修改这三个函数...,那么此时也许将这个对象分成两个会更好,这样一来每个对象都可以只因一种变化而需要修改。
6)霰弹式修改:如果遇到某种变化,你都必须在许多不同的classes内做出许多小修改以响应之,你不但很难找到他们,也很容易忘记某个重要的修改,可以把需要修改的代码放进同一个class.
7) 依恋情节:
我们看到某个函数为了计算某值,从另一个对象哪儿调用几乎半打的取值函数(getting method),疗法是把这个函数移至它该去的另一个地方,Move method.
8) 数据泥团 你常常可以看到很多地方有相同的三或四笔数据项:两个classes内的相同值域,许多函数中的相同参数,这些总是绑在一起出现的数据,真应该放进属于他们自己的 对象中。
处理java异常的例子:
你觉得自己是一个Java专家吗?是否肯定自己已经全面掌握了Java的异常处理机制?在下面这段代码中,你能够迅速找出异常处理的六个问题吗?
1 OutputStreamWriter out = ...
2 java.sql.Connection conn = ...
3 try { // ⑸
4 Statement stat = conn.createStatement();
5 ResultSet rs = stat.executeQuery(
6 "select uid, name from user");
7 while (rs.next())
8 {
9 out.println("ID:" + rs.getString("uid") // ⑹
10 ",姓名:" + rs.getString("name"));
11 }
12 conn.close(); // ⑶
13 out.close();
14 }
15 catch(Exception ex) // ⑵
16 {
17 ex.printStackTrace(); //⑴,⑷
18 }
反例之一:丢弃异常
代码:15行-18行。
这段代码捕获了异常却不作任何处理,可以算得上Java编程中的杀手。从问题出现的频繁程度和祸害程度来看,它也许可以和C/C++程序的一个恶名远播的问题相提并论??不检查缓冲区是否已满。如果你看到了这种丢弃(而不是抛出)异常的情况,可以百分之九十九地肯定代码存在问题(在极少数情况下,这段代码有存在的理由,但最好加上完整的注释,以免引起别人误解)。
那么,应该怎样改正呢?主要有四个选择:
1、处理异常。针对该异常采取一些行动,例如修正问题、提醒某个人或进行其他一些处理,要根据具体的情形确定应该采取的动作。再次说明,调用printStackTrace算不上已经“处理好了异常”。
2、重新抛出异常。处理异常的代码在分析异常之后,认为自己不能处理它,重新抛出异常也不失为一种选择。
3、把该异常转换成另一种异常。大多数情况下,这是指把一个低级的异常转换成应用级的异常(其含义更容易被用户了解的异常)。
4、不要捕获异常。
结论一:既然捕获了异常,就要对它进行适当的处理。不要捕获异常之后又把它丢弃,不予理睬。
反例之二:不指定具体的异常
代码:15行。
许多时候人们会被这样一种“美妙的”想法吸引:用一个catch语句捕获所有的异常。最常见的情形就是使用catch(Exception ex)语句。但实际上,在绝大多数情况下,这种做法不值得提倡。为什么呢?
要理解其原因,我们必须回顾一下catch语句的用途。catch语句表示我们预期会出现某种异常,而且希望能够处理该异常。异常类的作用就是告诉Java编译器我们想要处理的是哪一种异常。由于绝大多数异常都直接或间接从java.lang.Exception派生,catch(Exception ex)就相当于说我们想要处理几乎所有的异常。
再来看看前面的代码例子。我们真正想要捕获的异常是什么呢?最明显的一个是SQLException,这是JDBC操作中常见的异常。另一个可能的异常是IOException,因为它要操作OutputStreamWriter。显然,在同一个catch块中处理这两种截然不同的异常是不合适的。如果用两个catch块分别捕获SQLException和IOException就要好多了。这就是说,catch语句应当尽量指定具体的异常类型,而不应该指定涵盖范围太广的Exception类。
另一方面,除了这两个特定的异常,还有其他许多异常也可能出现。例如,如果由于某种原因,executeQuery返回了null,该怎么办?答案是让它们继续抛出,即不必捕获也不必处理。实际上,我们不能也不应该去捕获可能出现的所有异常,程序的其他地方还有捕获异常的机会??直至最后由JVM处理。
结论二:在catch语句中尽可能指定具体的异常类型,必要时使用多个catch。不要试图处理所有可能出现的异常。
反例之三:占用资源不释放
代码:3行-14行。
异常改变了程序正常的执行流程。这个道理虽然简单,却常常被人们忽视。如果程序用到了文件、Socket、JDBC连接之类的资源,即使遇到了异常,也要正确释放占用的资源。为此,Java提供了一个简化这类操作的关键词finally。
finally是样好东西:不管是否出现了异常,Finally保证在try/catch/finally块结束之前,执行清理任务的代码总是有机会执行。遗憾的是有些人却不习惯使用finally。
当然,编写finally块应当多加小心,特别是要注意在finally块之内抛出的异常??这是执行清理任务的最后机会,尽量不要再有难以处理的错误。
结论三:保证所有资源都被正确释放。充分运用finally关键词。
反例之四:不说明异常的详细信息
代码:3行-18行。
仔细观察这段代码:如果循环内部出现了异常,会发生什么事情?我们可以得到足够的信息判断循环内部出错的原因吗?不能。我们只能知道当前正在处理的类发生了某种错误,但却不能获得任何信息判断导致当前错误的原因。
printStackTrace的堆栈跟踪功能显示出程序运行到当前类的执行流程,但只提供了一些最基本的信息,未能说明实际导致错误的原因,同时也不易解读。
因此,在出现异常时,最好能够提供一些文字信息,例如当前正在执行的类、方法和其他状态信息,包括以一种更适合阅读的方式整理和组织printStackTrace提供的信息。
结论四:在异常处理模块中提供适量的错误原因信息,组织错误信息使其易于理解和阅读。
反例之五:过于庞大的try块
代码:3行-14行。
经常可以看到有人把大量的代码放入单个try块,实际上这不是好习惯。这种现象之所以常见,原因就在于有些人图省事,不愿花时间分析一大块代码中哪几行代码会抛出异常、异常的具体类型是什么。把大量的语句装入单个巨大的try块就象是出门旅游时把所有日常用品塞入一个大箱子,虽然东西是带上了,但要找出来可不容易。
一些新手常常把大量的代码放入单个try块,然后再在catch语句中声明Exception,而不是分离各个可能出现异常的段落并分别捕获其异常。这种做法为分析程序抛出异常的原因带来了困难,因为一大段代码中有太多的地方可能抛出Exception。
结论五:尽量减小try块的体积。
反例之六:输出数据不完整
代码:7行-11行。
不完整的数据是Java程序的隐形杀手。仔细观察这段代码,考虑一下如果循环的中间抛出了异常,会发生什么事情。循环的执行当然是要被打断的,其次,catch块会执行??就这些,再也没有其他动作了。已经输出的数据怎么办?使用这些数据的人或设备将收到一份不完整的(因而也是错误的)数据,却得不到任何有关这份数据是否完整的提示。对于有些系统来说,数据不完整可能比系统停止运行带来更大的损失。
较为理想的处置办法是向输出设备写一些信息,声明数据的不完整性;另一种可能有效的办法是,先缓冲要输出的数据,准备好全部数据之后再一次性输出。
结论六:全面考虑可能出现的异常以及这些异常对执行流程的影响。
改写后的代码
根据上面的讨论,下面给出改写后的代码。也许有人会说它稍微有点罗嗦,但是它有了比较完备的异常处理机制。
OutputStreamWriter out = ...
java.sql.Connection conn = ...
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(
"select uid, name from user");
while (rs.next())
{
out.println("ID:" + rs.getString("uid") + ",姓名: " + rs.getString("name"));
}
}
catch(SQLException sqlex)
{
out.println("警告:数据不完整");
throw new ApplicationException("读取数据时出现SQL错误", sqlex);
}
catch(IOException ioex)
{
throw new ApplicationException("写入数据时出现IO错误", ioex);
}
finally
{
if (conn != null) {
try {
conn.close();
}
catch(SQLException sqlex2)
{
System.err(this.getClass().getName() + ".mymethod - 不能关闭数据库连接: " + sqlex2.toString());
}
}
if (out != null) {
try {
out.close();
}
catch(IOException ioex2)
{
System.err(this.getClass().getName() + ".mymethod - 不能关闭输出文件" + ioex2.toString());
}
}
}
本文的结论不是放之四海皆准的教条,有时常识和经验才是最好的老师。如果你对自己的做法没有百分之百的信心,务必加上详细、全面的注释。
另一方面,不要笑话这些错误,不妨问问你自己是否真地彻底摆脱了这些坏习惯。即使最有经验的程序员偶尔也会误入歧途,原因很简单,因为它们确确实实带来了“方便”。所有这些反例都可以看作Java编程世界的恶魔,它们美丽动人,无孔不入,时刻诱惑着你。也许有人会认为这些都属于鸡皮蒜毛的小事,不足挂齿,但请记住:勿以恶小而为之,勿以善小而不为。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/alexjjf/archive/2006/10/29/1355272.aspx
发表评论
-
架构师之jdk8-----------------ConcurrentHashMap快速构建本地缓存和单例模式
2015-06-04 15:33 90571.前言。 本地缓存和复杂的单例写起来不仅效率低下,而且 ... -
架构师之jdk8-------------------集合互相转换集锦
2015-06-04 11:34 16211.前言. 如题.这里主要介绍list,map等常用集合的 ... -
架构师之hibernate-------------------mysql类型对应java转换
2015-06-02 18:29 16421.前言. 如题. 2.代码. Hibernat ... -
架构师之bean---------------bean之间的数据copy
2015-06-01 18:05 14401.前言. 如题,bean不能强转,只能对应转换.一共有 ... -
架构师之jetty使用----------------问题集锦
2015-05-27 10:11 14301.前言. 如题. 2.问题描述. (1)com.op ... -
架构师之json-----------通过path查找指定数据
2015-03-31 14:29 26311.前言 如题。 2.代码. imp ... -
架构师之mybatis-----timestamp转date丢失精度问题
2015-03-26 14:53 45451.前言. 如题. 2.问题描述. 如果mappe ... -
架构师之数字判断-----------------怎么判断一个字符串是个数字
2015-03-24 14:43 9631.前言. 如题. 2.代码. 方法1: publ ... -
架构师之enum枚举之(二)--------直接判断String是否属于枚举中的一个
2015-03-22 21:17 82641.前言。 如题。 2.代码。 enum E ... -
架构师之jdk的bug排查(一)---------------split的点号陷阱
2015-03-20 15:01 33571.前言. jdk1.6的lang包的split方法是有 ... -
架构师之enum枚举之(一)-----------如何判断枚举和字符串相等(最简便方法)
2015-03-20 10:47 80701.前言. 如题. 2.代码. (1)代码串 publ ... -
架构师之maven(三)---------junit测试可能遇到的问题
2015-03-18 10:31 17901.前言. 如题. 2.代码. (1)类型转换错误 (1) ... -
架构师之maven(二)junit4.11+spring4.1的测试配置
2015-03-16 17:15 36991.前言. maven的junit测试是需要遵守一些规则 ... -
spring官方下载地址
2015-03-16 10:10 1135SPRING官方网站改版后,建议都是通过 Maven和Grad ... -
java 序列化和反序列化(针对字符串的例子)
2014-11-04 14:09 42271.前言. 摘自:http://blog.csdn.ne ... -
架构师之Dos命令之setx-------常用来设置系统环境变量
2014-08-25 10:19 73441.前言。 如题。 2.内容。 用法为形如 @SET ... -
linux集群之----------设置磁盘缓冲参数
2014-07-29 10:59 70711.前言。 如题。linux ... -
spark+hadoop+cenos6.5+VitualBox4.3.6整合开发(一)安装centos6.5
2014-01-17 10:04 32781.前言。 首先先感谢cctv和http://zhou ... -
axis2-如何已知uri或者xml生成客户端?
2013-11-06 10:23 26971.前言 首先,需要下载axis2工具包,见附件,我这里是 ... -
让ie6,7,8支持canvas,css3等主流html5技术
2013-06-18 13:02 293531.前言。 ie6,7,8支持htm ...
相关推荐
此外,《代码重构(C#&ASP.NET版)》还将介绍重构技术的标准定义,这样您就可以在工作中引用到它。《代码重构(C#&ASP.NET版)》涵盖的重构技术将让您变得效率更高。您将能使用这些信息对修改做出反应并改进既有代码的...
SharpRefactor(C#代码重构工具) 产品简述 -------- 本工具用于代码重构和代码自动生成。现阶段主要用于C#代码重构。 所谓重构也就是“保持软件的外在功能不变,重新调整其内部结构”。 关于每种重构模式的...
第1章 重构,第一个案例 1.1 起点 1.2 重构的第一步 1.3 分解并重组Statemen 1.4 运用多态取代与价格相关的条件逻辑 1.5 结语 第2章 重构原则 2.1 何谓重构 2.2 为何重构 2.3 何时重构 2.4 怎么对经理说 2.5 重构的...
第1章 重构,第一个案例 1 1.1 起点 1 1.2 重构的第一步 7 1.3 分解并重组statement() 8 1.4 运用多态取代与价格相关的条件逻辑 34 1.5 结语 52 第2章 重构原则 53 2.1 何谓重构 53 2.2 为何重构 ...
第1章 重构,第一个案例1 1.1 起点1 1.2 重构的第一步7 1.3 分解并重组statement()8 1.4 运用多态取代与价格相关的条件逻辑34 1.5 结语52 第2章 重构原则53 2.1 何谓重构53 2.2 为何重构55 2.3 何时重构57 2.4 怎么...
指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。 软件重构需要借助工具完成,重构工具能够修改代码同时修改所有引用该代码的地方。 在极限编程的方法学中,重构需要单元测试来支持
代码重构(英语:Code refactoring)指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。 软件重构需要借助工具完成,重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中,...
hapter 1:Refactoring,a First Example 重构,第一个例子 The Starting Point 起点 The First Step in Refactoring 重构第一步 Decomposing and Redistributing the Statement Method 分解并重组...
第1章 重构,第一个案例1 1.1 起点1 1.2 重构的第一步7 1.3 分解并重组statement()8 1.4 运用多态取代与价格相关的条件逻辑34 1.5 结语52 第2章 重构原则53 2.1 何谓重构53 2.2 为何重构55 2.3 何时重构57 2.4 怎么...
Chapter 1:Refactoring,a First Example 重构,第一个例子 The Starting Point 起点 The First Step in Refactoring 重构第一步 Decomposing and Redistributing the Statement Method 分解并重组...
第1章 重构,第一个案例1 1.1 起点1 1.2 重构的第一步7 1.3 分解并重组statement()8 1.4 运用多态取代与价格相关的条件逻辑34 1.5 结语52 第2章 重构原则53 2.1 何谓重构53 2.2 为何重构55 2.3 何时重构57 2.4 怎么...
第1章 重构,第一个案例 1.1 起点 1.2 重构的第一步 1.3 分解并重组Statemen 1.4 运用多态取代与价格相关的条件逻辑 1.5 结语 第2章 重构原则 2.1 何谓重构 2.2 为何重构 2.3 何时重构 2.4 怎么对经理说 2.5 重构的...
第1章 重构,第一个案例 1.1 起点 1.2 重构的第一步 1.3 分解并重组statement() 1.4 运用多态取代与价格相关的条件逻辑 1.5 结语 第2章 重构原则 2.1 何谓重构 2.2 为何重构 2.3 何时重构 2.4 怎么对经理说...
Chapter 1:Refactoring,a First Example 重构,第一个例子 The Starting Point 起点 The First Step in Refactoring 重构第一步 Decomposing and Redistributing the Statement Method 分解并重组...
重构,一言以蔽之,就是在不改变外部行为的前提下,有条不紊地改善代码。多年前,正是本书原版的出版,使重构终于从编程高手们的小圈子走出,成为众多普通程序员日常开发工作中不可或缺的一部分。本书也因此成为与...
第1 章重构,第一个案例···· · ·· · · ····· · · ····· ··· · ····· · · ·….... ……................ ….............. …..... …...... …l I.I 起点···· ·······...
高效重构 当我们熟练掌握了重构技术后,还不能此说自己在实践中已经可以安全而高效地实施... 重构工具对语言的支持的一个难点在于对代码引用点的分析查找. C++中有很多语法会干扰到这一分析,导致难以进行自动化重
Chapter 1:Refactoring,a First Example 重构,第一个例子 The Starting Point 起点 The First Step in Refactoring 重构第一步 Decomposing and Redistributing the Statement Method 分解并重组...
Chapter 1:Refactoring,a First Example 重构,第一个例子 The Starting Point 起点 The First Step in Refactoring 重构第一步 Decomposing and Redistributing the Statement Method 分解并重组...