Construction experience and summary of e-commerce integral payment system

This system is a very complete system, which is designed and built by myself throughout the whole process. Several other sets of systems are more or less working with colleagues and so on, and have no such complete experience.

Not a large set of things, but did learn a lot, mainly about database design, design API, code structure design, project promotion, project time and difficulty estimates, test estimates.

The project from the need to the completion of the integration System (including docking existing payment modules, writing tests and so on) is actually time-consuming, probably in 16 days, the reconciliation system including the test did 4 days total working days probably in 20 days. But this seemingly normal time is far from the initial estimated time. I have a lot of overtime in the early days, including the weekend overtime to be able to follow the current progress of the completion, in fact, initially estimated that no reconciliation system to complete the time of the 12-day, the middle difference of 4 working days, the overtime can be counted 7 working days. Perhaps this is not often estimated project time people easily made mistakes, the coding efficiency of their own self-confidence, but there is actually a large number of uncontrolled factors affecting the progress. One of the big impact is to modify the previous person to write the code of the payment module, not only need a lot of time to read the previous people write code and ideas, but also need to add their own logic, which takes time. So be sure to set aside enough time for the time, and then mention it later.

(a) or in order, first say database design, design API, design code structure

It took about two days to design the database, involving 11 tables altogether. After the leader and the supervisor opened a short meeting, I elaborated on my design ideas, and then pulled them to help me see whether the design problems, or there is no place there is a loophole I have no way to consider. Here I actually designed two water tables, each time there is a sum of income or expenditure, will add a record in the expense and income of the water table, but at the beginning, for some reason I might need to update the fields inside the table, But leader told me that the water table is best not to have update operation, this may be more error-prone, the water table only to record, not update, so there will be no problem. This makes me start to think about this problem from the stability of the table, I think there is some truth. Because the water table in the end of the settlement may be used for reconciliation, once the table because the Update field problems, then the reconciliation will be wrong, the e-commerce system reconciliation error ....

Look for seniors to help see because they are more familiar with the system than I do, so be sure to pull them to see for themselves, or some pits, or the previous hack may affect the new system to do some operations. Made some changes, and then we agreed to a decision, that is, if the full line of code in the volume of a large minimum of 2k lines, there may be no way to review. After all, taking the time to see a project with a 2k line of code is going to take some time. So decided to split the project into two pieces on-line. Because the query storage usage of component integral is completely unaffected by the existing system, it can be put on line separately, and then go online as another part of the current payment refund system. This would open up the coupling between the present logic and the new component system, and it would be a little more convenient to see the code.

After the discussion, leader let me have the best day of the afternoon, or the next morning, the set of things to provide the API for the app to set out, probably need some APIs. After the API is fixed, writing can follow the API to implement the function in turn.

This step really inspired me, after the completion of the database design, the design is exactly what to provide, you can complete the preliminary API design. In this way, you can well think of the functions provided in order to write code, it is not easy to miss something. In fact, the most difficult part of this is the idea of a clear, can let themselves know exactly what work is done, what is completed first, what can be done after the better. After designing the API and the database, I might need to draw some diagrams and take notes to help me think about these issues to make my own ideas clearer. My own painting took a few sheets of A4 paper on the above probably drew a note about what API, what the name is probably called, what kind of features, what may be designed to the table, and so on.

Finally this chapter inside about the code structure:

The DAO contains a model of each new table, which is used because of the use of ORM.

The model contains a variety of intermediate logic, including calling the method inside the DAO to create the update delete data, splicing various types of data.

Outside the API provides the functions of the API function, API layer I only processed the entry, to ensure that the type of the arguments are valid and then passed to the model corresponding function for further logical processing.

Const contains a variety of constants that may be used. When the design constants are stored, this time stepping on a hole, it is best to have a few possible types of constant type to create a class, write under the class, and preferably in advance to allocate the number of their own area. For example, we may have a constant demand for different spending and income, and don't write this:

