During the university, I wrote xx management system and XX small program. At that time, I was very free. Anyway, I didn’t really need to use it. Talk about the differences between student projects and work projects, and reminisce about my recent school days.
PS: The article is also roughly about some personal think to pay attention to the point, may not be correct, may be correct. Just be sure to bring your thoughts with you.
Characteristics of the contrast
Student project
Small number of users (no users), independent development, casually messing around.
The work items
Large number of users, collaboration, usability.
Project development process
Student project
There’s no standard process. It’s usually just a pat on the head — “That’s a good point, we can do it.” , and then a planning, a front end, a backstage, rolling up the sleeves is to do. For example, the Pet App is one of my competitions from my sophomore year to my junior year. At that time, the project consisted of two front ends, two back ends, and two plans, and the whole development process was a bit of an “agile iteration”.
The specific development process is that there is a review meeting every two weeks. The contents of the meeting include summarizing the work of the last iteration, summarizing the problems in the iteration, and drawing the work of the next iteration.
It’s a little nostalgic to remember that this process is often done in a bird cage in the school cafeteria. The most wonderful is to sum up the problem stage, can be called “progress seriously delayed but certainly not my problem” large blame scene. The front end says that the planning diagram is given slowly, the icon and the color number are not given, and the background agreement changes every day; The background said that the needs change every day, and not rigorous, he can’t help; Plan said I draw and want to demand and write documents, I try to refuze.
Thus it can be seen that the worst or planning (dog head to save life).
The work items
The process after the work is very standard. Something like this:
Product plan, write requirement documents -> product, developed requirements -> confirm feasible, start development -> development completed, test, acceptance -> online
There may be some up-front planning (market research, planning with your boss, etc.), etc., and the process associated with development is roughly the same. The only constant, however, is change. Needs, or change.
Let’s get to the point. From the perspective of background development, let’s have a brief talk about what I think about my projects at work compared to my previous projects that I was messing around with.
Storage design implementation
Student project
Storage is generally based on MySQL. Development principle: single carry flow, index casually built, data casually write, transaction casually use.
That’s basically it. CRUD isn’t scared. After all, 10qps May not be achieved.
The work items
Here are just a few brief considerations for storage design:
- Sub-table rules.
If the amount of data is small, it can be ignored. But when the amount of data is large, we should consider the sub-table. The key to subtable is to evenly distribute data, while considering the subsequent data inflation. For example, the user order table can be divided into N tables based on the user ID.
- The index.
Let’s start with ordinary indexes. If normal indexes are not considered properly, you can have slow SQL. Slow SQL is very harmful. It may cause db connection exceptions, or even drag down the entire DB. Therefore, queries should be indexed, and the appropriate indexes should be considered.
In addition, unique index, unique index can ensure the correctness of data from the storage level, as a bottom line strategy. This ensures data uniqueness even if the logical layer repeats calls.
- Concurrency control.
For distributed storage systems, data consistency should be considered during concurrent storage. If the concurrency is not high, consider optimistic locking. This is similar to MySQL’s MVCC, which adds a version number to each row of data. When updating, it takes the version number to obtain the record. If the data is inconsistent, it means that the data has been modified and the update fails. If the concurrency is high, consider another implementation.
- Redundant data.
I was naive and dismissive of redundant data. We can figure it out. Why redundant? In fact, getting a piece of data can take multiple RPCS, costing more than redundant storage. Therefore, we need to compare the cost of redundant storage and query to come up with a suitable scheme.
- Statistical fields.
Our system, if it can be simple, should be simple, with as little complexity as possible. Therefore, try to avoid statistical fields, where there are statistics, there will be concurrency control requirements. If the data is not displayed in real time, do not add it to the data directly. You can obtain the data by using the subsequent computing task.
There are a lot of details that need to be paid attention to beyond the list. You don’t know until you step in a hole. These are all tears.
In addition, those of you who are interested can learn about domain-driven design (DDD), because I’m new to it and I’m a piece of shit, so I’m not here to mess with it. If you want newbies to peck (or if you want to peck me), I’m welcome.
Business logic implementation
Student project
Which brings me to my masterpiece (bah), the Pet Love App. At that time young frivolous, write out the code let a person see can not help but shout loudly, “good tuo Shi”.
For example: write n custom exceptions, name happy good, as you like to throw; The parameter name is optional. After a, B, C, d, I, j, k, f; Repeat a lot of code, perfect CTRL + C, CTRL + V engineer name, etc. The code is so deadly, I can’t even open it.
The work items
Although my code is still not good, but compared to the student days, is also tuo mature SHI, not let people want to see the knife to kill. If you don’t want to be cut down by brothers, you can pay attention to the following points.
- Code specification.
I vaguely remember a friend’s description: “When I open a file with thousands of lines of code, I can find traces of five or six colleagues.”
Literally, men will be silent, women will see tears. Since we don’t want to take over old code like this, let’s not let someone else take a soul-beating when they take over code. Start from me, there are norms according to norms, no norms, try to integrate with the original code style.
- Interface idempotence.
That is, the result of requesting the interface x times is the same as the result of requesting it once. This is especially important in scenarios where the calling function relies on the return status of the called function to retry. Incorrect returns may cause the calling function to retry repeatedly, resulting in redundant requests that may be exhausted if the system is not processed accordingly.
For example, when mq calls an AOSVR service, if 0 is returned, the service is considered to be successfully executed and the service is not called again. If the return is non-zero, the system is considered an error and the call continues. Request the AO service with a unique ID. The call succeeds and returns 0. If other requests with the same parameters are sent, the AO service logic returns a non-0 error code in order to obtain the record already exists. Mq will assume that a system error has occurred with the AO service and continue to retry.
For MQ, this can cause a large number of messages to pile up in the queue, resulting in queued congestion; For the AO service, it will be constantly requested, blocking other normal requests and reducing system performance.
- Code readability.
Vaguely remember another friend’s description, “variables named with pinyin calculate, but also with pinyin abbreviation, who can withstand this ah.”
This must be the most feared code of the underworld. There are no comments, variables are randomly named, and a few lines of incomprehensible bitwise operators and magic value calculation functions are filled with the confidence that “I am awesome, and anyone who can’t understand is stupid”.
0202 years, in the emphasis on team cooperation today, for your good I good everyone good, I will generally do the following operations:
In terms of comments:
- At the beginning of the function, comment the function purpose, the main execution step;
- Add comments before each major step;
- Add comments to complex steps.
In other respects:
- Think carefully about naming functions and variables (if I’m not sure, Google translate them or search unbug.github. IO /codelf/)
- Complex logic is broken down into subfunctions to minimize cyclomatic complexity.
- The conditional processing logic with short execution steps is placed at the front and the long one at the back. For example, those that return immediately after an exception are put first.
- The same business logic, written in as easy a way as possible to understand. (Trying to do ing)
Interface Protocol Design
Student project
Generally, these are “style-free” interface protocols. If you’re using RESTful apis, 99.9% of the time it’s false. It’s usually /xx/xx/doSomething. It’s just GET and POST. It’s a simple API.
The work items
The interface of internal calls is basically similar to the design of student projects, as long as the internal agreement is reached and easy to understand. Interfaces for external calls should be standardized and unified to reduce communication costs. Most of them will be designed according to the specification of RESTful apis. The following points are also important for external apis.
- Identity authentication and data encryption and decryption
For details, please refer to the development specification of wechatpay apiv3: wechatpay-api.gitbook. IO /wechatpay-a… , which clearly explains concepts such as public key, private key, and certificate.
For those of you who have not been in contact before, you may be confused by these four questions: Why do you need identification? How to authenticate? Why do you need data encryption and decryption? How to encrypt and decrypt data?
To clarify these issues, for identity authentication and data encryption and decryption have a basic concept.
- Wide and narrow interfaces
In the previous interface design, some fields were reserved for the extensibility of the interface. Or the same interface can obtain different types of data based on conditions.
First of all, the idea of reserved fields is possible, but to verify that they are really necessary, the interface should only return the necessary information. We can confirm the later demands with the product students and determine whether the fields are retained; And communicate with the user to confirm whether there is a possibility of acquisition later.
Second, it doesn’t fit the idea of a single responsibility. Our interface should be simple and clear enough to do only one function. Otherwise, the interface is bloated and messy, with poor scalability, and that’s not good.
- Returns a clear error message
If you look at any wechat Pay or Alipay interface document, you will see a return status code and error message with different error limits.
From the caller’s point of view, it is devastating if the call fails with an ambiguous error. Therefore, the error code must be clear enough to at least allow others to locate the specific error step.