Late at night.
Colleagues, this week submitted a written code. We develop a graphical editor canvas, the shape of the adjustment has been achieved, i.e., to adjust the shape (such as rectangular and oval) shape of the edge by dragging the handle.
Code can run normally.
But a little more than repeat the code. Each shape (for example, rectangle and ellipse) with a different handle, the drag on the position and size influence the shape of the handle to the different directions are not the same. If you hold down the Shift key, change the size while maintaining the same proportion. This involves a lot of math.
The code looks like this:
let Rectangle = { resizeTopLeft(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeTopRight(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeBottomLeft(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeBottomRight(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, }; let Oval = { resizeLeft(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeRight(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeTop(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeBottom(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, }; let Header = { resizeLeft(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeRight(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, } let TextBlock = { resizeTopLeft(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeTopRight(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeBottomLeft(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, resizeBottomRight(position, size, preserveAspect, dx, dy) { // 10 repetitive lines of math }, };
Those repeated code really getting on my nerves.
This code is not enough clean.
Most repeated because adjusting the shape in the same direction are similar codes, such as Oval.resizeLeft() , and Header.resizeLeft() is very similar.
Other repeating method is the same as between one shape is very similar, for example Oval.resizeLeft() , and Oval other methods is very similar. Further, Rectangle, Header and TextBlock there are repeated between the places, because the text box is a rectangle.
Based on the above analysis, it is clear the idea of reconstruction.
We can group the code, and then repeat the code is removed out. Like this:
let Directions = { top(...) { // 5 unique lines of math }, left(...) { // 5 unique lines of math }, bottom(...) { // 5 unique lines of math }, right(...) { // 5 unique lines of math }, }; let Shapes = { Oval(...) { // 5 unique lines of math }, Rectangle(...) { // 5 unique lines of math }, }
Then, they act together.
let {top, bottom, left, right} = Directions;
function createHandle(directions) {
// 20 lines of code
}
let fourCorners = [
createHandle([top, left]),
createHandle([top, right]),
createHandle([bottom, left]),
createHandle([bottom, right]),
];
let fourSides = [
createHandle([top]),
createHandle([left]),
createHandle([right]),
createHandle([bottom]),
];
let twoSides = [
createHandle([left]),
createHandle([right]),
];
function createBox(shape, handles) {
// 20 lines of code
}
let Rectangle = createBox(Shapes.Rectangle, fourCorners);
let Oval = createBox(Shapes.Oval, fourSides);
let Header = createBox(Shapes.Rectangle, twoSides);
let TextBox = createBox(Shapes.Rectangle, fourCorners);
The amount of code is reduced by half, duplicate code completely gone! All of a sudden cleana. If you want to modify a 形状or 方向behavior, only you need to make changes in one place, no need to modify all the way. Late at night, I submitted the code to change a good master branch, then go to bed. Because my colleagues to help clean up the messy code, I was very proud.
the next day
Things did not happen like that I expected. The boss talked to me, they want me to go back to the code rollback. I was very surprised, after all, the original code is simply a mess, but I changed very clean ah! I reluctantly agreed, but after a few years, I realized that they actually are right.
The only way
Obsessed "clean Code" and delete duplicate code is a stage many of us will experience. When we are not very confident of their own code , it is easy to professional pride and self-worth can be measured in touch with some of the things together, such as lint strict rules, naming conventions, file structure, there is no duplication. We can not automatically remove duplicate code, but you can make your own. After each modify the code, we can easily know that code duplication is less or more. So, remove duplicate sense of the code is like to improve code quality . Worse, it disturbs people's sense of identity , so that they feel, "I am the kind of person to write CLean Code", but in fact is tantamount to self-deception. Once you learn the abstract, we can easily produce very high expectations for this ability when I see duplicate code will want them abstract. After a few years writing code, we find duplicated code everywhere, and our ability to abstract became a super obtained. If someone tells us that abstraction is a virtue, then we will certainly be convinced, and because people do not advocate "CLean Code" and for them to give lessons. Now, code refactoring is a disaster before, I know, for the following reasons.
- First of all, I did not write the code in advance and people communicate . I directly modify their code and submission, and they did not discuss. Even though this is an improvement (but I do not think so), but I like this way of doing things is not commendable. A healthy project team should be based on trust basis, without discussion on the amendment of the code of others will team a heavy blow.
- Secondly, there is no free lunch. I'm with the expense of flexibility, in order to reduce duplication of code , which is not really a good trade-off. For example, then we handle different requirements of different shapes have some special behavior, was I refactored the code needs to be modified several times to meet demand, while the original "messy" code but they can easily fulfill these requirements .
Well, I mean, we should try to write "Dirty" code? of course not. I just suggest that you consider what is the depth of thinking when the "Clean" or "Dirty" code. What did you feel? disgust? justice? beautiful? elegant? You can be sure these qualities will bring substantial engineering effort it? How do they affect the way the preparation and revision of the code? I really have not thought about these things in depth. I only take into account the code itself, but never thought about the evolution of the relationship between the code team. Coding is like a journey, think about what you write from the first line to how far away now. When first reconstructed by extracting function or class to make the complex simple code change, I think it is kind of fun. If you are proud of their "masterpiece", then it is easy to fall into the pursuit clean Codeof the vortex. But do not stop there! Not only a dedication to clean Code reconstruction mad. Write clean Code is not our ultimate goal, we just try to deal with this way find a complex systematic approach . When you are not sure the code will change the code base What impact, it is necessary unknown ocean guidelines lighthouse , then this is definitely a defense mechanism. Write clean codecan be used as a direction, but there is still a long way behind the need to explore .
Author: Dan Abramov | Translator: Ignorance | planning: Ash
Description link