Initial Experience of agile development

Disclaimer: The purpose of this article is only to convey some experiences about agile development, which may be of some reference to those who have just come into contact with agile development. I just attribute it to the "day of thoughtworks" series. You do not have to judge whether the series is eligible to be placed on the homepage Based on the series name (OtherArticleIs not placed on the home page ). Let's stop talking about this. As for whether I want to show off myself and go to thoughtworks, I don't want to speculate on others if I don't have to worry too much. Welcome to technical discussion. For other questions, please proceed. I really think it's incredible to get a comment like "coming out of the box"-Do I feel good to hide it after I go to thoughtworks? I deleted several comments. This is not the first or the last one, I can't bear to squeeze time out to write some articles and share it. I also see this kind of sneer-there is a time to do something more meaningful.

Yesterday (dec. 09) was the first day of employment. In the morning, I was assigned to another colleague to migrate an open-source software from Java to the. NET platform, that is, to C #Code. In the afternoon, I really experienced a Pair programming. one of the most impressive words is: Let's do it now. You can't change it any more. what's more, there is no pressure when talking about this sentence. It is not like a compromise but a calm choice. another thing is that sometimes things may not be as difficult as you think.

We need to do a Code Converter: Convert JUnit code into nunit code. it seems complicated at first glance. however, what we need is not a perfect solution. We can use tools to convert most of the code and then complete the rest manually. we break down the problem: Replace the package statement with namespace, delete the Import Statement (instead of automatically adding using), add the using nunit framework statement, and so on. the architecture is also very simple. The input is list <string> and a converter is used to convert it to the output list <string>. I initially considered using the visitor mode + interpretor mode, because I used this solution to convert a flowchart to an XML file system. however, subsequent development did not prove the necessity of these two models. I didn't propose it, mainly because I didn't want to make things too complicated at the beginning. however, I have proposed whether a global context is required to save the intermediate conversion result. However, this design is more complicated than passing parameters, so we chose the latter.

The TDD development method is used, and the development process is still smooth. Let's just talk about a few controversial points.

1. Processing of cross-line statements
   We designed line-based conversion. however, we know that Java statements can be cross-row. cross-row processing our design framework is not insurmountable, but much more complicated than processing a single row. we finally decided not to deal with cross-row situations first, because this software is just a tool we use internally.
2. Should I use composite mode to organize conversion rules?
   The rules applied to them are called iconverterrule. All specific rules implement this interface. because we finally need to apply all (at least most) conversions to all files. if you implement it as the composite mode, it is a natural choice. however, this will make the design a little more complex, because you need to add some interfaces to maintain leaves. if you only implement iconverterrule for the general rule set, it will not bring any other benefits. finally, I gave up the solution.

Start porting todaySource codePart. we adopt the method of testing and code alternate transplantation: First porting a test, then porting the relevant source code, then porting a test, and then porting the source code. however, there are more than 500 files in the source code, and the workload is quite large, and there are a lot of repetitive work. I thought there was no need for PP in this part. It turns out that even such work PP is also good for efficiency.

In the middle of the day, I chatted with Han Ke. He suggested that we could use a tool to convert the non-unit test part and then manually modify it. Then, he told us a UNIX text processing tool awk. I visited the homepage and did not try it today.

PP may be tired. I am prepared for it, but in practice, I still find it more tired than I think. we have to take a rest every hour or so. and the last section of this afternoon almost failed :(