maintain the little things

       From May 2015 to May 2016, it has been maintained for a whole year. For the maintenance of this little thing, how can not love. From December 2014 to March 2015, just a few months of development experience is not enough to face the vast world of code. If you want to spread your wings, there is no other way except to exercise more to make your wings rich.

      Routine maintenance, for database additions, deletions, and changes, an average of 30 to 40 records are modified from all directions every day. Commonly used SQL statements are placed, ctrl c+ ctrl v every day. This is a position that is useless without you, and impossible without you. Yes, at best it is a personal hand, not even a manpower, let alone a talent.


      Summarize and maintain personal insights for one year. Three steps to maintain:

1. Familiar with the business and the system. It is unavoidable to first look at various documents, look at the system, and go through the various processes in person. Familiar with business processes and systems. How familiar you are, no one will give you a standard, and no one knows where the 60 points are, so you still have to rely on yourself. Regarding the issue of familiarity with the system, I personally think that since the system has been made, the architects who are most familiar with it are the core development personnel. Of course, they generally do not have time to teach you. The development core personnel simply refers to having an overall understanding of the system, knowing the overall framework of the system, as well as the various table structures and function points. Ordinary developers, you don’t need to ask about this. Ordinary developers are children who have worked hard on their own acre and three points after building a framework for the core. They don’t have a complete understanding of the overall framework, but they still rely on solving small problems. spectrum. I have often asked, what is the familiarity system and what is the standard, but no one has answered me, because there is no single standard for this. To give a specific example, to be familiar with the system is to be familiar with what each function point does, which ones can be operated, which ones cannot be operated, and what content each page has. This is the first step. When someone asks you what the system is used for and what is the main function of the system, at least you can answer it.

2. Solve specific problems, be proficient in SQL, and be familiar with the table and table structure of each page field. There are always many strange problems in maintenance. First of all, you must have a pre-judgment in your own hands. Which are the problems of user operation errors, which are the problems of data errors, and which are system problems, which need to be informed to the developers. Modified, learn to distinguish. Don't jump and ask developers to change every time you encounter some problems, they will definitely annoy you. Of course, if you can solve it yourself, don't bother others. The premise is that if you can't, you must ask. I don’t want to ask, this is very important, you can change it at your own discretion, and only after you find out what is wrong, if the system data can’t be recovered, this is a big deal. It's not an easy question. There was also a more confident little brother who changed things by himself and didn't say hello, which caused the system to be paralyzed. After the basket was cleared, it was not the maintenance staff who continued to supply it, and a bunch of people complained. This is not good. This is a question of method. First of all, you have to ask it first, and then you can do it with confidence. Specifically speaking about mastering SQL problems, first of all, lay out the ER diagram to be familiar with the table structure. This requires you to specifically know which table contains which field and which field corresponds to which page. Conversely, if you are familiar with pages, you must know how many tables each page contains, and which table and which field the data on the page exists in. If the code is easier to find, F12 can query the page code, but cannot find the table structure. At present, according to the page, there is no query method that can connect to the corresponding table of the corresponding field, and I can only actively think of a way. The maintenance system is basically a data problem, and the corresponding page data table and data loss can be recovered by directly operating the database, under normal circumstances. When maintenance encounters some system problems, it is necessary to contact the developers to modify the code. For example, the non-standard pop-up box, the operation method that does not conform to the business logic, and the failure to respond after operation, all require code modification. Further, if the maintainer can move the code, it will bring you a lot of convenience.

Third, modify the code. During the maintenance process, the maintainer already knows where the problem will appear and which needs to be improved, and can modify it in person. Based on the familiarity with SQL and the table structure of system data, the sphere of influence can be extended to the code. It may take a while to become familiar with the code, but once you are familiar with the basic system framework, it will be very fast to find problems. There may be problems of making mistakes or not being able to deploy. It doesn't matter, you still have to take this step bravely, so that you can make progress. The maintainer's progression to the general developer, the first step.


It means that it is still in the transition between the second and third steps, and the process is upward, which is very good.


Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325787924&siteId=291194637