26 famous sayings about agile development

I often collect a variety of famous sayings. Recently I have relived agile development. What is the real problem? The following is a list of 26 key principles to guide the Agile Software Development Team.

1. Complete one task and start another thing afterwards: In the kitchen metaphor, it is: "Get this dish first, and then start to make the next one ". The biggest problem with software development is to start a few things at the same time, which will inevitably lead to the waste of some work. Focus on one thing; Fully implement its functions; run tests; write documents; check in all, take this as a task, and then start the next thing.

2. Do not destroy the Build: Obviously, but must be included in any software development suggestion list. The build will never be broken if Programmers take all the appropriate preventive actions for testing before checking in. If the build is damaged, it is usually because someone is lazy.

3. Do not implement the program before the use case is needed: When you implement a specific class, you should have a specific use case in your mind, and at the same time only implement the method required by the use case. You can consider the potential features of this class and write them into comments, but it should not be implemented until the use case is actually needed.

4. Do not add data members before the use case is required: Same as the previous one, but this is from the perspective of data members of the class. It seems obvious that the "customer" record requires a "shipping address", but it should be implemented until the useful example explicitly requires a shipping address.

5. Don't be afraid to make decisions. Don't be afraid to change previous decisions: Agile development is about changes and quick responses. You do not have complete information at the initial stage of development. You should postpone the decision as much as possible until you have to make the decision. Without information, you cannot make your decisions. On the contrary, you can make the best decisions based on valid information. With new information, do not be afraid to change previous decisions. (Some "dinosaurs" are called swinging, but I call it an environment that responds to changes)

6. Continuous learning on how to improve quality: this work will never end, so you should pay attention to the things that can be improved and collect the cases of quality problems being confirmed and handled.

7. Measurement, measurement, and measurement: Agile development helps to deal with future uncertainty, but there should be no uncertainty in the past. The test should run continuously, and the performance of each operation should be measured and recorded.

8. Design for people rather than systems: developers often make design mistakes due to technology. Never forget the ultimate goal of design, that is, to help people complete their work.

9. Testing is part of a product: many developers and managers think that a product is something delivered to the customer, and everything else is not that important. Testing should be considered as a real part of the product, and should be carefully considered during design, or even, in many cases, delivered together with the product to the customer. (The second half is controversial, but built-in testing, as part of Software Delivery, only takes up insignificant space, but provides obvious benefits when necessary. This approach should be taken into consideration .)

10. Compile the test before the code: the test itself can be used to explain the design that is really needed. Design defects are often discovered through test cases. Think about how much time can be saved through these use cases before coding. However, write a test for example 1, encode it, and then start Example 2.

11. Eliminate waste: Frankly speaking, this is another cliché that must be included in the list of any development principles, because it is too important. This work has no end to discovering and eliminating waste. Eliminate anything that cannot increase customer value. If you cannot confirm the customer value, you probably don't need it.

12. Build a culture that responds immediately to build destruction: You must understand that when a build is damaged, it will affect everyone in the project. Therefore, the most important thing is to confirm that the core code is built and tested properly. I have seen some teams that have failed tests for several months because they are the work of others. Everyone is suffering, but no one is taking action. To counter this, a consensus must be formed, that is, a small job can earn a big return for the team.

13. All team members should understand the customer's needs: large and complex projects are naturally divided into independent teams and then assigned to developers. However, what we should not do in this scope is to lose the expectations and objectives of paying attention to the real users of the final project.

14. Put related definitions together: organize code to make highly relevant things together, or in a class. This is a standard object-oriented design encapsulation principle. Ideally, all code outside the class does not need to know the internal work details. Some developers are happy to spread the details to multiple files so that they can be organized in different ways, such as putting all the same data types together or organized alphabetically. For example, placing all constants in a class in different packages they are using increases unnecessary program complexity. The guiding principle should be to group by relevance to hide complexity.

15. Always run the test before checking in: This criterion helps you meet the "Do not break the build" criterion.

16. The source of ten evil in premature optimization: cited by Gartner: the code should be well written to avoid waste at the micro level, however, optimization beyond the independent method level should be conducted during stress tests based on actual end user scenarios of the entire program. Just based on the static understanding of the Code, it intuitively judges what is important to the overall performance, and the conclusion is almost always wrong. Instead, measure the behavior of the entire system, identify the code that really affects performance by 1%, and focus on this.

