Refactoring
You should reread “Refactoring”. Refactors compose. In three months you can completely rearchitect a module without breaking it at any point in the process. That’s the promise of refactoring. Functions don’t have an identity. There is no such thing. I don’t know who taught you that but they have broken you in the process. Renaming things is a refactoring. We don’t check the entire commit history to make sure that function name has never existed. Only that it hasn’t existed recently. There’s no identity. One of the reasons to refactor is that the function has been lying about its…
Agreed. The way I explain this to managers is that software development is unlike most work. If I'm making widgets and I fuck up, that widget goes out the door never to be seen again. But in software, today's outputs are tomorrow's raw materials. You can trade quality for speed in the very short term at the cost of future productivity, so you're really trading speed for speed. I should add, though, that one can do the rigorous thinking before or after the doing, and ideally one should do both. That was the key insight behind Martin Fowler's "Refactoring: Improving the Design of Existing…
Don't fix things just for the sake of fixing them. Let new features, bugs, or necessary performance improvements drive your changes. Keep your changes small and focused. You need to ensure that you're delivering business value with each change, rather than embarking on an overwhelming, open-ended task. This is critical if you want the business to support your effort. It demonstrates pragmatism. It will shrink the scope of your changes and make the problem less daunting. You can prove to your boss and your coworkers that it's possible to fix the problem without slowing down new development…
"Refactoring" has a definitive origin, which is Martin Fowler's Refactoring book from 1999. Fowler wanted to write the book using Smalltalk, but because the techniques he wanted to write about were fairly language agnostic, he did it in Java, as that was more popular. Unfortunately I think a lot of programmers missed the point, and now think refactoring is only something that can be done well in languages like Java (static typing) and with IDE support. He's announced a second edition[0] in which he'll use JavaScript, to again prove the point that the techniques matter less than the language…
1. NEVER practice Coincidence driven development. If you get lost, and no longer know why something is not working, do not just keep fiddling and changing things. Simplify the problem. Disable all confounding variables and observe your changes. Open up a repl and try to reproduce the issue in your repl. Read the source code of your dependencies. I have seen this a lot: People fiddle with dependencies trying to get them to work. Crack the code open and read it. 2. Choose your battles. Not every hill can be the one you die on. You cannot control every part of a code-base when you are…
This really depends on what specifically you're struggling with, so going to take some shots in the dark: * "Refactoring" by Martin Fowler would probably help with writing good quality code and doing code reviews (or understanding the reasons for changes requested in others' code reviews). * In my experience, "academic" code tends to be far more prone to very long functions. Understanding the Single Responsibility principle was a very important part of the transition from academic scripts to software engineering for me. If you regularly write functions of 30+ lines, start looking at…
Ok, I'll be the curmudgeon here. In recent software development efforts I have run, I have put for the rule that "All comments are bugs". Comments get separated from the code, make statements about obsolete activities, and often mislead the reader, and even sometimes the author. In place of comments, write code that is as self-explanatory as possible. I refer to Martin Fowler's "Refactoring" as a way of trying to increase my authority in the matter. However, I do back off from this extreme position and put comments on individual methods. Sometimes. What helps is using longer…
Sorry to belabor the point. Again, if what you're doing works for you, more power to you. However, your unit tests should survive starting with one file and breaking it out into multiple files. That's exactly what evolutionary design is, and how I program too. If your tests can't survive it, they're probably too caught up in implementation details. (Or you've fallen into the common trap of defining "unit test" too narrowly.) Also, if you haven't read it, check out Martin Fowler's Refactoring book. It shows how you can do things like splitting one file into multiple without rewriting. What I…
Some good points there. When it comes to source code, I believe that it all boils down to how detail-oriented the programmer is, and the source code will be a reflection of that. Everything from formatting, white-spacing to method/variable names counts I have come across places where a programmer chooses to name a variable "temp" rather than giving it a descriptive name, and that annoys the snot out of me. Even if it a temp (and which local variable isn't, in a language like Java) take the time to think about it and name it appropriately! Some pointers that I use for maintaining source code…
"Make the change easy, then make the easy change" hadn't even been coined as a phrase yet when I discovered the utility of that behavior. When I read 'Refactoring (Fowler)' it was more like psychotherapy than a roadmap to better software. "So that's why I am like this." When we get unstuck on a problem it's usually due to finding a new perspective. Sometimes those come as epiphanies, but while miracles do happen, planning on them leads to disappointment. Sometimes you just have to do the work. Finding new perspectives 'the hard way' involves looking at the problem from different angles, and…