Agile practices in my eyes

Recently, several articles on TDD and thoughtworks have been written in coolshell.cn, and the students of Todd Wei in the garden also wrote an article on whether TDD is beautiful or not. I didn't want to talk about it, but I still want to talk about it.

Statement:I don't want to talk about thoughtworks in this article. It's a bit difficult to say anything bad about her. She's my East house. If you want to say something nice to me, you may not believe it. I just want to say that if you want to know about thoughtworks, you can contact other thoughtworks people. Yes, I am talking about more contacts. For example, if you don't want to see me as a cainiao, You can say thughtworks. The thoughtworks Beijing office is a venue sponsor of the openparty. You can take a look at it and send me a private email. Therefore, what I want to declare is that this article has nothing to do with my company. It only represents my own point of view, and I hope that no words will appear in the comments. I will delete it all.

Now, let's go to the topic of this article.

First, take a look at agile practices in the title of this article. Why do we say "practice" instead of "methodology" and "model? My opinion is that practice can be implemented in a real sense. Many people say that software development is an art. However, the art is nothing, so it is difficult to develop good software and cultivate our art cells. Therefore, we need some practical practices. These practices are very good, there are no ambiguous things, there is nothing to learn about, and there is nothing to say.

For example, in an article I wrote recently, "Maybe you need more practical practices", object-oriented is a very abstract thing, so many books teach us how to think in an object-oriented way with examples of all kinds of kitten and puppy. These examples are all well spoken during reading, however, all of our actual projects have been completed. Therefore, we need some seemingly dead practices: we define the number of rows of classes and methods, and do not require repeated code or multiple "." operators for a line. These can be called practices because they are very easy to operate and can be seen at a glance.

Someone may say that software development is an art. What is the difference between this and the construction team. Well, yes, it may be a bit earthy. But I suddenly remembered that some similar practices were not introduced when the teacher taught us how to draw pictures. For example, when I painted portraits, I didn't have a trigger or a trigger (for example ). Painting is an art, but it still uses seemingly rigid methods. Why can't we use software development.

What I want to say is that agile practices are like this three-stop-and-five-eye, and they are well implemented. Test-driven development is an extremely important part of these practices:

1. Programmers are technical personnel who are often addicted to technical details and cannot extricate themselves. They forget the Business Value of the software they want to develop. Sometimes they even come up with many functions that they think are useful to users, but in fact, after being delivered to the customer, the customer finds that the added things are useless. Test-driven development uses a somewhat extreme method to stipulate that, after the test is passed, you should not write any code unless you add a failed test, otherwise, I refuse to add new code. This prevents us from excessively pursuing technology and forgetting the business value.

I remember a long time ago, my manager often told me that you are too concerned about technical details and forget something very important. I did not agree at that time, but I felt ashamed every time I thought about it. For example, I often modify the code to construct a very good class structure, and sometimes I even cut some software functions to achieve this goal.

2. design is very difficult. We have been emphasizing the need for high cohesion and low coupling. So how can we construct high cohesion and low coupling? Of course, it cannot be done by shouting slogans. If you use test-driven product code from the beginning, it is much easier to create highly cohesive and Low-coupling code.

For example, I added a new feature to a legacy code last week. The specific requirement is like this: display the signature based on the current user and the accessed content and the policies set by other administrators. Because the results can be seen only after the code is packaged and deployed, and the legacy code is very large, after the redeployment, it will take about five minutes for Tomcat to respond (I miss IIS every time ). Therefore, manual testing is obviously unreasonable, and it takes so long to package and deploy each time. We have also modified the legacy code, so we must perform regression testing. No way. We need to add an integration test, which removes the need for packaging and deployment. It took us about one morning to write this part of the integration test, but there was always an exception. Finally, I found that the exception occurred in a class named userrightbro. It has a currentuser method, which you may have come up with. This currentuser is of course a thing in the web context, how can we get this in this integration test. The best way to solve this problem is to write a class derived from userrightbro, overwrite the currentuser method with our implementation, and replace the original class with this subclass during testing. Finally, we are desperate. The userrightbro class is instantiated in the class that calls it, rather than passed in through the interface. These two classes are tightly coupled.

Maybe you should say that the person who writes this place is a dumb and gets such tightly coupled things. But how do you ensure that we will not write such highly coupled classes? Do you dare to make a ticket? Of course not. But I think if this part of the code is driven by a test (this part is a legacy code, and there is no test), I think it should prevent this problem. Because some basic structures will be prepared when you write a test. When preparing, you will be wondering how to use this class and what things are needed, such a strong environment dependency implementation is basically impossible.

3. Should we write a test? If the product we develop is not released or used once, or released to internal users (they generally can tolerate you), you can skip the test. What? You said you have a large manual testing team? Okay, I recognize it. If we don't have a large manual testing team, we 'd better write more tests that can be automated, But I have mentioned three. How many developers are coming back for testing after coding? Raise your hand to do this. From what I know, I don't think much about it. How can we implement the test to the testing? I think writing a test before writing the product code may be a good method.

