Create standardized code to implement agile development in VS

Standardization program Development is one of the core contents in agile development. Standardized code is not only conducive to teamwork between the team, but also conducive to the integration between modules, save time and cost. A lot of effort has been made to create standardized code in VS. In this article I share with you the considerations of creating standardized code in the VS platform. Specifically, the five bans and four major recommendations.

Ban one: Do not randomly check the code.

This may differ from the user's normal understanding. Some developers may think that checking code is necessary during the development process. But in the Agile development model, this is precisely forbidden. Because if you are writing in code, checking the code every now and then will waste a lot of time and effort on the developer. Of course, this is not to say that users do not have to check the work of the Code, but that the code should be checked to have a specific model.

Specifically, in the preparation of code, should be prepared in advance. If you need to create a threat model, and then under the guidance of the model to complete the relevant code checking work. Where necessary, the project team needs to determine the priority of the code that accepts the most stringent security checks, and the order in which the problem is resolved. In VS, you can help the project team build a threat model and guide the developers in their follow-up work.

Ban II: No user input is validated.

The standardization of Code also includes validation of user input. As a date field, the user is allowed to enter a date in a specific range. However, the user may have entered a non date type of data or entered a date that has exceeded a specific range due to some kind of misoperation, and the application accepted the unreasonable value and followed up the operation because the developer did not take any validation action in the user interface. Wait until the result of the operation or no subsequent operation to find the user's input problem, to the user prompted error messages. It's late now. Not only wastes the user's time, but also produces the unnecessary rubbish data in the system. More seriously, the system operation may be dead loop because the user has entered the wrong data. Eventually, the application becomes machine because of the exhaustion of system resources.

This is a clear violation of code standardization practices. This situation should be avoided during the development of the actual application program.

Ban III: Use assertions to check external revenue.

Note that this feature is not yet perfect in vs. Nor has Microsoft compiled it into a formal version. So developers cannot use assertions to validate external input. In other ways, it is necessary to carefully validate the exported functions and methods, as well as related parameters and results, and to verify the validity of all user input and all file and socket data. This check looks more troublesome, in fact, as long as the 1th, that is, in the beginning to establish a suitable threat model, then the work of the test will become very simple.

Ban four: Hard coded user ID and password pair.

The existence of a hard-coded user ID and password pair seriously violates the requirements of standardized code and Agile Development. If you use the VS system-provided Code analysis tool, the tool detects the existence of hard-coded user IDs and passwords and warns developers not to do so.

Hard coded user ID and password, simply to create a username and password directly in the application code. This is forbidden. In the process of development, to have a better interaction with the user. This includes allowing users to create users and set passwords according to their needs. Technically, you can use an encrypted text file or database to store the user's username and password. When the user logs on, it is decrypted and matched.