As a programmer, it is inevitable that you will take over the new system due to the resignation of your colleagues. If you happen to be a newcomer to the company, what should you consider when you are unfamiliar with the business.
1. Documentation.
While most system documentation is lacking, the following are required.
Application deployment diagram: On which server is the application (or service) deployed, and what are its related servers? For example, the cache notification service, the database server, etc. are respectively deployed on that server. What might be the impact on each other?
Data Dictionary: Always know the meaning of database tables and fields.
System documentation: system launch time, function introduction, operational risk, deployment environment and form, document location, source code location.
Other documents: the more the better, may not read, but it is always good to keep spares.
2. Source code related Is the
source code consistent with the online version? If not, why? Referenced dll source? Are there instructions or source code for this?
When leaving colleagues explain the code, they comment directly into the source code.
Generally speaking, explaining the business process at this time may not be clear, so record it first.
3. Whether the application has logging (mainly exception handling).
A system without logging is a nightmare to maintain.
I have seen a system with a very high complaint rate. There are few logs and only successful information is recorded. The catch block is always return null or return false. If you can know the root cause of the problem, you can avoid this problem, so you can often only know the possible problems at this time, but the specific reasons may not be known, but there is a temporary solution such as restarting a service. There is time to gasp to check the problem)
4. Is there a test environment to test the database server address?
As far as possible, let your resigned colleagues assist you in successfully compiling and deploying the system once.
Know the resource location referenced by the system (for example, you may find that the path of some configuration files referenced by the system can only be in the D:/XXX directory).
Pay attention to whether the test environment is consistent with the formal environment (for example, the test environment is .NET Framework 3.5, and the formal environment is .NET Framework 2.0, and going online will bring unnecessary trouble).
5. If it is a web application, you need to pay attention to the situation of other services and applications on the web server.
A situation that often occurs is that a certain service of a server exhausts the socket port, causing all other services or applications to fail to run normally.
As for other resignation handover orders, they are often in a form, which is skipped here.
1. Documentation.
While most system documentation is lacking, the following are required.
Application deployment diagram: On which server is the application (or service) deployed, and what are its related servers? For example, the cache notification service, the database server, etc. are respectively deployed on that server. What might be the impact on each other?
Data Dictionary: Always know the meaning of database tables and fields.
System documentation: system launch time, function introduction, operational risk, deployment environment and form, document location, source code location.
Other documents: the more the better, may not read, but it is always good to keep spares.
2. Source code related Is the
source code consistent with the online version? If not, why? Referenced dll source? Are there instructions or source code for this?
When leaving colleagues explain the code, they comment directly into the source code.
Generally speaking, explaining the business process at this time may not be clear, so record it first.
3. Whether the application has logging (mainly exception handling).
A system without logging is a nightmare to maintain.
I have seen a system with a very high complaint rate. There are few logs and only successful information is recorded. The catch block is always return null or return false. If you can know the root cause of the problem, you can avoid this problem, so you can often only know the possible problems at this time, but the specific reasons may not be known, but there is a temporary solution such as restarting a service. There is time to gasp to check the problem)
4. Is there a test environment to test the database server address?
As far as possible, let your resigned colleagues assist you in successfully compiling and deploying the system once.
Know the resource location referenced by the system (for example, you may find that the path of some configuration files referenced by the system can only be in the D:/XXX directory).
Pay attention to whether the test environment is consistent with the formal environment (for example, the test environment is .NET Framework 3.5, and the formal environment is .NET Framework 2.0, and going online will bring unnecessary trouble).
5. If it is a web application, you need to pay attention to the situation of other services and applications on the web server.
A situation that often occurs is that a certain service of a server exhausts the socket port, causing all other services or applications to fail to run normally.
As for other resignation handover orders, they are often in a form, which is skipped here.