More on this book
Community
Kindle Notes & Highlights
Read between
October 1 - October 14, 2018
Remember, code is your house, and you have to live in it.
Another advantage of Wrap Method is that it explicitly makes the new functionality independent of existing functionality. When you wrap, you are not intertwining code for one purpose with code for another.
But if you consistently do these little improvements, your system will start to look significantly different over the course of a couple of months. At some point, you’ll come to work in the morning expecting to sink your hands into some slime and discover, “Huh, this code looks pretty good. It looks like someone was in here refactoring recently.” At that point, when you feel the difference between good code and bad code in your gut, you are a changed person.
One thing that really helps development is code reuse. If we can buy a library that solves some problem for us (and figure out how to use it), we can often cut substantial time off a project.
Sketching isn’t the only thing that aids understanding. Another technique that I often use is listing markup. It is particularly useful with very long methods. The idea is simple and nearly everyone has done it at some time or another, but, frankly, I think it is underused.
This is actually a nice suggestion and an excuse to use your editor's print function and when's the last time you got to do that?
Check out the code from your version-control system. Forget about writing tests. Extract methods, move variables, refactor it whatever way you want to get a better understanding of it—just don’t check it in again. Throw that code away. This is called Scratch refactoring.
Closely related to spikes
The brutal truth is that architecture is too important to be left exclusively to a few people. It’s fine to have an architect, but the key way to keep an architecture intact is to make sure that everyone on the team knows what it is and has a stake in it.
There were some other very good-looking areas of the code base, but there is something mesmerizing about large chunks of procedural code: They seem to beg for more.
if there isn’t a strong overlap between conversation and code, it’s important to ask why.
Domain Driven Design
One of the first things to establish is a class naming convention. Generally, you’ll have at least one unit test class for each class that you work on, so it makes sense to make the unit test class name a variation of the class name.
Sobering reminder of all the testing best practices I can thnkfully take for granted in 2018
Many of the features that people add to systems are little tweaks. They require the addition of a little code and maybe a few more methods. It’s tempting to just make these changes to an existing class. Chances are, the code that you need to add must use data from some existing class, and the easiest thing is to just add code to it. Unfortunately, this easy way of making changes can lead to some serious trouble. When we keep adding code to existing classes, we end up with long methods and large classes. Our software turns into a swamp, and it takes more time to understand how to add new
...more
In Rails see the Mammoth Model or the Triple Thick Controller
The key remedy for big classes is refactoring.
I mean, yeah, sure.
This can be one of the most frustrating things in legacy systems. You need to make a change, and you think, “Oh, that’s all.” Then you discover that you have to make the same change over and over again because there are about a dozen places with similar code in your system.
