Declaration of completion (a manifesto of done)

Alixx skevington posted a declaration of completion, opening a discussion on the following topics-the quality and clear description of the work by team membersCodeObligations of the delivered commercial value.

 

The following completion criteria are listed:

 

• I'm sure my code is available. My code is used and communicated by others. My code should make this process fun, reducing rather than increasing the workload.

 

• The Team accepts the code style I wrote. Besides me, others can also maintain and improve my code. When I have the freedom to design problem solutions using any technology, I still follow this rule and write code that can be maintained by others.

 

• I agree to maintain a reasonable length of the method. It is difficult to read and debug long methods. I will try to shorten the length of the method to reduce complexity. I will comment out all the code. Whether writing new code or modifying existing code, I will use concise comments to explain what I have done. In this way, other people can understand what I have done and what problems the code has to solve.

 

• I am in favor of unit testing for my code. I agree to write reusable and error-free test cases. I should make the test case explain what and why it is being tested. In this way, when other people refactor and modify bugs, they can not only run my test cases, but also understand what the code is doing.

 

• I agree to maintain test cases for existing code. When I modify or add a function on the existing code, I will ensure that both the original and new test cases pass.

 

• I agree to make my code coverage reach at least 80%. Through code coverage check, I can confirm that all the code I write is valuable. There are no potential problems in my code. I will try to make code coverage higher.

 

• I agree to check whether the code is correctly integrated. After I write the code, I will work with other developers to confirm that my code can work with their code to implement the expected functions.

 

ArticlePosted on LinkedIn attracted replies from many netizens. We recommend that you add more entries, for example:

 

I want to add one: "I will re-run all the unit tests before checking in the code ". The reason is that the Code may cause problems in other places after modification. This happened several times in my previous job. (David Kramer)

 

Reply: this is related to unit test: In fact, I want to change this sentence to "I will write unit test before writing code", because I am a loyal believer in test-driven development. Another test-related item is that they are also production code and should be treated with the same standards. (Scott Ames)

 

Scott McPhee does not agree with the code comment entry:

I have to say that I totally disagree with the comments about the code. Comments often lie, or repeat the obvious things (such as:/* let y be equal to x */x = y;), always let us carry additional burdens, to maintain anything other than code. Clear design and coding do not require "concise comments to explain what I have done"-this is what the Code itself can describe, the comments and versions when you check in the configuration management server are sufficient to explain "why ". If the Code does not reflect this, refactor it until the above requirements are met. The API documentation is another difficulty, but it is usually notSource codeIs a part of the officially released product provided by users using the public method.

 

Jay packlick puts forward the key points he thinks:

The most important piece of the definition of "done" should be clearly pointed out. I put it in the first item of the list: "All validation criteria defining the 'finished function' should be reflected in the form of a test and be able to pass the test ".