Be a professional software craftsman

At the beginning of this month, I participated in Shenjian 、 Wuke 、 Deng Zhiguo's three teachers CSD(Certified Scrum Developer) After the certification course , Deeply infected by three teachers , Yes TDD、 restructure 、CICD A series of XP The engineering practice of has a practical feeling at the same time , It further inspired a belief in my heart ——“ Be a software person with professional ethics . I hope I can become a craftsman ”. One month after class , I have also tried to implement a number of practices in practical work . I'm impressed in class today , And some recent practical feelings to share . I hope it will be helpful to you .

The smallest unit of iteration can be a function

Usually when we mention iteration , Maybe the first thought is 1～4 Weekly Timebox. Yes , This is a cycle of delivering value to the business . But in fact, we are developing a function , Even a function as small as a function can be regarded as an iteration . Iteration is to be deliverable within a certain time frame , And get feedback , So as to promote the adjustment of the next iteration , Repeat until you get the best result . Isn't that the purpose of writing and debugging code ？ combination TDD How it works ： A red light -> A green light -> restructure , Nature is an iterative closed loop .

The purpose of red green switching is to solve the current demand / problem , And restructuring is to reduce technical debt , Deal with future changes .

TDD Classic three-step method ： A red light , A green light , restructure . And their three steps have their own meanings ： red 、 The green step is to solve the needs / Problems exist . Refactoring exists for the future . But only the first two steps have built a safety net , To be able to adjust for the future . This also explains ： Good code / The architecture is written , Not designed in advance . Refactoring itself is a kind of design , More pragmatic design , Avoid excessive design .

When you don't know how to refactor , That is, the step is not small enough

Recently, I just paired up with a little partner to reconstruct a 100 A multiline function . When I asked him what he thought , He looked at me with a confused face . I thought of the teacher's advice in class ： When you don't know how to refactor , That is, the step is not small enough . I said at the time , Let's look for the same ！ Yes , Not looking for a different , Is to find the same .DRY(Don’t Repeat Youself) principle . It turns out that 100 There are three lines of code if Sentence block . So we use the extraction function method , take 3 individual if After the statement is extracted into three methods . My little friend put forward the follow-up reconstruction ideas ： Change to switch-> Change to polymorphic . It seems that ideas are constantly being opened . This last 100 The multi line function body has only 25 Line code . And the result of this reconstruction was unimaginable at the beginning .

Reconstruction small Tip：

• Start with a small step , It doesn't require a single refactoring to solve all the problems .

• Change the code to the same form , See if you can merge similar items .

• Tests must be run after every change . Ensure that all pass .

• repeat 2~3 Step , Until the refactoring is satisfactory .

TDD The three law

• Don't write any functional code before testing

• Just write test code that just happens to reflect a failure

• Only write test code that just passes .

#1  Is the most difficult to change , Once you can accept it and stick to it, you will form a habit .#2,#3 The main thing is to avoid over design , Reduce waste , Just write enough functions code Just fine . Simpler code Easier to modify , It can also be avoided bug. At the same time, it is easier to adapt to future changes .

The steps of reconstructing the legacy system

• Writing tests preserves the behavior of current functionality , Instead of modifying it .

• After the current function test fails due to the new function , Then modify the test logic .

• Only aim at bug Add test start . Don't deliberately write tests for parts that work well , Until necessary .

Adding testing to legacy systems is a very costly activity , But if you don't , The system cannot jump out of the continuous production caused by streaking bug The vicious circle of . And how to take this step and make the flywheel rotate in a positive direction , What will happen ？ The three steps given by the teacher can really promote the engineering practice of unit testing . It avoids the high cost of blindly writing tests , It can also gradually build a safety net according to local conditions . I successfully applied this method to implement unit tests to a legacy system team , And in a month's time increased 100 Multiple tests . And R & D partners also began to actively apply TDD To develop and modify functions .

At the end

Having professional ethics is actually an attitude of being responsible for the code you write , Many researchers around write code It's all about feeling , When you really ask him how to ensure that the code he writes is correct , They can't give specific proof . It can only be said that I just know there is no problem . The most direct case is the recent , When I use TDD For another team SDK When doing behavioral tests . They can still be found bug. And these bug It's actually a piece of code that they have always thought is working properly , But the truth is “ did not ”. So let me feel again ： Use tests to protect your code reliably . At the same time, refactoring makes the code better . Think of yourself as a software craftsman , Creating art , Instead of an ordinary coder , Just forced to move bricks .

Practice agile practices , Make work better . Welcome to leave a message , Exchange landing experience .

【 Welcome to my blog 】