How can software developers gain insight into their own code?

Recently, I encountered something that hurts me a lot. A c # programmer is proud to announce that he has not understood the Code he wrote a week ago. To be honest, I really want to know what he has to be proud. He is proud that he writes a lot of code every day? Or is anyone willing to give him money to write code?

My opinion on this is: for a professional C # programmer, it is undeniable that you cannot understand the code you wrote a week ago or a year ago.

Yes, I mean. Let me explain it. I have been using software development for 15 years. I accepted some software development principles earlier, and they have been with me so far. I can still easily understand the code I wrote a year ago, two years ago, or twelve years ago. No matter what language it is written, no matter what you call it as a domain, algorithm, analyzer, network application, embedded controller, script, connector or something else. Even if the code was earlier, even if it was hard for me to understand, I could also identify some of the patterns that started to appear.

In fact, to make yourself understand the code you have previously written, the purpose is to make the code readable. Whether you are yourself or others. The Code is as bad or worse as the Code cannot work normally. If you cannot read the code you have written for a while, it is impossible for others to read your code.

For me, it is important to emphasize how easy it is to read and understand your program code, not only because it is a better product maintained by others, and your program source code is in your own toolbox. in your career, you will use and reuse it. In addition, this toolbox is especially authorized and is one of the most notable features for an experienced programmer. I can't expect my problems to be solved immediately. There are similar things in the past, mining my own code archives, finding a solution, or similar problems. Obviously, you cannot put incomprehensible code in your toolbox.

It would be unfair if at least no attempt was made to explain how this feat could be achieved. Frankly speaking, this is not easy to express clearly, but I can try.

I am sure that this is mainly for writers (well, maybe also for their creative industries ). When you break down a few lines of code (the shorter the better), you 'd better stop here and use a little time to check whether this part is understandable. Read it several times. Do not worry about it. Think about it. If I saw this code for the first time, can I still understand it? If the tragedy cannot be discovered ...... Why? Do not hesitate. Make sure that you keep "readability" as a measure of code quality until your entire code segment is understandable.

Once you have fun with these results, read them again and read them again in a few days. This reminds me to write more technical blog articles: every sentence I write has to be rewritten over and over again for 20 times, which is usually the fact that I write code, I have achieved perfection through inherent talent and continuous practice. Because I don't have the former, I can only rely on the latter to make up for diligence.

Finally, it is restructuring and bold improvements. If you encounter a piece of code that can be written more clearly, make it clearer and easier to understand. Improving code quality is our internal task. Its benefits are sometimes difficult to quantify, but if you participate in one or two large-scale projects that have been taking a long time, you will naturally understand it.