26 Jin keyu laws in Agile Software Development)

• L make sure that case 1 works properly before case 2 starts

This statement in the kitchen is: "Before starting to cook the next dish, give the current dish to the customer ". The biggest problem in software development is that a lot of tasks are carried out concurrently, so some of the work will inevitably be discarded later, which means that efforts are wasted.

Focus on Case 1 first, so that it can work properly, run relevant tests, write relevant documents, embed all relevant code, and then start the next task;

 

• L never allow build failure

Obviously, this suggestion should be included in any list of software development recommendations; if a programmer has done all the appropriate preventive actions before embedding it and has done enough testing, the build will never fail. If the build fails, someone wants to take a shortcut;

 

• L never write any program before the explicit requirements of Use Cases

When writing a class, you should have a corresponding use case in your mind. At the same time, you should only provide the necessary methods for this use case. Sometimes programmers may consider some of the functions that this class may need. At this time, you should add these considerations as comments, but never write any code, until these potential features are actually needed;

 

• L never add a data member before a use case actually needs it

This is recommended to be the same as the previous one, but its object becomes a data member of the class. Sometimes it may seem obvious that a "user" record will be used somewhere; but you should never add that data member, until you have a specific use case to explicitly use this data;

 

• L do not be afraid to make decisions or change previous decisions

The essence of Agile Software development is to deal with uncertainty and rapid response to changes. In the early stage of development, you may not obtain complete information, so you should make decisions as soon as possible; but sometimes this decision has to be made so that the development work can continue, you can no longer wait for all the information required for this decision. At this time, you should first make the best decision based on the information you have mastered, then, after obtaining more information, you must have the courage to change the previous decision;

 

• L continuously learn how to improve quality

Quality improvements are endless, so you should persistently seek areas where improvements can be made, while at the same time collecting methods to identify and locate software quality problems.

 

• L measurement, measurement, and re-Measurement

Agile development is a way to help teams deal with future uncertainties, but there should be no uncertainty about what has happened. Therefore, various types of attempts should be carried out continuously, at the same time, there should be records for each attempt to measure its effectiveness;

 

• L design around people, not the system

It is too easy for developers to turn their design goals to technical possibilities. In fact, the most important thing is people. We should never forget the final purpose of the software to help some people do their jobs better;

 

• L testing is part of the product

Many developers and managers think that the product is only the function and related code you submit to the customer. Everything else is unimportant. In fact, the test code should be considered as an integral part of the product, it is worthwhile to start a comprehensive consideration at the design stage. In many cases, it should even be submitted to the customer as the final product;

 

• L write test cases before coding

Test cases can be used to clarify the final intent of a design. In many cases, design defects are discovered when the test cases are completed. Think about how much time can be saved if you write test cases before coding. But remember: first write the test of Case 1 and then write the code of Case 1, which must be completed before case 2 starts;

 

• L eliminate waste

Frankly speaking, this has become a cliché that will be mentioned in any software development principle, because it is really too important. Discovering and eliminating waste in software development is a never-ending task. Any effort that does not increase the value of end users is a waste. If you are not sure what value it has for end users, you may not need it.

 

• L create a culture: respond immediately to build failures

Understand the fact that once the build fails, everyone in the project team will be affected, so nothing is more important than ensuring that the core code can be correctly built and tested. I have seen some teams that allow building to expire for several months, because everyone thinks it is the responsibility of others, and everyone suffers, but no one takes action to solve the problem. In this regard, a small effort will benefit the entire team and should become the consensus of the team.

 

• L everyone in the team should fully understand the customer's needs

Large and complex projects should be split into small project teams and further distributed to programmers. However, in this process, you must never lose your understanding of the final purpose of the entire product and the needs of end users. People should always focus on meeting the needs of end users.

 

• L bring together related things

Organize code so that highly correlated things are located in close locations. If possible, put them in a class. This is one of the rules of object-oriented design principles-encapsulation. Ideally, all code outside the class does not need to know how the class works internally. Some programmers like to transfer details between different files for some purpose, for example, to keep all the same data types together or in alphabetical order. Such operations bring unnecessary complexity to the system. Therefore, the guiding principle is to group irrelevant things to reduce the complexity of the system.

 

• L always run all tests before checking in

Some people understand this sentence as running all unit tests before Check in, and some people understand it as running test cases. in fact, I personally think these should all be run before check in.

 

