-
Notifications
You must be signed in to change notification settings - Fork 37
SourceMaking has written a very good introduction to refactoring answering why should you refactor?, when should you refactor?
TODO
-
AutoRefactor goes one step beyond formatting: it makes the code look even more familiar by ensuring code structures are consistently written in the same, clean way.
-
Code style exist to ensure code looks consistent across an entire project. This eases readability by ensuring developers find the same style everywhere: indentation, formatting, position of braces, all these contribute to the code style.
-
-
AutoRefactor aims at using techniques commonly found in optimizing compilers, and applying them to the source code with the goal to simplify the burden of maintaining software.
-
Optimizing compilers provide many benefits for code execution. The JVM’s JIT is particularly good at optimizing running code. However, when it comes to the source code, an optimizing compiler does not help developers with maintaining large code bases with a rich history and a long evolution. A lot of cruft accumulates after several years; which is known as technical debt.
-
-
Manual code reviews. The developer is responsible for the changes he commits. So it is highly recommended he reviews all the changes before committing them.
-
Unit tests/Functional tests. Unit and functional tests maintain high confidence that the software keep doing what it was supposed to do.
-
Make smaller commits. Make single purpose commits. With refactoring commits touching many files, only commit one type of refactoring at a time. Use the "Choose refactoring" menu option. Commit changes in smaller chunks. The size of a chunk should be the size you would be comfortable to deal with if a regression occurred. If you do all this, and a regression occurs, then you can bisect the revisions and quickly converge to the commit causing problem. Then you either fix it or revert it. Tools to bisect exist for git (git-bisect), Mercurial (hg bisect), Subversion (svn-bisect), etc.
This is well possible. Despite trying to remove all false positives, some can have slipped through. You can file a bug if you think some refactoring is wrong.
AutoRefactor is opinionated and subjective in the way it refactors code. If you disagree with one particular refactoring rule, maybe thinking differently can help. For example, refactoring rules like "Collapse if statement" can produce complex conditions. Is it possible to extract methods with sensible names to break down the complex condition into more meaningful ones? More than likely, there are comments around that could give clues on how to name such methods.
It could. However, consider what it means to not refactor the software: it makes it harder for any future maintenance on trunk/master, or any future branches. Instead, return on investment for refactoring right now is huge in the longer term. Additionally, refactoring code can help understand what the code is doing, hence clarifying what the code on older branches is doing.
Indeed. Do not wait for a tool to do that :)
If you’re up for the organizational/managerial challenges, then go for it. AutoRefactor is only a solution for purely technical problems, when the problem is not organizational/managerial, when you do not want to address the later or when you are unsure. It’s just a help that free up time for you to think about bigger problems. It ensures you can quickly fix these pesky details and think more about the bigger picture.
You have found something AutoRefactor should do? Feel free to create an issue describing what you would like.
Be ready to interact with the team.