Hot answers tagged refactoring
45
Sounds like a good habit to me. First rule in coding is to make it work. Once you've done that, clean up your code and make it neat, understandable and simpler if you can.
However - if you are spending a lot of time over designing your solution and wasting a lot of time creating stuff that doesn't need to exist, that's possibly a bad habit - like if you ...
20
My answer may be little off topic, but this method works for me.
Before you even start programming you have to think: what kind of structures I need to solve a problem, and what kind of algorithms.
Often you will find that solution already exist and that you only have to implement it into your project*. Never try to reinvent a wheel - if you need ...
14
There are (seemingly) opposing forces in play.
On the one hand, you want to enforce encapsulation
On the other hand, you want to be able to test the software
Proponents of keeping all 'implementation details' private are usually motivated by the desire to maintain encapsulation. However, keeping everything locked down and unavailable is a misunderstood ...
11
Looks like you're talking about dependency injection. It's really common, and IMO, pretty necessary for testability.
To address the broader question of whether it's a good idea to modify code just to make it testable, think of it this way: code has multiple responsibilities, including a) to be executed, b) to be read by humans, and c) to be tested. All ...
9
What would help when refactoring a large method to ensure that I don't break anything?
Short answer: small steps.
The problem is that when I refactor a tiny part of a 500 LOC private method, adding unit tests appears to be a difficult task.
Consider these steps:
Move the implementation into a different (private) function and delegate the call.
...
9
I have had similar challenges. The Working with Legacy Code book is a great resource, but there's an assumption that you can shoe-horn in unit tests to support your work. Sometimes that's just not possible.
In my archeology work (my term for maintenance on legacy code like this), I follow a similar approach as to what you outlined.
Start with a solid ...
8
I would go for a variant to your second option that allows you to phase-out the old, too generic, name DataSource:
abstract class AbstractDataSource { ... } // corresponds to the abstract DataSource in the ideal solution
class XmlDataSource : AbstractDataSource { ... }
class MdbDataSource : AbstractDataSource { ... } // contains all the code of the ...
7
I find that when I work out on paper what I want to do ahead of time, that I make less unnecessary code. Sometimes I end up with several drafts on paper, so it's still an iterative process, but the iterations tend to be faster, since you don't have to get all the way to working code to realize that something you thought was a good idea won't work after all. ...
7
It's a bit of a chicken and egg problem.
One of the biggest reasons why it's good to have good test coverage of your code is that it allows you to refactor fearlessly. But you're in a situation where you need to refactor the code in order to get good test coverage! And your colleague is fearful.
I see your colleague's point of view. You have code which ...
6
I think this rule of thumb exists because it is easy to get caught into playing "What if..." when designing the code for the first time or after the first duplication. I've encountered severe analysis paralysis in some cases because people started designing functionality that might be needed later. But not needed for the immediate problem at hand.
There ...
5
I do not mean this in a patronising manner but if possible you should consider moving away from VB6 for future work. In the meantime my personal view is that you should not be too concerned about the number of lines of code in your solution. The real concern is the cost of maintenance. If this is a solution that is going to evolve further then you should ...
4
Rewriting it from scratch will likely take more time than refactoring and working with legacy code, unless the legacy code is truly a disaster.
Instead, I recommend spending some extra time during the beginning of each project to refactor the code more, to let you work with it more easily. This is probably a more time-effective approach, and over time, your ...
4
Writing and re-writing code isn't a problem, nor is writing more code than is absolutely necessary. Every time you write code and throw it away or refactor it you are learning--in fact it's possibly the best way to learn. Trying to be "Optimal" about your coding type or typing time is really harmful to all involved.
Also, all those "Extra" variables are ...
4
The best solution will be something close to your option #3. Keep the DataSource mostly as it is now, and extract just the reader part into its own class.
class DataSource {
private Reader reader;
DataSource(string fileName) {
reader = ... ? new MdbReader(fileName) : new XmlReader(fileName);
}
Data ReadData() {
return ...
3
There are a few reasons to rewrite from scratch. I already mentioned them in another answer. In short, the reasons to reinvent the wheel I mentioned are:
Because someone doesn't know that the wheel exist already,
Because someone knows that the wheel exist, but doesn't like it,
Because someone believes she can make a commercial scale product,
Because it's ...
3
Is the cyclomatic complexity of the function below 5?
Did you completely understand what cyclomatic complexity was without following that link?
Do you have an automated test or documented test case for every path through the function?
Do all of the existing test cases pass?
Can you explain the function and all it's edge cases to me in less than 1 minute?
...
3
The best coders and average coders usually have similar code, the difference is how long it takes them to do it. If you take the time to plan ahead and solve the problem before you start coding it will help you become one of the best coders. Obviously you won't be able to foresee every problem so you will have to make the little things work and that can ...
2
Nothing wrong with this habbit in my opinion. The longer you code, the better your coding and problem solving skills will get, thus all of the "extra" code will get less.
I've been working as a junior software engineer for about two years now, and still use this sort of approach, with the difference being that as time has gone by, I've been more often ...
2
Verbosity is very common for junior programmer, but you are more advanced that you aware those verbosity and try to remove it.
At first it might sounds like a good habit that you always refactor, but if you need a lot of refactoring after first time it means you should improve your initial coding performance.
Refactoring more often is the key. Don't wait ...
2
Just try to mark your extraneous code if possible. Variable checks can be written as assertions for example which add semantical information to your code, I.e. these properties have to be fulfilled etc. Since assertions are usually dropped in "release mode" (depending on language/plattform) lots of assertions do not have to be removed but can function as ...
2
What language are you using?
If it is an object oriented language like Java or C++ make sure you understand OO Design principles like S.O.L.I.D. Also, learn some design patterns and try and analyse your current code to see if you could re-factor it to add some patterns. Design patterns will help with maintainability and extensibility in the future, and they ...
2
Usually Unit Tests are the way to go.
Make the needed tests that prove that the current works as expected.
Take your time and the last test must make you confident on the output.
What can help me in knowing which unit tests are relevant for a given
piece of code?
You're in the process of refactoring a piece of code, you must know exactly what it ...
1
This may just be a difference in emphasis from the other answers, but I'd say that the code should not be refactored strictly to improve the testability. Testability is highly important for maintenance, but testability is not an end in itself. As such, I would defer any such refactoring until you can predict that this code will need maintenance to further ...
1
A good and common practice is to use Unit testing and debug logs. Unit tests ensures that if you make any further changes in program, your old functionality is not breaking. Debug logs can help you trace the program at run time.
Sometimes it happens that even beyond that we need to have something only for testing purpose. It is not unusual to change the ...
1
Your current description could use clarification - calling functions and assigning them to local variables generally doesn't do anything useful except for the side effects of the calls.
Also if the two methods were exactly the same code as your question suggests then you'd really only need one method, and call that from the places where you now call the two ...
1
According to Patterns of Enterprise Application Architecture, you can use a Table Data Gateway with the Transaction Script pattern (see the "When To Use It" section of the Table Data Gateway pattern). So your approach seems like a pretty conservative way to move towards better code without radically changing the original style all at once - which is a good ...
1
In this case I'd use a simple text search to find references to "gold", then use a refactor tool to rename the variables and methods. After that, running the test suite should confirm that there's no issues.
If renaming variables or methods causes issues, you should look at your workflow and find out why it's a problem. If it's very problematic, you could ...
1
I'm struggling with some of these issues currently, and was looking for other people's approaches when I came across this question. I thought I'd toss some thoughts up here just in case they help someone coming down this route later.
The approach I've decided upon has the following:
The model layer has no access control logic in it, with the exception ...
Only top voted, non community-wiki answers of a minimum length are eligible
