The Way to Neat Code
Synopsis:
This book is a summary of the experience of programming guru "Uncle Bob" over 40 years of programming career, explaining what kind of attitude, what kind of principles and what kind of actions are needed to become a real professional programmer. The author takes the detours and mistakes he and his colleagues have made as examples, with the intention of guiding those who come after him and helping them to take a higher step in their careers.
This book is suitable for all programmers and can be used as a reference for all those who want to become professionally literate in the workplace.
Chapter XII. Collaboration
Most software is developed by teams. Teams are most effective when their members are able to work with each other in a very professional manner. Working alone and outside the team is unprofessional.
12.1 Programmers and People
We didn't choose to be programmers because we like working with other people. We all agree that human relationships are difficult and irregular. Programming machines is neat and predictable behavior.It would be the most enjoyable time to be able to stay alone in a room for hours immersed in some really interesting issues.
Well, I may be generalizing a bit by saying that, and it's true that there are quite a few exceptions. There are many programmers who are very good at working and collaborating with others and enjoy the challenges involved. But the average profile of the group as a whole is still moving in the direction I've described.We, programmers, still enjoy expressionless contemplation the most, wrapping ourselves up like cocoons and immersing ourselves in problematic thinking.
Programmers and Employers:
A professional programmer's primary responsibility is to meet the needs of their employer. This means working well with your managers, business analysts, test engineers, and other team members to deeply understand the business goals. This doesn't mean you have to be a business guru, but you need to understand what the business value of the code you're writing is, and how the organization that fires you is going to reap the rewards of your work.
As a result, professional programmers will take the time to understand the business. They will talk to users about the software they are using, they will talk to sales and marketing people about the problems they are experiencing, and they will talk to managers to clarify the team's short-term and long-term goals.
Programmers and programmers:
It's often difficult for programmers to work closely with each other, which can lead to some not-so-small problems.
-
Code Individual All
The worst symptom of a dysfunctional team is that each programmer builds a high wall around his or her code and refuses to let other programmers have access to it. I've seen it in many places where programmers won't even let other programmers see their code. This is the "most effective recipe for disaster".
-
Collaborative code-sharing
I agree with this approach: every member of the team can sign out the code for any module and make any changes they see fit. I expect that it is the whole team that owns the code, not individuals. Professional developers are not going to prevent others from modifying the code. They don't construct ownership barriers over the code, but rather collaborate with each other as much as possible. They learn by working together.
-
twinning
"Professionals will work in pairs." Why? Because for at least some problems, pairing is the most effective solution.
Professionals work in pairs, also because it is the best way to share knowledge.
Professionals are twinning because twinning is the best way to review codes. (The most efficient and effective way to review code is to do it in a collaborative way with each other.）
12.2 Working together
Professionals will work together. You can't participate in collaboration when sitting in a corner with headphones on. Therefore, I expect people to be able to sit around a table and face each other. You need to be able to feel other people's fearful concerns, you need to be able to hear other people's grumblings when things aren't working out, and there needs to be a subconscious exchange of communication both verbally and in body language. The whole team has to be connected as a unified whole.
Maybe you think you do better when you work alone. That may be true, but it doesn't mean that the whole team will do a better job when you work alone. Besides, the truth is that it's unlikely that a person will work better when working alone. There are times when working alone is the right thing to do. When you just need to think long and hard about a problem, it's okay to work alone. When the task is trivial and inconsequential, and working with another person seems wasteful, one can work alone. But generally speaking, working closely with others and in pairs for most of the time is the best practice.
12.3 Conclusion
Maybe we didn't choose to do this work because we can collaborate with people through programming. But unluckily for us, programming means collaborating with people. We need to work with business people, and we need to collaborate with each other.