Refactoring is the process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure. The idea of improving an already written code is appreciated in most Agile teams. Continuous improvement is is something that these teams strive for. However, improving the already existing code involves time and money. Is it worth it?
Microsoft has decided to continue licensing CodeRush Xpress for free for developers using the non-free editions of Visual Studio 2010. Developer Express has released the beta version of CodeRush 10.1.1, containing features related to code selection, code navigation, class/field/variable declaration and refactoring.
Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt.
The goal of refactoring and rewriting is to improve the sanity of the system by improving the code readability, structure and clarity. A clean code would be easier to maintain and enhance. However, on many occasions Agile teams have a tough time deciding between the two.
Jimmy Bogard, Charlie Poole, Lior Friedman, Charlie Poole and others give their guidelines for more readable and useful unit tests.
Rails 2.3.3 is now available. Among the usual bug fixes, it adds a few new features like ActiveRecord touch functionality and some JSON related API changes. Also: a look at what's up with Rails 3 and Merb 1.1.
Ruby on Rails has been around for about 5 years and in those years developers have created a lot of applications. Many of those applications were created while learning Ruby and Ruby on Rails and may not have used the best practices but yet made it into production web sites. These web applications can be problematical but a new book focused on the solution is available.
When should you refactor? There are times when you simply need to pay down technical debt - you should stop and refactor. No, you should only refactor when one is working on a User Story. Which advice is best? Is there, perhaps, a third option?
A recent discussion on the Extreme Programming Yahoo Group explored the apparent conflict between making software reusable and the XP practice of not writing code until it is needed. Ron Jeffries and others shared insights about the costs and benefits of code reuse, as well as how and when to do it in an agile environment.
A few days ago ReSharper 4.5 Beta was released by JetBrains. This new version promise better performance and less memory consumption. New features include VB9 support, native MSTest support, "Go to Implementation" and improved compatibility with F#, Compact Framework and Silverlight.
RFactor is a Ruby refactoring tool that aims to bring automated refactoring support to text editors. We talked to its developer Fabio Kung to learn how it works and what's planned for the future.
It's not news that at the heart of successful software systems (and, frankly, fulfilling software careers) is good design. Also not news is that defining what "good design" really means has been at the heart of many debates, papers, talks, books, discussions, and more for ages. To help, J.B. Rainsberger and Scott Bellware offer some advice to follow until that one true definition comes along.
DevExpress has announced the availability of CodeRush Xpress for C#, a free add-in for Visual Studio 2008. CodeRush Xpress offers code navigation features like Highlight All References, Smart Clipboard Operations, Generate from Using (TDD), and 25 code refactoring features like Make Explicit, Make Implicit, Name Anonymous Type, and others.
We interviewed Immo Landwerth of the open source project Clone Detective for Visual Studio. This project leverages ConQAT to analyze C# code for duplication.
A Technical Debt Workshop was recently held to improve our industry's understanding of and approach to "technical debt", resulting in some interesting ideas. Among them, changing our perception of the problem to focus on "assets" rather than "debt", an idea now receiving quite a bit of attention by people such as Michael Feathers and Brian Marick.