In the first half of the month, I worked a lot of overtime so that ONE Order could run under the new framework. Then, IN the second half of the month, I continued to improve Design.

We all know the old One, the order, the header and item of the administration information are saved CRMD_ORDERADM_H and CRMD_ORDERADM_I, then other order node, each node has 1 table, the table has a total of 1368 pieces, Every time you save, different data goes into different tables.

Now, under the new design, all the 1368 tables will be removed, and all the data will be replaced with the new Header and item. How to get? Carsten communicated with me at remote before I came, saying that he had some draft ideas, but he was not sure whether they could really work. He needed me to turn these ideas into codes that could be run. After running, we could see step by step. Carsten’s draft idea was very rough without implementation details, so I had room to give full play to it.

After the first phase of my framework was put together, I thought the implementation was pretty neat, the code wasn’t too much (2000 + lines), and it worked, and I flattered myself.

In the second stage, we had sync meeting for half an hour every morning and AD Hoc meeting in the afternoon. The agenda of the morning sync meeting: divide the POC code I wrote into several pieces and review one piece every day

1. Review the rework result of yesterday’s piece
2. Review the one we should see today

In other words, for half an hour, the three of us sat together and improved design by looking at my POC code. I was supposed to type the code up on the screen and explain what it did line by line, but it didn’t need to be, and Carsten looked at the code very quickly and reacted very quickly (or maybe my code was really readable). I don’t have any problem with the code quality. I think I am first-class, but Carsten can find out the places that need rework every day, which are related to design. For example, the check should be placed in Method B instead of method A. Some logic should not be placed in class A but in class B. Therefore, my daily routine in the second stage was as follows: review in the morning, rework in the afternoon and bug correction. When FIXING a bug, I would add some code, which would become the input of the next day’s review, and the cycle would start again.

Carsten works on the same topic to learn why he disagrees with my design/code. For example, if Carsten trains me for one order, I don’t think it will be of any help to me. On the first day I arrived, Oliver asked me if I needed him to tell me about one order session. I said no, no, no, let’s just start. I reviewed with Carsten every day and he would find out the faults, and his fault finding criteria and evaluation criteria were worth learning. For some faults, he would say, “If you do this now, there is no problem with POC, and we will improve in productive production in the future.” Some faults he said, you can’t, must change. I wonder, in hindsight, what he was basing his judgments on.

Wuji told me that he wanted to learn programming at first, but he didn’t have any basic knowledge and didn’t know how to get started. Therefore, he spent 1400/ month to find a computer teacher in Sichuan University and asked him to teach Wuji some basic knowledge of computer three days a week. Therefore, I now regard what I do every day as a training similar to the training of Jade Bird in Peking University. In this training, T5 Chief Architecture is my teacher every day, who can sit with me and do a specific project together, including project design on paper and homework on the computer. And the teacher will carefully correct my homework, which is a rare opportunity. The more I do, the more opportunities there will be for teachers to help me grade, and the more I can learn. That’s why I don’t go anywhere every weekend.

The first picture is the implementation of Order Save, which I have changed countless versions, and I think it is quite good. However, in the Carsten review today, I still give some suggestions for modification. The reason is the seemingly simple single responsibility. This principle is easier said than done.

Comparing the two pictures, it seems that my design code is less and simpler. Carsten’s is more complicated. But this is just an appearance, in fact my vision is to inject what the buffer Merge framework needs to do into the convert class of each node of the One Order model, the method called convert_1o_to_S4. The One Order model, for example, has 200 nodes, and the merge process is repeated 200 times. Carsten’s argument is simple: If a single responsibility convert class should not be done, it should not be perceived, and it should not be touched. Today, I just refacted the whole framework according to Carsten’s proposal, and the result is indeed that the improved framework has less code. This is because all of the convert class duplicate buffer merge actions are extracted out of the same class as the brown method shown in the figure in chapter 2.

I had thought about Carsten’s proposal at first, but I think if it is placed outside, this method should be able to handle the Order node data in any format, and detect any mode of Creation, Deletion and Update. I think the programming complexity is too high to give effort Estimation. If you put it inside the convert class, then the convert class knows what structure it is, so the structure can be written inside the convert. This is much easier to merge. Therefore, I made POC according to the simple implementation, but I was finally defeated by Carsten Callenge. This refact leads me to conclude that implementation complexity should not be a determining factor in design (as a reference) if you are doing framework development.

For more of Jerry’s original articles, please follow the public account “Wang Zixi “: