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.
In comparison to Java, an emphasis on continuous refactoring is still relatively new in .NET. Besides having few ardent proponents, many myths linger around what refactoring really is and how it applies to the development process in general. Danijel Arsenovski, author of Professional Refactoring in Visual Basic, attempts to dispel some of these myths.
JetBrains has released the much-anticipated productivity Visual Studio add-in, ReSharper 4.0. Resharper 4.0 includes many improvements and new features.
In this interview, Michael Stal describes what architecture refactoring is about and how it relates to both code refactoring and patterns. He describes some architectural refactorings by giving real work examples from his work as Siemens, and he elaborates on some situations where you may want to avoid doing this kind of refactorings.
At JAOO '07 Bob Martin asserted: "it is irresponsible for a developer to ship a line of code he has not executed in a unit test." In this InfoQ video, Martin debated with another well respected software thought leader, Jim Coplien, on this and other topics, including Design by Contract vs. TDD and how much up-front architecture is needed to keep a system consistent with the business domain model.
After asserting that one must, as a rule, always version their database work, Scott Allen detailed an approach to making the best of versioning databases. Allen presented a comprehensive, practical approach to creating a baseline, using change scripts to manage schematic revisions, controlling programmatic database objects, and handling branching and merging.
Patrick Smacchia, a Microsoft C# MVP, talks about his product NDepend and how it helps resolving issues in your code. Large code bases can be very complex to manage and the right tools make navigating so much easier.
Steve Yegge touched a nerve in the development community when he argued that keeping the code size to an absolute minimum is the most important thing when developing software. In his view, you may have to sacrifice some design patterns and avoid refactoring at times just to keep the lines of code down. And if your problem is large enough - you may have to switch to another programming language.