"Go" writing high-quality Code 157 recommendations for improving C # programs--recommendation 154: Don't overdo it, get the fun of refactoring in agile

Recommendation 154: Don't overdo it, and experience the fun of refactoring in agile

Sometimes, we have to change the design of the software at any time:

• If the project is for a large organization, different levels of software users will ask different needs, or as the key positions of staff turnover, the demand will change with the individual will.
• If our competitors add new requirements, we also have to adjust the design for the new product we are developing.
• The beginning of the architecture is too bad, it may be due to the lack of design experience or architects irresponsible.

The above describes several scenarios in which requirements and designs must be modified externally and internally. In other words, in the software development process, changes will almost always occur.

To capture the changing needs, software development must become "agile" enough. Design should also stay in the "high-level", with a guiding role, and functional modules (or code) need to be gradually improved. We refer to the process of improvement as "refactoring".

Traditional waterfall development is replaced by various agile development frameworks in software field because it can't meet the change of demand.

The agile development model divides the entire development process into one iteration, with each iteration having a period of about two weeks to one months. Each iteration is broadly divided into the following steps.

Agile Development uses the user story, which is categorized as a backlog in the TFS Agile specification, to approve requirements and workload metrics. At the beginning of an iteration, the development team should pick the user story as the target of this iteration, and at the end of each iteration, the user story should be developed. The entire development department must publish a version that can be run to the customer (the object can be a real user, or it can be a team operating unit). This helps customers to adjust their expectations of the product in a timely manner and to revise possible changes in demand. As a development team, you can also modify the requirements, even the design, based on customer feedback.

Because agile development embraces change, the design should be modifiable as the entire development process is implemented, and the status of refactoring is improved. In an agile development system, we can bring it into the entire development process as a task.

As a team, it is necessary to periodically review whether the module can be refactored. As a developer, it is recommended that once you sniff the bad taste of the code, you need to refactor our code.

We don't want to keep the first version of the code very neat, that's unrealistic, and it's not going to make sense to developers. Of course, we should not let the cumbersome code forever in the first version of the state, such code, so I am not satisfied.

Turn from: 157 recommendations for writing high-quality code to improve C # programs Minjia

"Go" writing high-quality Code 157 recommendations for improving C # programs--recommendation 154: Don't overdo it, get the fun of refactoring in agile