1. Preface 1. Agile Developments is a quick development of rapid development software in a rapidly changing demand.
2. Chapter 1 Agile Practice P2 1. Constantly adding more constraints and artificial articles result in a large and cumbersome process. The big and cumbersome process is huge, heavy-duty process methods.
2. Agile Software Development Declaration: 1. Individuals and Interactions overhead Processes and Tools 2. The software that can work is better than the face-oriented document 3. Customer cooperation is better than contract negotiations 4. Respond to the plan
3. Individuals and interactions winning processes and tools. People are the most important factors that have successful success. The bad process will make the best team members lose utility.
2. Cooperation, communication, and interaction ability are more important than simple programming capabilities. So a good team member may be a average programmer, but it can work well with others.
3. Suitable tools are very important for success. But it is not good like a huge, cumbersome tools like missing tools.
4. The team's construction is much more important than the environment. First of all, we should be committed to building a team, and then build an environment based on what needs to be enabled.
4. The software that can work is better than the documentation 1. The team needs to prepare the easy-to-read documents to describe the basis of the system and its design decisions.
2. Excessive documents are even worse than too little documents. Dreams of documentation and code synchronization.
3. The document should be short and the subject is protruding. Shortness means up to 120 pages. The topic is highlighting to discuss the high-level structure of the system and the design principles of the summary.
4. Martin document The first law: until it is urgently needed and significant, the document is written.
5. Customer cooperation is better than contract negotiations 1. Successful projects need to be orderly, frequent customer feedback. Not relying on contracts or statements about work, but to make software customers and development teams work closely together and provide feedback often as much as possible.
2. A bad contract has a fundamental defect that indicates the contract of demand, progress, and project cost.
3. Good contracts provide guidance for the development team and customers in the same way is the best contract.
4. The function module and acceptance details should not be specified in the contract.
6. Responding to changes in the plan 1. When building a plan, you should ensure that the plan is flexible and easy to adapt to business and technical changes.
2. Good to do planning strategies are: Do a detailed plan for the next two weeks, do a rough plan for the next three months, and then do an extremely rough plan.
3. It takes time to take a detailed plan for an urgent task. The rest of this plan remains flexible.
7. The 12 principles followed by the agile Declaration: 1. We must do the best to make our customers with your best, continuous (frequently) deliverable software. 1. Two relevances have strong correlation between systems and system quality of partial functions as early as possible. The less features included in the initial delivery system, the higher the quality of the ultimately delivered system.
It is often related to the highly increasing function, and has strong correlation between the system and system quality. The more frequently delivered, the higher the quality of the final delivery system.
2. Even later, it is also welcome to change demand. Agile process uses changes to create competitive advantages for customers. 1. Demand changes means that the team has learned a lot of knowledge that meets the needs of the market.
3. Software that is often delivered, the interval delivered can be delivered, the shorter the time interval delivered, the shorter the time interval delivered. 1. The goal of interest is to deliver software that meets customers, rather than a large number of documents or plans. 4. During the development of the entire project, business people and developers must work together every day. 1. Through customer, developers, and more frequent interactions, the software projects continue to be continuously guided.
5. Build projects around individuals who are embraced. Give them the required environment and support, and trust them to complete the work. 1. People are the main factors for the success of the project. Processes, environment, management, etc. are secondary factors. When a secondary factor has a negative impact on people, the secondary factors will be changed.
6. The way in the team is most effectively and efficiently, is the face-to-face conversation. 1. The conversation is the default communication method.
7. The software working is the primary schedule metric. 1. Not based on the development phase of the development phase, the number of documents that have been written or the amount of infrastructure code that has been created is measured.
8. Agile process advocates sustainable development speed. Responsible persons, developers and users should be able to maintain a long-term, constant development speed. 1. The agile project is not 50 meters running, but the marathon runs.
2. Travel in fast but sustainable speed.
9. Constantly paying attention to excellent skills and good designs will enhance agility. 1. High product quality is the key to high development speed.
2. High quality is as simple as possible, robust.
10. Simple - Maximize the unfinished work - it is fundamentally. 1. The easiest way to adopt and goals.
2. Do not value the forecast of problems that will appear tomorrow, and will not defense those issues today.
3. Convinced if there is a problem tomorrow, it will be easy to process.
11. The best architecture, demand and design from the self-organizing team. 1. Members of the agile team work together to solve all the problems in the project.
12. Every time you have time, the team will reflect more effectively, and then adjust your behavior accordingly. 1. Anti-provincial aspects include: team organization, rules, relationships, etc.
8. The agile process is: 1. Scrum
2. Crystal
3. Feature Driven Developments (FDD)
4. Adaptive Software Development (ADP)
5. Extreme Programming (XP)
3. Chapter 2 Extreme Programming Overview P9 1. Extreme Programming, referred to as XP) Extreme programming is a simple, specific practice, which combines these practices to form an agile development process.
2. Customer as a team member XP team refers to a person or group that defines the characteristics of the product and arranges these characteristic priorities. If you are determined that you can't work with your customers, you should look for people who can work together, willing and can replace the real customers.
3. User Stories 1. User material is a mutant on demand conversation.
2. User material is a planning tool, and customers can use it and schedule time to implement this demand based on its priority and estimation cost. 3. The specific details of the demand are also captured at the truth, and it is likely to cause useless work and the concerns of immature demand.
4. Short delivery cycle 1. The XP project delivers a software that can work every two weeks.
2. Every two weeks (Items, can also be called repetitive cycles or cycle cycles) have realized some needs of people.
3. Iterative Plan 1. Iterative Plan is some user material selected by the customer based on the budget determined by the developer.
2. Developers set budgets for this iteration through metrics in the previous iteration.
3. Once the iteration begins, the customer will no longer modify the definition and priority of the user material in the iteration.
4. Publish Plan 1. A release plan plan to plan about 6 iterations.
2. One time I usually take three months.
3. The developer is based on the workload completed in previous releases in the previous release.
4. Don't make the content of all 6 iterations in the early days, just develop the original content of the original iteration in the release.
5. The flexibility release plan is not always constant, and customers can change the content of the plan at any time.
5. Acceptance Test 1. You can capture details about the user's material in the form of an acceptance test (Acceptance Tests) specified.
2. The acceptance test of the user material is to be written while the user material is to be implemented.
3. Acceptance Test Use some scripting language that allows them to automatically and repeatedly, and these tests are running with the behavior specified by the user.
6. Ending program 1. All product code is done by the same computer using the same computer.
2. The relationship of the pair changes at least once a day so that each programmer can work in two different ends in one day.
3. During an iteration, each team member should work with all other team members, and they should participate in each of the works involved in this iteration.
4. The benefits of programming: greatly promote the spread of expertise in the team.
7. Test-driven development methods: 1. Writing all product codes is to make the failure unit tests can pass.
2. First, write a unit test, because the function it wants to test does not exist, so unit testing will fail. Then write the product code to pass the unit test.
3. Finally, you can get a very complete test case.
4. A benefit of testing drive: Unpacking the coupling between each module.
8. Collective ownership No programmer is responsible for any particular module or technology.
9. Continuous Integration 1. The XP team uses non-blocking source code version control tools.
2. Check IN To ensure that all tests (unit tests and acceptance tests) can pass.
10. Sustainable development speed 1. Software project is not full speed, it is a marathon.
2. The team must maintain a stable and moderate speed.
11. Open work space is full of active discussions, the productivity is not reduced, but it will be improved.
12. Planning Game 1. The essence of the planning game is divided into business personnel and developers. The responsibility of the business (ie, customer) is the importance of determining product characteristics. Developers decided time to achieve a product feature. 2. Customers choose the rules of user material: At each release and each iteration, developers provide a budget based on the workload they have completed in the last iteration or recently released. Customers choose those user materials that do not exceed the budget.
13. Simple design 1. XP team makes their design as simple as possible, expressiveness (Expressive)
2. The XP team only focuses on the user material to be completed in this iteration, and will not consider those future user materials.
3. Three XP Guiding Principles (Mantras) 1. Consider the easiest thing to work. The XP team always looks as much as possible to achieve the easiest design of the current user material.
2. You will not need it. Time to introduce infrastructure (such as database, ORB, etc.): Only there is evidence, or at least very obvious signs indicate that the XP team will introduce these infrastructure when introducing these infrastructure is now more comparable than continuing to wait.
3. One time, and only once. Extreme programming people cannot tolerate duplicate code. No matter where you find the duplicate code, you must eliminate them.
Eliminating the best way to repeat is abstraction. Abstract and further reducing the coupling between the code, this is a root cycle.
14. Reconstruction 1. Definition: Reconstruction is to make a series of small modifications to improve system structure without changing code behavior.
2. Role: Code tends to corrupt, and the role of reconstruction is to reverse this corruption.
3. Reconstructing is continuous, and everything is going to do every hour or half an hour.
15. Metaphor 1. Metaphor is a metaphor for the entire system
2. Metaphor is a global view that links the entire system together, which is the future sight of the system. Metaphors make the position and appearance of all individual modules to be significantly intuitive. If the appearance of the module does not match the metaphor of the entire system, then the module is wrong.
3. Metaphor usually can be attributed to a name system. These names provide a vocabulary for a system constituent elements and help define their relationships between them.
4. Metaphor for a system that analyzes network traffic into toaster. The data block is called "bread slice" analysis program is called "baking bread sliced" entire system is called "toaster" data block in the data block is called "breadcrumbs"
4. Chapter 3 Plan P17 1. Initial Exploration 1. When the project starts, developers and customers will try to determine all of the real-user material materials, but does not determine all user material. With the progress of the project, customers will continue to write new user materials. The writing of materials will continue until the project is completed.
2. Inquiry, decomposition and speed 1. Any excessive user material should be broken down into a small part. Any user material should be combined with other small materials. 2. After segmentation or combining a user material, it should be estimated. It is unwise to simply add or subtract the estimated value.
3. Decompose or consolidation of a user material, in order to make it sized to be accurately estimated.
4. Velocity factor multiplies the estimation point of the user material to the actual development time of the user's material.
5. The development speed of the calculation team takes a few days to prototyize one to two subscribers to understand the speed of the team. Such a prototyping process is called an exploration
2. Publishing Plan When the development speed becomes more accurate, the release plan can be adjusted again.
Select the user material completed in the publish plan, belongs to the category of business decisions.
3. Iterative Plan 1. The order of implementation of user material during iteration is a technical decision scope.
2. Once the iteration begins, the customer can no longer change the user material that needs to be implemented during the iteration period.
3. Even if all user materials are not completed, iterations will also end in pre-specified dates.
4. Operation after iteration: Total all completed user material estimates and then calculates the development speed of this iteration.
5. For each iteration, the development speed used is the development speed measured in the previous iteration.
4. Task Program 1. When the new iteration begins, developers and customers jointly develop their plans. Specific method: Developers decompose user material into development tasks, one task is a functionality that developers can achieve within 4 to 16 hours (half days ~ two days). Developers analyze these user materials with the help of customers and all tasks are fully listed.
2. Iterative Middle Point 1. When it is an iterative, half of the user materials arranged in this iteration should be completed. If not, the team should try to reassign the unfinished task and responsibilities to ensure that all user materials can be completed at the end of the iteration.
2. The goal is to complete the user material, not just a task.
3. In the iterative midpoint, I hope to see a complete subscriber material with half of the number of items.
5. Iterate the work after each iteration: 1. Demonstrate the customer presentable program.
2. Require customers to evaluate the appearance, sensory and performance of the project procedure.
3. Customers provide feedback in a new user material.
5. Chapter 4 Test P21 1. Writing unit test is a verification behavior, which is also a design behavior, a behavior of writing documents.
2. Write a product code is to pass the test.
3. Effects of test-driven development methods: 1. Each function in the program has a corresponding test to verify the correctness of his operation.
2. The developers can use different observation points. From the advantageous perspective of the programmaker to observe the program to be written. This will directly pay attention to the interface interface while paying attention to the functionality of the program. It is possible to design software that is easy to call.
3. Forcing developers designed to be tested. In order to become easy to call and test, the program must decouple with its peripheral environment. Pre-writing test code before writing product code, often exposes the area that should be decoupled in the program. The more product procedures are tested, the weaker the coupling relationship is.
4. Test can be used as an invaluable document. Test is like a set of examples, which help other programmers know how to use code. The unit test is compilant and can run documentation on the internal structure of the system. It always maintains up to date, will not be synchronized with the product program. The programmer can easily read unit tests. 4. Interesting programming (inteentional programming) I can use the product program as long as the structure implied in the test can be tested.
5. Mock Object (Imitation Object) mode Insert the interface between the class and all collaborators, create test piles that implement these interfaces (TEST STUB)
6. The function of the unit test: unit testing to verify that the small constituent unit of the system should work according to the desired manner. The unit test is a white-box tests for verifying individual mechanisms in the system.
Unit test does not verify the correctness of the system as a whole.
7. The function of the acceptance test: Acceptance test is a black box test for verifying the system to meet customer needs (Black-Box Tests).
The acceptance test is a document related to systematic characteristics. Customers can easily read the acceptance test.
In order to make the system tonel, it is necessary to facilitate the decoupling of the system at a high system architecture layer.
8. Writing Acceptance Tests typically use scripting languages that are created for applications to write an acceptance test.
Acceptance tests should be easily written and easy to change, so use simple text files to write. The CSV file is a nice choice for writing acceptance tests.
9. Acceptance test is the final document on a feature.
6. Chapter 5 Reconstructing P28 1. The purpose of reconstruction is to enable each software module to have the following three responsibilities. 1. The first responsibility is the function that is completed every software module runs.
2. The second responsibility is that each software module should respond.
3. The third responsibility is that each software module is to communicate with people who read it.
2. Principles and patterns can help developers create more flexible and adaptive software modules. But to make the software module easy to read and modify, not only the principles and patterns, but also need discipline constraints and developers to create a passion.
3. An example of a prime number generating program, demonstrating a simple reconstruction P29
4. Intellij IDEA A Java IDE, built-in refactoring browser official website http://www.jetbrains.com/idea/
Intellij IDEA V4.5.1 Registration Code Name: Crsky Code: 12919-DD8VQ-UVPQ0-10TMG-F5VNN-B2OA7
5. General method name is a verb phrase, class name is a noun phrase.
6. After multiple subtle reconstruction, you must read all over the product code. Because the reconstruction is the code snippet, it is finally read again to see if these pieces are integral with readability.
7. Reconstruction and unit testing is inseparable. After each small crushing, it is necessary to ensure that the product code can pass the unit test.
8. It is very small for the time of reconstruction and subsequent efforts to save yourself with others.
9. An example of an example P38 with reconstructed metaphor is cleaned with reconstruction to keep the code clean.
7. Chapter 6 Programming Practice P39 1. A agile practice process of developing bowling competition score programs.
2. From simple consideration, join class frame is not necessary, as long as an integer array can achieve the desired functionality.
3. Let the program follow the principle of principles, you can give it to the reconstructed done later. Not need to make the program follow the principles in the initial design phase. 4. First make the program easier to read. Continue to add more features to the program.
5. Not only the product code needs to be reconstructed, the test code also needs to be reconstructed.
6. If the code uses a local variable, it cannot be extracted, unless these local variables become a member variable.
7. Through reconstruction, try to make the structure of the product code more like readily read.
8. When isn't need to illustrate the code that is created without verifying their code, it is intended to follow them.
Painting a pair of pictures to explore an idea is right. However, after painting a pair, it should not be assumed to be the best design of the relevant task.
The best design is first prepared, then gradually formed when a small step is taken.
