Other Development Methods

In fact, there are still many such things. such as:

1) Configuration management issues . For the configuration management of source code, it is not a simple matter. Configuration management and the structure of the software and team structure are very relevant. I have seen two very inefficient configuration management, one is to open the project branch to do the project, while opening a lot of branches, the branch opening time is still very long, which causes the merge back to the trunk to spend a lot of time to solve Various conflicts, the other is that N more teams are modified in a code base, resulting in a lot of complicated problems, such as a bug in a team's changes, or all the team's functions have to wait for this bug to be Fixes can be released, or all changes can be rolled back to the previous version, including features developed by other teams. Obviously, the structure of the software module, the architecture of the software, and the organization of the team will seriously affect the development efficiency.

2) Human flesh-based software development . Most software teams and supervisors use "not enough people" as an excuse for developing insufficient efficiency, and most of the failures will use a heavier "human flesh process" to make up for their lack of ability. They never thought about using "technology" and using a more "smart" way to solve problems.

3) Conference-driven development . There are more people, more teams, more ideas, more communication, so you need to have a meeting to meet.

In summary, I have the following summary:

1) The more detailed the division of software engineers is, the less efficient the team is. The service between teams is the key . Whether it is from the language or from the division of labor on the software module, the finer the worse. Service is not something I want to do for you, but it is easier for me to let you do things.

2) You always need to be serious in one link. The more efficient this link is, the less efficient you will be . Either you design and code carefully, otherwise you have to be serious about testing. If you are not careful in designing, coding, and testing, then you have to be serious in operation and maintenance, and you have to deal with the fault seriously. You always need to be serious in one place. Another article you can look at - " More time to write less code "

3) Only the small team, the internal consumption will be small, only the conditions or resources are limited, will force you to use the most economical means to do the most valuable things, will force you to like simplicity and simplicity.

4) Technical debt cannot be owed, and it is necessary to pay debts relentlessly . A lot of things will not be there at first, then there will never be. Once a thing is rotten, the back can only be followed by rotten, the more rotten, the less people dare to pay debts.

5) The software architecture should be loosely coupled, and the team should be tightly coupled .

6) Engineer culture is the key, and attaching importance to the process is to pay attention to the results . The KPI that only pays attention to the result is equivalent to “exhaustion and fishing” and “drinking and quenching thirst”.