classIncomeconst (object): Income_normal_review= 1#earn points for normal reviewsIncome_review_bonus = 2#bonus points earned at the topIncome_unlock_order = 5#Order Integration UnlockedIncome_refund_order = 7#Refund Rebate PointsclassExpenditureconst (object): Expenditure_fresh_member= 3#love to buyExpenditure_lock_order = 4#Order Point consumption lockExpenditure_offset_cash = 6#Point of arrival

You should first determine that the income occupies 1-1000 of the number so expenditure can occupy 2-2000 of the number so that the same type of const is consistent, like this:

classIncomeconst (object): Income_normal_review= 1000#earn points for normal reviewsIncome_review_bonus = 1001#bonus points earned at the topIncome_unlock_order = 1002#Order Integration UnlockedIncome_refund_order = 1003#Refund Rebate PointsclassExpenditureconst (object): Expenditure_fresh_member= 2001#love to buyExpenditure_lock_order = 2002#Order Point consumption lockExpenditure_offset_cash = 2003#Point of arrival

Don't make yourself like a schizophrenic, and you'll get a number up in Riga. I can't bear to look directly at =.

Exception contains all kinds of errors that may be thrown, and it inherits from the Excepition class.

(ii) Project promotion

The process of project advancement is nothing more than a module written according to the step by step of the design of the front. In fact, the middle also did not encounter anything special pit dad, just the original two on-line steps to split into three, because found in fact, although there is no building the whole set of points to pay for things, but there is a record of user points of things, in the user comments after the product will give users to record points, This causes the front more or less to write some of the points of things, I need to put these original things into a good class re-put back into the integral module of the new design integration. This step in fact, I did not think of the time, because the previous code is more casually, resulting in my migration is very laborious, there is a lot of dependence flying, more time spent, but also the impact of the line of things have to be careful, measured and measured. Summed up an experience, first from the most dependent on the beginning of the demolition, complete a piece of the test piece. Such a step-by-step make almost no mistakes. Do not move several pieces of things in a row, and finally come together to test, then if the problem was measured again, I believe that the difficulty of changing it is very large. It is almost impossible for you to check in turn which one of the previous changes is causing the problem.

The ideal state of migration is that everything has unit tests, and if not, the Run unit test will report an error, and you will be able to detect and cut changes in time. The reality is (it looks cruel), and if you don't have unit tests, you may need to be robust step-by-step. When you move simple things away, you will find that the things that have been difficult to migrate have become easy to move.

(iii) Project schedule estimates, including estimates of the duration of the project in the test section

As mentioned in the first section, in fact, if the time is very ample and easy, you may have plenty of time to test the key parts according to the process I said above, and even bring unit tests to every place. The reality is that if you estimate the project time too short, you may not have time to refine the test. The premise is that there is no full-time QA in your company, the test needs to be done on your own, and it is important to estimate the timing of the test into your project schedule. My test time is about 30% of the time it takes to complete the project, much of it depends on my spare time to complete the project or test, and to rely on some of my previous colleagues to write the payment part of the test, If I had all my own, I'd estimate the time at least. 50% time to complete the project time for testing or writing unit tests. In other words, if you estimate that you can finish the project in 15 days, you may need an additional 7 days to test and fix the bugs, as well as your own code two times review. This progress will ensure that the quality of your code, and after the online without fear will be the client or web-side colleagues trouble.

In terms of time estimates, the experience of not a few projects is definitely inaccurate, and when you find that you can't finish the project before deadline, be sure to explain the project extension to your leader, and for what causes the project to be postponed and to complete the project as soon as possible. Therefore, the project to promote the rhythm of the control, may seriously affect the quality of the project, can not be completely without pressure and time on the deadline at random to complete the project, nor the project time card too tight, because in addition to my analysis above the problem, but also may appear such as you need to leave something, Midway task insertion.

Above.

Construction experience and summary of e-commerce integral payment system