17. Reduce the backlog of unfinished coding tasks: When a developer starts a use case, the cost will occur, associated with the modified but unfinished code and the test code. Days or weeks with unfinished changes will generate a huge redo risk. Consider that each Estimation requires three tasks a day, start these three tasks at the same time, and carry out at the same time within three days, which means the cumulative cost of nine units. However, each task is executed sequentially, And the next task is completed and then started, which means there are only three units of cost. This is not intuition. Intuition tells us that we may wish to do three things at the same time before the work is completed. But the software is not physically structured. Short, fast, and complete work not only reduces the burden of cognition, but also reduces the possibility of conflicts between unfinished work and unfinished work of others.

18. Do not overemphasize code universality: this is the famous "yagni-you don't need it ". When writing a specific class, programmers always like to think that this class may be used for other purposes. This is good if the current use cases require these purposes, but programmers often consider unmentioned purposes, or those that are never actually needed. (This often reminds me of the classic pop-up on Saturday. A product is not only floor wax, but also a sweet tooth on cakes .)

19. If two lines of code work, do not use three lines: When someone reads the code, the concise code always returns. But do not compress the code into a hard-to-read version. Smaller, well-written code is more lengthy, and it is easier to maintain and discover errors when writing gorgeous code. Always simplify it as much as possible, but never overdo it.

20. Do not use the number of lines to measure the code: the number of lines of code required to complete a specific task varies greatly between programmers and coding styles. The number of lines of code cannot tell you about Code Completion and quality. The code quality can be 200 times different, which is enough to offset the number of lines of code. The number of function cases should be counted.

21. Continuous re-design and refactoring: use this criterion with caution because some code is fragile and difficult to change, but you should not be afraid to change the code to fit your actual needs. A data member may have been an integer in the past, but when a use case requires that it be a floating point number, do not be afraid to change it.

22. delete dead code: if there are a lot of code that is hard to understand, there is a tendency to avoid any trouble. One example is to add a new method to the class to replace the other. Developers often leave the old method just in case. Efforts must be made to check whether the method is required. If there is no evidence that it is required, delete it. The worst thing is to comment out a lot of code and leave it there. The commented out code should be deleted as soon as possible after the test is passed. Of course, the code should be deleted before it is checked in. Therefore, you may find that something is unnecessary at some time, and make little effort to verify and eliminate this code to make the code baseline easier to maintain.

23. Do not invent a new language: programmers love to use the runtime driver feature of text file configuration. No configuration file can change the behavior of the program without compilation. The emergence of XML has pushed the endless wave of specialized scripting languages, so that functions can be customized by end users without compilation. The defect of this reasoning lies in that, leaving a specific implementation environment, the operation behavior is almost never well defined. At the same time, those scripting languages are only useful for those who have a deep understanding of the internal operation of the problematic domain code. Therefore, real end users without detailed internal knowledge will never be able to know what the expected results of complex command combinations are. Script languages are useful and cannot be eliminated. However, designers must adopt a very conservative attitude and try to use existing languages to avoid new inventions.

24. Do not design before you prepare for implementation and testing: You should have a general idea of moving forward and an overview of the system architecture. However, do not design in detail or describe the implementation of functions until the design can be implemented and tested in the Development iteration. The detailed design should only deal with the current use cases. The biggest waste in software development comes from spending time designing things that are not needed or that need to be re-designed due to wrong design assumptions.

25. design is plastic: Unlike physical manufacturing, software can easily achieve significant changes. In fact, there is a lot of evidence that the software itself is easier to change than the design specification that describes the software. In addition, the software communicates the design more effectively than the specification. Therefore, you should use the time to directly implement the design so that the customer can see the design details. If you make mistakes and change the design, it is easier to change the software than to change the specifications. But the most important thing is that after the customer sees the code running, you have a great deal of information about what the customer wants.

26. A complete description of the problem in the code that takes the time to write and report exceptions: programmers are often very lazy and throw an exception that roughly describes the error. I think they will always be the only one who will see the problem, and they will remember the meaning of the problem from a vague description. However, in the customer support environment, inaccurate or incomplete error reports waste more time than other reasons. Write every error message as if you are explaining the situation to someone who just walks into the room and has no experience with this code. After all, the customer and customer support team have no experience in this Code.

There is no specific sequence for these introductions. You are welcome to discuss the principles that I ignore, or (if so) agile development principles that you do not agree.

Original article: 26 hints for Agile Software Development Author: Keith Swenson

From: http://www.it121.com/content/75