java重构代码设计文档 java 代码重构
java中什么是代码重构,什么时候需要代码重构
代码重构(英语:Code refactoring)重构就是在不改变软件系统外部行为的前提下,改善它的内部结构。
成都创新互联公司专注于永德企业网站建设,成都响应式网站建设公司,商城网站制作。永德网站建设公司,为永德等地区提供建站服务。全流程按需策划设计,专业设计,全程项目跟踪,成都创新互联公司专业和态度为您提供的服务
软件重构需要借助工具完成,重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中,重构需要单元测试来支持。
java重构:指程序员对已有程序在尽量不改变接口的前提下,进行重新编写代码的工作,一般有以下几方面:
1、去除已知bug。
2、提高程序运行效率。
3、增加新的功能。
重构举例:(简化代码、提升效率)
重构前:
if(list != null list.size() 0){
for(int i = 0; i list.size(); i++){
//skip...
}
}
重构后
if(list != null){
for(int i = 0, len = list.size(); i len; i++){
//skip...
}
}
何时着手重构(Refactoring)
新官上任三把火,开始一个全新??、脚不停蹄、加班加点,一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行,势如破竹,攻城掠地,直指"黄龙府"。
开发经理是这支浩浩汤汤代码队伍的统帅,他负责这支队伍的命运,当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时,他感叹说"我有这样一支军队哪里还怕没有胜利呢?"。但很遗憾,你手中的这支队伍原本只是散兵游勇,在前进中招兵买马,不断壮大,所以队伍变形在所难免。当开发经理发觉队伍变形时,也许就是克制住攻克前方山头的诱惑,停下脚步整顿队伍的时候了。
Kent Beck提出了"代码坏味道"的说法,和我们所提出的"队伍变形"是同样的意思,队伍变形的信号是什么呢?以下列述的代码症状就是"队伍变形"的强烈信号:
·代码中存在重复的代码
中国有118 家整车生产企业,数量几乎等于美、日、欧所有汽车厂家数之和,但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。
程序代码更是不能搞重复建设,如果同一个类中有相同的代码块,请把它提炼成类的一个独立方法,如果不同类中具有相同的代码,请把它提炼成一个新类,永远不要重复代码。
·过大的类和过长的方法
过大的类往往是类抽象不合理的结果,类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国,诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂,错误机率将直线上升,而可读性则直线下降,类的健壮性很容易被打破。当看到一个过长的方法时,需要想办法将其划分为多个小方法,以便于分而治之。
·牵一毛而需要动全身的修改
当你发现修改一个小功能,或增加一个小功能时,就引发一次代码地震,也许是你的设计抽象度不够理想,功能代码太过分散所引起的。
·类之间需要过多的通讯
A类需要调用B类的过多方法访问B的内部数据,在关系上这两个类显得有点狎昵,可能这两个类本应该在一起,而不应该分家。
·过度耦合的信息链
"计算机是这样一门科学,它相信可以通过添加一个中间层解决任何问题",所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息,需要一个类的方法调用另一个类的方法,层层挂接,就象输油管一样节节相连。这往往是因为衔接层太多造成的,需要查看就否有可移除的中间层,或是否可以提供更直接的调用方法。
·各立山头干革命
如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能,你会发现往往是因为开发团队协调不够造成的。笔者曾经写了一个颇好用的字符串处理类,但因为没有及时通告团队其他人员,后来发现项目中居然有三个字符串处理类。革命资源是珍贵的,我们不应各立山头干革命。
·不完美的设计
在笔者刚完成的一个比对报警项目中,曾安排阿朱开发报警模块,即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息,阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求,即要求第三方系统以报文形式向比对报警系统发送请求,比对报警系统接收并响应这个请求。这又需要用到Socket报文通讯,由于原来的设计没有将报文通讯模块独立出来,所以无法复用阿朱开发的代码。后来我及时调整了这个设计,新增了一个报文收发模块,使系统所有的对外通讯都复用这个模块,系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计,刚开始可能注意不到,到后来才会慢慢凸显出来,此时唯有勇于更改才是最好的出路。
·缺少必要的注释
虽然许多软件工程的书籍常提醒程序员需要防止过多注释,但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释,因为前者更能带来成就感,所以代码注释往往不是过多而是过少,过于简单。人的记忆曲线下降的坡度是陡得吓人的,当过了一段时间后再回头补注释时,很容易发生"提笔忘字,愈言且止"的情形。
曾在网上看到过微软的代码注释,其详尽程度让人叹为观止,也从中体悟到了微软成功的一个经验。
如何写出更好的Java代码
1. 优雅需要付出代价。
从短期利益来看,对某个问题提出优雅的解决方法,似乎可能花你更多的时间。但当它终于能够正确执行并可轻易套用于新案例中,不需要花上数以时计,甚至以天计或以月计的辛苦代价时,你会看得到先前所花功夫的回报(即使没有人可以衡量这一点)。这不仅给你一个可更容易开发和调试的程序,也更易于理解和维护。这正是它在金钱上的价值所在。这一点有赖某种人生经验才能够了解,因为当你努力让某一段程序代码变得比较优雅时,你并不是处于一种具生产力的状态下。但是,请抗拒那些催促你赶工的人们,因为那么做只会减缓你的速度罢了。
2. 先求能动,再求快。
即使你已确定某段程序代码极为重要,而且是系统的重要瓶颈,这个准则依然成立。尽可能简化设计,让系统能够先正确动作。如果程序的执行不够快,再量测其效能。几乎你总是会发现,你所认为的”瓶颈”其实都不是问题所在。把你的时间花在刀口上吧。
3. 记住”各个击破”的原理。
如果你所探讨的问题过于混杂,试着想像该问题的基本动作会是什么,并假设这一小块东西能够神奇地处理掉最难的部分。这”一小块”东西其实就是对象–请撰写运用该对象的程序代码,然后检视对象,并将其中困难的部分再包装成其他对象,依此类推。
4. 区分class开发者和class使用者(使用端程序员)。
Class 使用者扮演着”客户”角色,不需要(也不知道)class的底层运作方式。Class开发者必须是class设计专家,并撰写class,使它能够尽可能被大多数新手程序员所用,而且在程序中能够稳当执行。一套程序库只有在具备通透性的情况下,使用起来才会容易。
5.当你撰写class时,试着给予明了易懂的名称,减少不必要的注解。
你给客户端程序员的接口,应该保持概念上的单纯性。不了这个目的,当函数的重载(overloading)适合制作出直觉、易用的接口时,请善加使用。
6. 也必你的分析和设计必须让系统中的classes保持最少,须让其Public interfaces保持最少,以及让这些classes和其他classes之间的关联性( 尤其是base classes)保持最少。
如果你的设计所得结果更甚于此,请问问自己,是否其中每一样东西在整个程序生命期中都饶富价值?如果并非如此,那么,维护它们会使你付出代价。开发团队的成员都有不维护”无益于生产力提升”的任何东西的倾向;这是许多设计方法无法解释的现象。
7. 让所有东西尽量自动化。先撰写测试用的程序代码(在你撰写class之前),并让它和class结合在一起。请使用makefile或类似工具,自动进行测试动作。
通过这种方式,只要执行测试程序,所有的程序变动就可以自动获得验证,而且可以立即发现错误。由于你知道的测试架构所具备的安全性,所以当你发现新的需求时,你会更勇于进行全面修改。请记住,程序语言最大的改进,是来自型别检查、异常处理等机制所赋予的内置测试动作。但这些功能只能协助你到达某种程度。开发一个稳固系统时,你得自己验证自己的classes或程序的性质。
8. 在你撰写class之前先写测试码,以便验证你的class 是否设计完备。如果你无法撰写测试码,你便无法知道你的class 的可能长相。撰写测试码通常能够显现出额外的特性(features)或限制 ( constraints)__它们并不一定总是能够在分析和设计过程中出现。测试码也可做为展示class 用法的示例程序。
9. 所有软件设计上的问题,都可以通过”引入额外的概念性间接层(conceptual indirection)”加以简化。这个软件工程上的基础法则是抽象化概念的根据,而抽象化概念正是面向对象程序设计的主要性质。
10. 间接层(indirection)应该要有意义(和准则-9致)。
这里所指的意义可以像”将共用程序代码置于惟一函数”这么简单。如果你加入的间接层(或抽象化、或封装等等)不具意义,它可能就和没有适当的间接层一样糟糕。
11. 让class尽可能微小而无法切割(atomic)。
赋予每个class单一而清楚的用途。如果你的classes或你的系统成长得过于复杂,请将复杂的classes切割成比较简单的几个classes。最明显的一个判断指针就是class的大小:如果它很大,那么它工作量过多的机会就可能很高,那就应该被切割。重新设计class的建议线索是:
1) 复杂的switch语句:请考虑运用多态(Polymorphism)。
2) 许多函数各自处理类型极为不同的动作:请考虑切割为多个不同的(classes)。
12. 小心冗长的引数列(argument lists)。
冗长的引数列会使函数的调用动作不易撰写、阅读、维护。你应该试着将函数搬移到更适当的class中,并尽量以对象为引数。
13. 不要一再重复。
如果某段程序代码不断出现于许多derived class函数中,请将该段程序代码置于某个base class 函数内,然后在derived class函数中调用。这么做不仅可以省下程序代码空间,也可以让修改该段程序代码动作更易于进行。有时候找出此种共通程序代码还可以为接口增加实用功能。
14. 小心switch语句或成串的if-else 子句。
通常这种情况代表所谓的”type-check coding”。也就是说究竟会执行哪一段程序代码,乃是依据某种型别信息来做抉择(最初,确切型别可能不十分明显)。你通常可以使用继承和多态来取代此类程序代码;Polymorphical method (多态函数)的调用会自动执行此类型别检验,并提供更可靠更容易的扩充性。
15. 从设计观点来看,请找出变动的事物,并使它和不变的事物分离。
也就是说,找出系统中可能被你改变的元素,将它们封装于classes中。你可以在《Thinking in Patterns with Java》(可免费下载于 www. BruceEckel. Com)大量学习到这种观念。
16. 不要利用subclassing来扩充基础功能。
如果某个接口元素对class而言极重要,它应该被放在base class 里头,而不是直到衍生(derivation)时才被加入。如果你在继承过程中加入了函数,或许你应该重新思考整个设计。
17. 少就是多。
从class 的最小接口开始妨展,尽可能在解决问题的前提下让它保持既小又单纯。不要预先考量你的class被使用的所有可能方式。一旦class被实际运用,你自然会知道你得如何扩充接口。不过,一旦class被使用后,你就无法在不影响客户程序代码的情况下缩减其接口。如果你要加入更多函数倒是没有问题–不会影响既有的客户程序代码,它们只需重新编译即可。但即使新函数取代了旧函数的功能,也请你保留既有接口。如果你得通过”加入更多引数”的方式来扩充既有函数的接口,请你以新引数写出一个重载化的函数;通过 这种方式就不会影响既有函数的任何客户了。
18. 大声念出你的classes,确认它们符合逻辑。
请base class和derived class 之间的关系是”is-a”(是一种),让class和成员对象之间的关系是”has-a”(有一个)。
19. 当你犹豫不决于继承(inheritance)或合成(组合,composition)时,请你问问自己,是否需要向上转型(upcast)为基础型别。
如果不需要,请优先选择合成(也就是是使用成员对象)。这种作法可以消除”过多基础型别”。如果你采用继承,使用者会认为他们应该可以向上转型。
20. 运用数据成员来表示数值的变化,运用经过覆写的函数(overrided method)来代表行为的变化 。
也就是说,如果你找到了某个 class, 带有一些状态变量,而其函数会依据这些变量值切换不同的行为,那么你或许就应该重新设计,在subclasses 和覆写后的函数(overrided methods)中展现行为止的差异。
21. 小心重载(overloading)。
函数不应该依据引数值条件式地选择执行某一段程序代码。这种情况下你应该撰写两个或更多个重载函数(overloaded methods)
22. 使用异常体系(exception hierarchies)
最好是从Java标准异常体系中衍生特定的classes, 那么,捕捉异常的人便可以捕捉特定异常,之后才捕捉基本异常。如果你加入新的衍生异常,原有的客户端程序仍能通过其基础型别来捕捉它。
23. 有时候简单的聚合(aggregation)就够了。
飞机上的”旅客舒适系统”包括数个分离的元素:座椅、空调、视讯设备等等,你会需要在飞机上产生许多这样的东西。你会将它们声明为Private成员并开发出一个全新的接口吗?不会的,在这个例子中,元素也是Public接口的一部分,所以仍然是安全的。当然啦,简单聚合并不是一个常被运用的解法,但有时候的确是。
24. 试着从客户程序员和程序维护的角度思考。
你的class应该设计得尽可能容易使用。你应该预先考量可能性有的变动,并针对这些 可能的变动进行设计,使这些变动日后可轻易完成。
25. 小心”巨大对象并发症”。
这往往是刚踏OOP领域的过程式(procedural)程序员的一个苦恼,因为他们往往最终还是写出一个过程式程序,并将它们摆放到一个或两个巨大对象中。注意,除了application framework (应用程序框架,译注:一种很特殊的、大型OO程序库,帮你架构程序本体)之外,对象代表的是程序中的观念,而不是程序本身。
26. 如果你得用某种丑陋的方式来达成某个动作,请将丑陋的部分局限在某个class里头。
27. 如果你得用某种不可移植方式来达成某个动作,请将它抽象化并局限于某个class里头。这样一个”额外间接层”能够防止不可移植的部分扩散到整个程序。这种作法的具体呈现便是Bridge设计模式(design pattern)。
28. 对象不应仅仅只用来持有数据。
对象也应该具有定义明确界限清楚的行为。有时候使用”数据对象”是适当的,但只有在通用形容器不适用时,才适合刻意以数据对象来包装、传输一群数据项。
29. 欲从既有的classes身上产生新的classes时,请以组合(composition)为优先考量。
你应该只在必要时才使用继承。如果在组合适用之处你却选择了继承,你的设计就渗杂了非必要的复杂性。
30. 运用继承和函数覆写机制来展现行为上的差异,运用fields(数据成员)来展现状态上的差异。
这句话的极端例子,就是继承出不同的classes表现各种不同的颜色,而不使用”color”field.
31. 当心变异性(variance)。
语意相异的两个对象拥有相同的动作(或说责任)是可能的。OO世界中存在着一种天生的引诱,让人想要从某个class继承出另一个subclass,为的是获得继承带来的福利。这便是所谓”变异性”。但是,没有任何正当理由足以让我们强迫制造出某个其实并不存在的superclass/subclass关系。比较好的解决方式是写出一个共用的base class,它为两个derived classes制作出共用接口–这种方式会耗用更多空间,但你可以如你所盼望地从继承机制获得好处,而且或许能够在设计上获得重大发现。
32. 注意继承上的限制。
最清晰易懂的设计是将功能加到继承得来的class里头;继承过程中拿掉旧功能(而非增加新功能)则是一种可疑的设计。不过,规则可以打破。如果你所处理的是旧有的class程序库,那么在某个class的subclass限制功能,可能会比重新制定整个结构(俾使新class得以良好地相称于旧 class)有效率得多。
33. 使用设计模式(design patterns)来减少”赤裸裸无加掩饰的机能(naked functionality)”。
举个例子,如果你的class只应该产出惟一一个对象,那么请不要以加思索毫无设计的手法来完成它,然后撰写”只该产生一份对象”这样的注解就拍拍屁股走人。请将它包装成singleton(译注:一个有名的设计模式,可译为”单件”)。如果主程序中有多而混乱的”用以产生对象”的程序代码,请找出类似 factory method这样的生成模式(creational patterns),使价钱可用以封装生成动作减少”赤裸裸无加掩饰的机能”(naked functionality)不仅可以让你的程序更易理解和维护,也可以阻止出于好意却带来意外的维护者。
34. 当心”因分析而导致的瘫痪(analysis paralysis)”。
请记住,你往往必须在获得所有信息之前让项目继续前进。而且理解未知部分的最好也最快的方式,通常就是实际前进一步而不只是纸上谈兵。除非找到解决办法,否则无法知道解决办法。Java拥有内置的防火墙,请让它们发挥作用。你在单一class或一组classes中所犯的错误,并不会伤害整个系统的完整性。
35. 当你认为你已经获得一份优秀的分析、设计或实现时,请试着加以演练。
将团队以外的某些人带进来-他不必非得是个顾问不可,他可以是公司其他团队的成员。请那个人以新鲜的姿态审视你们的成果,这样可以在尚可轻易修改的阶段找出问题,其收获会比因演练而付出的时间和金钱代价来得高。实现 (Implementation)
36. 一般来说,请遵守Sun的程序编写习惯。
价钱可以在以下网址找到相关文档:java.sun.com/docs/codeconv/idex.html。本书尽可能遵守这些习惯。众多Java程序员看到的程序代码,都有是由这些习惯构成的。如果你固执地停留在过去的编写风格中,你的(程序代码)读者会比较辛苦。不论你决定采用什么编写习惯,请在整个程序中保持一致。你可以在home.wtal.de/software-solutions/jindent上找到一个用来重排Java程序的免费工具。
37. 无论使用何种编写风格,如果你的团队(或整个公司,那就更好了)能够加以标准化,那么的确会带来显著效果。这代表每个人都可以在其他人不遵守编写风格修改其作品,这是个公平的游戏。标准化的价值在于,分析程序代码时所花的脑力较小,因而可以专心于程序代码的实质意义。
38. 遵守标准的大小写规范。
将 class名称的第一个字母应为大写。数据成员、函数、对象(references)的第一个字母应为小写。所有识别名称的每个字都应该连在一块儿,所有非首字的第一个字母都应该大写。例如: ThisIsAClassName thisIsAMethodOrFieldName 如果你在static final 基本型别的定义处指定了常量初始式(constant initializers),那么该识别名称应该全为大写,代表一个编译期常量。 Packages是个特例,其名称皆为小写,即使非首字的字母亦是如此。域名(org, net, edu 等等)皆应为小写。(这是Java 1.1迁移至Java 2时的一项改变) 。
39、不要自己发明”装饰用的”Private数据成员名称。
通常这种的形式是在最前端加上底线和其他字符,匈牙利命名法(Hungarian notation)是其中最差的示范。在这种命名法中,你得加入额外字符来表示数据的型别、用途、位置等等。仿佛你用的是汇编语言(assembly language)而编译器没有提供任何协肋似的。这样的命名方式容易让人混淆又难以阅读,也不易推行和维护。就让classes和packages来进行”名称上的范
围制定(name scoping)”吧。
40、当你拟定通用性的class时,请遵守正规形式(canonical form)。
包括equals( )、hashCode( )、clone( ) ( 实现出Cloneable),并实现出Comparable和Serialiable等等。
如何使用IntelliJ IDEA来重构代码
Ctrl+Alt+L 格式化代码
Ctrl+Shift+J 两行合成一行,删去不必要的空格匹配代码格式
其他快捷键:
【常规】
Ctrl+Shift + Enter,语句完成
“!”,否定完成,输入表达式时按 “!”键
Ctrl+E,最近的文件
Ctrl+Shift+E,最近更改的文件
Shift+Click,可以关闭文件
Ctrl+[ OR ],可以跑到大括号的开头与结尾
Ctrl+F12,可以显示当前文件的结构
Ctrl+F7,可以查询当前元素在当前文件中的引用,然后按 F3 可以选择
Ctrl+N,可以快速打开类
Ctrl+Shift+N,可以快速打开文件
Alt+Q,可以看到当前方法的声明
Ctrl+P,可以显示参数信息
Ctrl+Shift+Insert,可以选择剪贴板内容并插入
Alt+Insert,可以生成构造器/Getter/Setter等
Ctrl+Alt+V,可以引入变量。例如:new String(); 自动导入变量定义
Ctrl+Alt+T,可以把代码包在一个块内,例如:try/catch
Ctrl+Enter,导入包,自动修正
Ctrl+Alt+L,格式化代码
Ctrl+Alt+I,将选中的代码进行自动缩进编排,这个功能在编辑 JSP 文件时也可以工作
Ctrl+Alt+O,优化导入的类和包
Ctrl+R,替换文本
Ctrl+F,查找文本
Ctrl+Shift+Space,自动补全代码
Ctrl+空格,代码提示(与系统输入法快捷键冲突)
Ctrl+Shift+Alt+N,查找类中的方法或变量
Alt+Shift+C,最近的更改
Alt+Shift+Up/Down,上/下移一行
Shift+F6,重构 – 重命名
Ctrl+X,删除行
Ctrl+D,复制行
Ctrl+/或Ctrl+Shift+/,注释(//或者/**/)
Ctrl+J,自动代码(例如:serr)
Ctrl+Alt+J,用动态模板环绕
Ctrl+H,显示类结构图(类的继承层次)
Ctrl+Q,显示注释文档
Alt+F1,查找代码所在位置
Alt+1,快速打开或隐藏工程面板
Ctrl+Alt+left/right,返回至上次浏览的位置
Alt+left/right,切换代码视图
Alt+Up/Down,在方法间快速移动定位
Ctrl+Shift+Up/Down,向上/下移动语句
F2 或 Shift+F2,高亮错误或警告快速定位
Tab,代码标签输入完成后,按 Tab,生成代码
Ctrl+Shift+F7,高亮显示所有该文本,按 Esc 高亮消失
Alt+F3,逐个往下查找相同文本,并高亮显示
Ctrl+Up/Down,光标中转到第一行或最后一行下
Ctrl+B/Ctrl+Click,快速打开光标处的类或方法(跳转到定义处)
Ctrl+Alt+B,跳转到方法实现处
Ctrl+Shift+Backspace,跳转到上次编辑的地方
Ctrl+O,重写方法
Ctrl+Alt+Space,类名自动完成
Ctrl+Alt+Up/Down,快速跳转搜索结果
Ctrl+Shift+J,整合两行
Alt+F8,计算变量值
Ctrl+Shift+V,可以将最近使用的剪贴板内容选择插入到文本
Ctrl+Alt+Shift+V,简单粘贴
Shift+Esc,不仅可以把焦点移到编辑器上,而且还可以隐藏当前(或最后活动的)工具窗口
F12,把焦点从编辑器移到最近使用的工具窗口
Shift+F1,要打开编辑器光标字符处使用的类或者方法 Java 文档的浏览器
Ctrl+W,可以选择单词继而语句继而行继而函数
Ctrl+Shift+W,取消选择光标所在词
Alt+F7,查找整个工程中使用地某一个类、方法或者变量的位置
Ctrl+I,实现方法
Ctrl+Shift+U,大小写转化
Ctrl+Y,删除当前行
Shift+Enter,向下插入新行
psvm/sout,main/System.out.println(); Ctrl+J,查看更多
Ctrl+Shift+F,全局查找
Ctrl+F,查找/Shift+F3,向上查找/F3,向下查找
Ctrl+Shift+S,高级搜索
Ctrl+U,转到父类
Ctrl+Alt+S,打开设置对话框
Alt+Shift+Inert,开启/关闭列选择模式
Ctrl+Alt+Shift+S,打开当前项目/模块属性
Ctrl+G,定位行
Alt+Home,跳转到导航栏
Ctrl+Enter,上插一行
Ctrl+Backspace,按单词删除
Ctrl+”+/-”,当前方法展开、折叠
Ctrl+Shift+”+/-”,全部展开、折叠
Alt+1,项目
Alt+2,收藏
Alt+6,TODO
Alt+7,结构
Ctrl+Shift+C,复制路径
Ctrl+Alt+Shift+C,复制引用,必须选择类名
Ctrl+Alt+Y,同步
Ctrl+~,快速切换方案(界面外观、代码风格、快捷键映射等菜单)
Ctrl+Tab,转到下一个拆分器
Ctrl+Shift+Tab,转到上一个拆分器
【重构】
Ctrl+Alt+Shift+T,弹出重构菜单
Alt+Delete,安全删除
Ctrl+Alt+N,内联
【查找】
Ctrl+F,查找
Ctrl+R,替换
Ctrl+Shift+F,在路径中查找
Ctrl+Shift+R,在路径中替换
Ctrl+Shift+S,搜索结构
Ctrl+Shift+M,替换结构
【VCS】
Alt+~,VCS 操作菜单
Ctrl+K,提交更改
Ctrl+T,更新项目
Ctrl+Alt+Shift+D,显示变化
补充说明:
IDEA
全称IntelliJ
IDEA,是java语言开发的集成环境,IntelliJ在业界被公认为最好的java开发工具之一,尤其在智能代码助手、代码自动提示、重构、
J2EE支持、Ant、JUnit、CVS整合、代码审查、
创新的GUI设计等方面的功能可以说是超常的。IDEA是JetBrains公司的产品,这家公司总部位于捷克共和国的首都布拉格,开发人员以严谨著称的
东欧程序员为主。
本文标题:java重构代码设计文档 java 代码重构
网站网址:http://azwzsj.com/article/hjopeh.html