For many, in the process of embedded software development, modularization seems like a mirage, a written term, a past trend—modularization seems to have never truly been realized. When boasting, people often disdainfully say: “You may not have seen a pig run, but have you never eaten pork?” In fact, if the subject of discussion is embedded software, many may really have never seen a pig run. Before the topic becomes more like an urban legend, I want to ask a question:
Why modularize?
Experienced people would say:
To achieve code reuse.
Further—”Why can modularization achieve code reuse?” Many would say:
Isn’t that obvious? If the code is made into a module, then other projects can use it directly, and this part of the code in the module is reused.
Even further—”What is the purpose of code reuse?” Hearing this, project managers take a last drag from their cigarette butts, casually toss it to the ground, stomp it out, and prepare to leave:
Code reuse can save development time and accelerate project development speed.
To stifle the words “You all take your time, I have things to do” that are on the tip of their tongues, let’s ask another question:
In actual project development, does using modules really speed up the project’s progress? Is time really saved?
Project managers became still, slowly sitting back down from their half-raised positions. This time, their tone was serious:
No, using modules does not necessarily speed up project progress. Honestly, when using someone else’s module, programmers often have to seriously understand the module’s functionality and code to confirm the scope of the problem during debugging. You know, many times, the time spent understanding someone else’s code is longer than redesigning it themselves.
Many programmers around nodded in agreement, some even seriously shook their heads. In fact, we have already discovered that in practice, aside from the technology used for modularization, using modules to achieve code reuse often does not speed up a team’s development speed—so why modularize?
It is still too early to draw conclusions. From the descriptions of project managers, we can see:
-
The purpose or motivation of code reuse is to save development time
-
In practice, programmers, for various reasons, always spend a lot of time understanding the code when using modules to feel “safe” using it.
According to our description in What is Embedded (Part 1), a program (software) is “the thinking that programmers try to solidify”; while a module (hardware) is “the logic that has already been solidified”, understanding a piece of code actually involves deducing the thoughts of the module’s creator through the static code logic, which is a reverse process, and this is a process of indirect communication between people using code. When the logic itself is relatively complex, it is evidently more difficult than translating one’s own thoughts directly into a program (redesigning it).
Through the above analysis, it is easy to see that modularization is meant to speed up development through code reuse, and it is precisely the programmers’ need to read the code they want to reuse that undermines this effort. Thus, we can directly conclude:
When using modules, programmers must be prevented from reading the code they want to reuse.
Or in other words:
When using modules, one must focus on the use of the module, while intentionally ignoring the implementation logic of the module, and must psychologically trust the module. In short, one must treat the module as a black box!
It is easy to see that the above conclusion is drawn from the perspective of project managers, as they focus on the project itself, the rational use of various resources, and the project’s progress—the only thing project managers do not need to and should not focus on is specific technical implementation details. So from the perspective of frontline programmers, how do we view this issue?
Why do programmers need to read the code implementation of modules?
The author has asked programmers with different lengths of experience, and from their perspectives, it boils down to the following reasons:
-
For learning purposes—want to know how others implement it. Many programmers believe that reading others’ code can quickly learn from their experiences and improve themselves.
However, from the perspective of project management, it is understandable, or even commendable, that programmers use their spare time to read others’ code to improve themselves. However, sacrificing precious project time to read the implementation code of modules instead of focusing on the use of the module (quickly implementing the required functions for the project) is far more detrimental than beneficial to the project itself—reading code brings improvement to the programmer’s abilities, which is a long-term benefit for the team, but this benefit has little to no timeliness for the project itself—there is a saying that distant water cannot quench a nearby thirst, and that’s what it means.
In fact, project managers usually allocate tasks based on the existing capabilities of programmers and do not hope that programmers will improve by reading module code and then return to help with this urgent project—if there are project managers who do this, then it can only be said that the slow progress is completely not the fault of programmers reading module code, but rather a direct personnel issue—one can only believe that perhaps they really have no one else available.
So the conclusion is: strictly prohibit reading module source code for learning purposes during work hours.
-
For debugging purposes—perhaps not all programmers have an innate confidence in the quality of their own code, but almost all programmers inherently distrust the code written by others (modules)—just like Kong Yiji, who must see the bartender scoop wine from the jar and confirm it is not watered down to feel at ease—so when problems arise, they must suspect the module, and many irresponsible programmers will instinctively suspect the module first—since it’s not written by them, how can they be at ease—so during debugging:
-
Source code must be available, otherwise debugging cannot proceed.
-
They must read the module’s code, otherwise, they won’t know if the source code is correct.
-
They must understand the module’s code, otherwise, how can they claim that “the error in their program is entirely due to the module’s poor coding”?
For this situation, personally, I have only one principle—do not provide source code! Only provide library files—trust me, programmers who are usually at a loss when facing assembly code will automatically ignore the implementation details of the module during debugging and focus on the input-output behavior of the module’s interface—what input is given, what output is expected, and what output is actually obtained—clear and straightforward. If the expected output and the observed actual output differ, the problem is found: either the documentation was not read well, there was a misunderstanding of input-output; or the input was incorrect; or the module has a problem. This is definitely much faster than understanding the source code before debugging!—unless the module written by someone else needs you to maintain it… So, during debugging
There is absolutely NO NEED to read the source code of the module!
There is absolutely NO NEED to read the source code of the module!
There is absolutely NO NEED to read the source code of the module!
The reason for reading the source code of the module under the guise of debugging is fundamentally untenable!
For imitation purposes—there’s nothing much to say about this purpose; if someone gives you the source code, it’s a mistake. Please consciously resist ignoring others’ intellectual property. Technically, because you need to read others’ implementations to create your own version and understand their thinking, this is a white-box behavior, and thus does not belong to the normal use of modules, but rather falls within the ordinary development scope.
Since during the use of modules, neither for learning nor debugging purposes is there a need to read the module’s source code, we can clearly conclude: programmers do not need to, nor should they waste project time reading source code during the use of modules. A team can only speed up project development through code reuse if they achieve this.
When a project’s manager understands the significant harm of “reading module code” to the project and formally prohibits this behavior from programmers—removing the stumbling block to modularization practice; then how should the technical manager understand, design, and practice a modular architecture that suits the current team and project needs?
Recommended Reading:
Embedded Programming Series
Linux Learning Series
C/C++ Programming Series
Qt Advanced Learning Series
If you like my thoughts, feel free to subscribe to Naked Machine Thinking