• L premature optimization is the source of all evil

At the micro level, the Code should indeed be written according to the optimal method to avoid unnecessary waste. However, for optimization beyond the method level, it should be carried out after the whole system has undergone a stress test, in addition, this stress test is based on a specific user use case.

If you only understand the static code, you can make an intuitive judgment on the overall performance of the system, which is almost always wrong. On the contrary, it is king to measure the performance of the entire system, identify the 1% code that does have an important impact on the system, and focus on optimizing this part of code.

 

• L minimal list of tasks with incomplete encoding (Status: encoding in progress)

When a developer implements a use case, all the code that has been modified but has not been modified or has not been tested will incur a price. Allowing these half-done changes to last for several days or weeks can significantly increase the risk of waste of work, as many of these semi-finished products may have to be redone.

Assume that there are three tasks, each of which takes one day to complete. If the three tasks are started at the same time, they are processed concurrently every day within three days, resulting in the overhead of nine work units. If the three tasks are processed sequentially, one task is completed every day, and the next task is not started before the previous task is completed, this will only lead to the overhead of the three work units;

This is not consistent with our intuition. Intuition tells us that when three things need to be handled, it is reasonable to carry out three things at the same time; however, software development and physical construction are not the same. Short-cycle, fast, and complete tasks not only reduce the cognitive load, but also reduce the conflict between unfinished jobs among several people.

 

• L never use the number of lines of code to Measure code quality and work efficiency

The number of lines of code required to complete a specific task varies greatly between programmers. The number of lines of code does not tell you much about task completion or code quality. Up to 200 factors may cause different code quality, which makes it meaningless to calculate the number of lines of code. If you want to count, use cases.

 

• L continuous re-design and Reconstruction

Be careful when applying this rule, because some code is too fragile, which makes it very difficult to change them, however, the general principle is that you should not be afraid to change the code that matches the actual use cases. A data member may be an integer in the past, however, do not hesitate to change it when it is needed to become a floating point number.

 

• L Delete useless code

When it comes to code that is not easy to understand, there is a tendency: "Let the sleeping dog lie there "; one example is that when a new method is added to a class to replace the old method, many developers keep the old method just in case. In this case, we should make additional efforts to check whether the old method is still necessary. If there is no evidence that it is necessary to retain it, we should delete it;

The worst change is to comment out a large segment of code, but not delete them. The commented-out code should be deleted immediately after the unit test is successfully run and before the code is checked in. It is easy to add code at any time, but it is difficult to delete code at any time. Therefore, if at some point you realize that there may be something unnecessary, it should take another time to confirm that the code can be deleted, which will improve the maintainability of the Code.

 

• L do not create new languages

One example is to add too many things that end users cannot understand to the configuration file.

 

• L do not design unless you are actually preparing to start encoding and intend to test your changes

You should have a rough understanding of what the system is going to do and what the purpose of the system architecture is, unless development iterations allow a specific design to be implemented and tested, you should neither design in detail nor write down the specific description about a function implementation.

The detailed design only needs to cover the content that just meets the needs of the current use case. The biggest waste in software development is spending a lot of time on unnecessary detailed design issues, or re-design due to incorrect assumptions.

 

• L software is plastic

Different from material processing, software can easily make major changes. In fact, there is sufficient evidence that the software itself is easier to change than the design document used to describe the software. Further, the software itself is more capable of describing what it is designed to do than the instructions. Therefore, you should spend time directly implementing it so that the customer can see the final design details with their own eyes. If you fail to meet customer requirements, you have to change the initial design. directly changing the software itself is easier than changing the description document. More importantly, when the customer sees the system running, the information you get about how they want the system to run is much clearer!

 

• L spend time in the Code for detecting and reporting exceptions to add a complete problem description

Programmers are often too reluctant to add instructions, so that in the thrown exceptions, there is only a very simple description of the problem. They thought they were the only one who saw the problem and thought they would think of the details of the problem based on the vague description. In fact, the customer support overhead is higher than any other reason due to incorrect or incomplete false descriptions. Therefore, to describe every error message, you should assume that you are explaining the problem to a stranger who has just entered the door and has no experience in coding. After all, end users and customer support departments have no experience in coding.

 

Original article:

Http://www.pmhut.com/26-hints-for-agile-software-development/comment-page-1#comment-10565