When you read the code, it’s time to rewriting code

If you ask a software developer what time they spend the most work on, they will tell you that they spend most of their time writing code.

However, if you really observe the work that software developers spend their time doing, then you will realize that they spend most of their time trying to understand the code:

Much of a programmer's working time is used to read code.

As Peter Hallam explained:

Why does editing code take 5 times more time to write new code? The new code becomes old almost immediately. You write some new code. Then go out to make a cup of coffee. And suddenly all your code has been written to become the old code. The brand-new code is almost exclusively available at the initial design stage, but this phase is not much. Most software development projects use iterative development methods. Software architecture design, programming, testing, repetition. Repeat a lot. Only the code in the first iteration is considered a completely new code. After the first iteration process, the code is quickly edited more and more than the new code. Furthermore, almost all code changes made during the error correction process (fix bug) fall into the code editing category. Look at [Microsoft Visual Studio product development team]; milestones in our bug fixes are as much as milestones about new features. The job of editing code is more time consuming for a professional software developer than writing new code.

Why is the reading of code cost 3 times more time than code editing? Before editing the code, you must first understand what it does. The same is true in any existing code refactoring activity – you have to understand the behavior of that code so that you can ensure that the refactoring did not change anything unexpected. want. When you debugging, the time you spend understanding the problem is many times greater than the time you actually used to fix the problem. Once you have fixed that problem, you need to understand the new code to make sure that the fix is ​​just right. Even when writing new code, you never have to start from scratch. You will call the existing code to do most of your work. Either use the code already written or a library provided by Microsoft, or even a third-party dll provided. Before calling this existing code, you must understand it in detail. When writing my first XML application, I had to spend a lot of time understanding the details of XML library classes rather than actually writing the code. When adding new features, you must understand the characteristics that exist so that you can reuse in the right place. Reading code is an activity that professional software developers spend most of their time doing.

I think the way most software developers "understand" the code means that they are rewriting it. My friend Joel thinks that rewriting code is always a bad idea. I'm not sure if that is correct. But according to The Universe in a Nutshell , it is said that the words written on the blackboard by the famous physicist Richard Feynman at the time of his death were:

Something I can't create, I don't understand.

That doesn't mean developers want to rewrite everything; which means that very few programmers are smart enough to understand the code without rewriting it. And just as I believe in the efficiency of reading code, I also believe that the only way to become better at writing code is to write a lot of code. As much as possible. Whether good, bad, or whatever. Nobody wants developers to reinvent the wheel (again), but just reading to see how those wheels work is far inferior to the experience of driving around on some. the wheel you created them yourself.

Understanding someone's code – really understands how all of them can function smoothly – losing a large number of mental efforts. And, even then a question arises, is the source code really the best way to understand an application? After reading the provocative thoughts of Nate Comb in a blog post, I also wondered:

Is Martians wishing to understand the rules of the famous game World of Warcraft (WoW) better by trying to read its source code or watching millions of hours of video recording the battle scene on the screen?

"If someone is reading the game code, do you think they can learn how to play well [Monopoly]?"

I have worked on a lot of applications that even the majority of source code is written by myself , and I have had problems explaining exactly how that application works. Imagine how difficult it would be for this explanation to the project that has 3, or 5, or 12 programmers involved.

Does the source code really tell the story of that application? I'm not sure. Perhaps the best way to understand an application is paradoxically, it is ignoring its entire source code. If you want to know how that application really works, look carefully to see how users use it. Then write a version of yourself.