There are still a lot of ideas about how TDD can put some difficult things into practice, but I want to declare that I am not singing a song for TDD. Some agile practices have embodied very abstract problems, some difficult problems, and simplified some seemingly advanced skills. Therefore, some problems are inevitable, therefore, there are still many obstacles in practice.

As Todd Wei described in his article, when the demand changes, our tests will be a blockbuster and even discard many tests. Actually, what I want to answer is:

1. Even if we do not test driver development, should we write tests? In this case, if the demand changes, do we choose not to change the test? But finally, Todd said, we need to quickly build a workable software, let the user see it, and then wait for the demand to stabilize and then write the test. Well, if this one really works, I think you don't need these agile practices, because you have applied agility to the extreme: frequent communication and feedback. Frequent communication and feedback can effectively suppress other risks.

2. Why cannot we use tests to reflect changes in requirements? If the user changes the requirement, we should first change our test and then modify our function code.

3. What I want to talk about most is that the demand changes frequently for the entire software system. When a specific class is implemented, the requirements will not change frequently or even. This is a matter of granularity.

4. Do not simply come up with TDD for discussion. Many agile practices are linked together. When we get a software requirement, we will determine which features will be developed first based on the user's priority. Then we divide these functions into smaller user stories. These user stories have a very small granularity and will not even change in the visible future, there are also acceptance conditions in the user story, which are very specific. Of course, the list of these features, the division of user stories, and acceptance criteria are all divided by business analysts and customers, not by our developers. Therefore, in test-driven development, we are not talking about customer requirements through testing. Because the granularity of user stories is very small, we will describe it very specifically, as long as you carefully read this part of user stories, I think you are doing a good job.

In todd's article, he frequently mentioned that we should construct workable software as soon as possible, then provide it to users, and then wait for feedback from users.

I agree with both hands. No problem. We just need to give feedback frequently. However, feedback comes at a cost. There are many feedback loops in software development, such as developers to developers, developers to QA, developers to business personnel, and developers to customers. Generally speaking, the inner ring has the lowest cost, and the automated test is such a feedback loop. Let's write a test, write the functional code, and test fails. Then we write the code to make the test pass. We work in such a cyclical small feedback loop, and then spread to a more external feedback loop.

Then let's describe our actual work and how to solve the problem:

The previous user stories will not be mentioned. We will create a mini showcase every time we complete a user story. At this time, we will invite business analysts, QA and other project team members interested in this story to participate, this show is very short. You only need to demonstrate it on the development machine, and then the business analysts and QA staff will raise some concerns about them, if this show passes, QA will move the story from under development to the test phase. We have an iteration cycle of two weeks. Two weeks later, QA and business analysts will collect user stories that have been tested in this iteration cycle, present them in front of customers, and then collect customer feedback. This iteration cycle is also very important. If you have a very cooperative customer, and your software belongs to the type that requires frequent changes, you can greatly shorten the iteration cycle, such as one week. However, the response from the outer ring requires a higher cost. Therefore, this is a trade-off problem. We need to try it before we can determine.

Feedback is emphasized in agility, but frequent feedback is costly. First, the customer may not necessarily work with you, even if they work with you frequently to present immature software to the customer, it is not very good. However, if you do not show it to the customer for a long time, it is very likely that you will deviate from the expected track. Therefore, we need a feedback cycle and a feedback loop with an increasing price.

This article is a bit messy. In fact, I still have a lot to say. If you are interested, you can go to coolshell.cn to check whether TDD is beautiful or not? The following are the comments of jnj and Chen Hao. The content is wonderful.

Postscript

One of the main taboos in test-driven development is to think too much when writing a test or passing a test. As Chen Hao said, wow is a very large software system with XXX, and XXX. Yes, I admit it. It's very huge. But how can a huge system not write a line of code? Why should I consider the task system when writing the monster mobile code? We can't eat a fat man at a time. You should do TDD well when you are doing TDD. Other things have other aspects to consider. Okay, I'm not testing the driver, so I am not writing a test? If you think it is necessary to write a test, all TDD problems will occur and will be more intense. Therefore, the test drive may reduce some of our pain points.

Of course, if you have reached a certain level of skill, you will also be very familiar with the software requirements and overall architecture. Some agile practices make you feel too extreme. It just means that you have surpassed these practices. You have considered these practices as a habit and you can discard them. For example, here is a good example of two articles written by Lao Zhao:

My TDD practices: testability-driven development (I) My TDD practices: testability-driven development (II)

Although the two articles of Lao Zhao did not use the traditional test first TDD, he stressed "testability ". Although "testability" seems simple, it is very difficult to achieve this goal just like non-functional quality of other software such as scalability and reliability. However, if you see the same situation as Lao Zhao, the requirement design will be clearly visible, and you can still construct loosely coupled programs, then you can discard TDD. But you have to ask yourself whether you will make up the unit test as Old Zhao.

In short, it is good or bad to try it yourself. Go to the Internet and find relevant articles and examples. First, let's take a look at the exercises and then experiment in your project, if it still doesn't work, find out why. If you finally find that this is not suitable for me, discard it.

From: http://www.cnblogs.com/yuyijq/archive/2011/02/27/agile_practice_in_my_mind.html