When I first entered the computer industry, I simply thought, “As long as the technology is good enough, I can make the project succeed.” But as the razor pushed up the hairline over time, it became increasingly apparent that a force other than technology was at work. This has prompted me to think beyond the boundaries of “writing code” and to think about what’s going on outside of the code. Here are a few premature thoughts.
This is the fifth article in the code Life series, which is listed below:
- Have you ever diss someone else’s code? What makes good code?
- Do programmers and leaders misunderstand project delay?
- A joke from the programmer’s wife
- Success, yoga, huang xiaoming | middle-aged programmers think hard to success
- A coder’s wild idea for the project
Value chain flow
-
“Development to requirements” : it means to give feedback to the product on the incomplete and unreasonable requirements perceived by the coding section r&d, resulting in the need for fine tuning.
-
Test-to-development: Represents code discrepancies found during testing.
-
“Test to requirements” : This reverse flow can occur in many cases, such as when testing and development have different understandings of requirements, and neither can convince the other, so they have to find the product together. Another example is finding unreasonable requirements during the testing phase, communicating with the product, and changing them into new requirements before delivery.
How to reduce the reverse flow of the value chain is the direction that all project team members need to think about and strive for.
Demand consensus
In addition to improving individual business and communication skills, there is another worthwhile direction to work towards reducing value chain reverse flows: improving the common understanding of requirements among all.
Necessity is like literature, a thousand Hamlets in a thousand readers.
Although this metaphor is a bit of an exaggeration, it also makes fun of the fact that requirements documentation is not thorough enough. But this pot product can’t be carried by one person. Even if product documentation is written as rigorously as a mathematical theorem, deviations in the understanding of requirements in product, design, development, and testing cannot be completely eliminated as the value chain flows. So communication is essential.
Deviations slow down the progress of the project and reduce the quality of the project. The later the deviations are discovered, the greater the impact on the project will be. The worst result is that the inconsistency of everyone’s understanding of requirements will be exposed until the testing stage.
Since deviation is inevitable, let it be exposed earlier. In the whole process of value flow, the earlier the understanding deviation is found and the earlier the treatment, the smaller the loss will be.
Product requirements meetings, test cases, and server-side interfaces all contribute to early crashes. (If the iteration cycle is only one week, there is no time for so many meetings, welcome the short iteration friends to leave a comment, share how you deal with the misunderstanding.)
It’s not uncommon for products to read scripted documents, developers to listen carelessly, and for lengthy products to pull out their phones while listening. The worst thing was that reading the product documentation didn’t deepen my understanding of the requirements, and I had to read it carefully before starting development.
Can the r&d team read the product documentation closely first? Think deeply about requirements and even elaborate designs to find boundary cases that are not considered, inconsistent product logic, and low cost product designs.
Can we switch roles? Turn the product requirements meeting into a “requirements q&A”, let R&D take the lead, and put forward questions and suggestions on requirements.
Will this stimulate research and development initiatives? Expose more “understanding biases” when passing requirements?
The module of belonging
The division of development needs to be done before the requirements q&A, which raises another question:
“Should short-term module division become long-term module ownership?” That is, business modules have property rights, so that a module belongs to a research and development for a long time. He takes the lead in the development of the requirements of the module, and he takes the lead in the repair of the bugs of the module. All modifications to the module need to be reviewed by him.
Changing code in unfamiliar modules is a trivial matter. Even if the module code is logically clear, low coupling and easy to expand, it may change the bug because it is not familiar with the specific business logic. What’s more, most of the code is a jumble of logic, high coupling, and a whole lot of it.
Programmers are more or less artisans, taking care of the code they create as if it were their own craft, and this feeling drives them to constantly self-optimize the code. But when it comes to other people’s crafts, that motivation is much reduced.
Only division of labor can specialization, only specialization can improve quality.
Module ownership also changes “centralized code Review” into “distributed code Review”. In the past, all the code was reviewed by the team Leader, but how could the Leader know the details of all the business modules? So it can only be reviewed in general. Why not have it reviewed by the person who knows the code best?
The knowledge sharing
Module ownership also increases risk by significantly reducing the “bus factor”. The bus factor describes the degree of concentration of knowledge in a project, i.e. one bus kills several developers and the whole project can be declared GG.
The knowledge of a particular module is in the hands of only one person, like putting all the chips in one basket. He gets sick, leaves his job, and the module crashes.
If most of the knowledge of the team is concentrated in the hands of a few people, it is not conducive to improving the technical level and anti-risk ability of the whole team.
The sharing of business knowledge can reduce the cost of team development and maintenance, while the sharing of general knowledge can improve the quality of team coding.
Each R & D is good at different fields, and the boundary of knowledge is also different. If knowledge can flow smoothly in the team, and if everyone’s knowledge can be combined, it can not only improve the technical level of the whole team, but also form a good technical atmosphere and stickiness.
“Collective Code Review” may be one way to try knowledge sharing. It encourages two-way communication: put a piece of code out there for Review. All roads lead to Rome, and the one you implement may not be the shortest path, or it may not scale well, or it may not perform well. This is where the collective wisdom shines. A collective review of the same piece of code can lead to many collisions of ideas. The truth is always clearer, and the light of collective wisdom can benefit everyone present.