Tencent cloud technology community – Gold digging home page continues to present cloud computing technology articles, welcome your attention!
Kang Liang is a senior engineer at Tencent. I worked in netease Online Game Division, Baidu Client Department, Tencent Research Institute and Tencent MIG. 10 years of development across multiple platforms, currently in charge of Tencent Translator App.
I have been engaged in front-line development for ten years, and have worked in several places such as netease, Baidu, Tencent Research Institute and MIG. I have successively made 3D games, 2D page games, browsers and mobile terminal translation apps.
Accumulated some insights. There must be still naive place, when to cast a brick to attract jade, chat for joke.
1. Process is too important for the team
To march to war, you need a guide. If you don’t have a guide, you need a map; If you don’t have a map, at least learn from Li Guang and find an old horse who knows the way. If you don’t have an old horse, two heads can discuss in an effort to outsmart one. If three heads can’t even have a good discussion, that’s a typical rabble. It’s better to light three joss sticks and pour a cup of liquor before writing code. Worship Bodhisattva first, and then Worship Google.
I’m personally a mild-mannered person (programmers are mostly nice), but I do see a few strong people who say a lot of strong things. Technically it’s a matter of the word, but any objections get personal. Such a style, in the end is domineering, or have a plan, need to judge carefully.
Why is process important? In fact, if there is sun Wukong on the team, it probably doesn’t need any process, just direction. But as an ordinary soldier, he should worry about defeat first. When looking for a person to tell fortune, should listen to bad place first, good place need not listen to, always be good, bad place must listen to, such ability circumvent.
That’s my attitude: be pessimistic, draw a line in the sand, and think what do you do with that line?
It’s a habit OF mine in development, but it certainly doesn’t apply to buying a house.
Where do you draw the line? Is the hypothetical team without Sun Wukong, only rely on you Tang Xuanzang, zhu Bajie and sand monk, how should go to fetch scriptures.
Wherever we go this month, we should follow the path of mountains and rivers. When we meet monsters on the road, who should resist them? What should I do when I find a girl on the road who needs to be rescued? That’s the process. That’s the principle.
I went through a phase where the process was chaotic. It happened many years ago. You can point it out. There’s no one involved.
In 2011, I encountered several impressive things in the Baidu Browser team. At one meeting, the product presented a DEMO of a Google product, in which there was a very cool 3D effect, and it was required to develop and add it. Only 2 days were given, and everyone was dumbfounded. In order to catch up with the pace of the subsequent development, there were a lot of bugs. In order to correct bugs, the leader distributed all bugs equally according to the staff, so that students in different modules could modify each other. It’s hard to imagine. It is like asking the cook to modify the taste of west Lake fish in vinegar.
The initial symptoms are: bugs fall slowly, bugs increase by extension, everyone is tired to death, the code style is extremely messy, and temporary solutions are created to meet deadlines.
In the middle: People are leaving more and more, code is difficult to maintain, and new requirements conflict with previous AD hoc solutions.
At the end of the game: trying to make some fixes, trying to tweak the architecture, and still making it work is like taking parts out of a flying plane.
And THEN I left in a hurry… There is no real prospect of success.
Later, I came to Tencent’s team and felt that the process was more standardized. Tapd tracking of requirements and bugs, product release in accordance with the rhythm, the feasibility will be repeatedly discussed with the development before requirements are put forward, there is special quality tracking, there is special user feedback, know what to do every day, and know what to do tomorrow. There are product needs and there are development needs! This is very important. A lot of teams, you know, they just have product needs, development is like cattle, and they just plow the field, right?
The process is not so complicated, it is each with his own responsibility + rhythm. We are all part of the “Dorrema Solasido”, each with his own responsibilities, and then we team up and run in a rhythm. Set the pace of what to do and what to run.
Two, don’t show off, honest code
There is a joke on the Internet, saying that someone wants to use JS to implement a simple function, and then his friend recommended dozens of libraries to him.
Is it really necessary? Case by case.
To live at home, you need only a set of ordinary tools. If you’re a car mechanic, you need a car repair kit. If you’re bald, you need a logging machine. Eat with chopsticks, knife and fork, all ok, but do not use pig knife, do not use zhangba spear! And, of course, no toothpicks.
What tools to use, what libraries to use, ask people who have done it, and do a lot of searching on KM. For example: Android encryption, SQLChpher can be used, wechat is also used, you can of course learn; Database ORM idea, using KM recommended GreenDAO is ok; PC 3D engine, OGRE can be used; Small game DEMO, Irrlicht enough; To write WebGL, ThreeJS is enough.
First of all, think about: will some big warehouse hold? What’s the follow-up development? How much do these libraries affect the size of the installation package? Have you researched what is being used in the same product?
Think carefully before deciding what to use, and it’s best to follow in the footsteps of successful projects.
Three, architecture practical + applicable
I like the words of Zeng Guofan very much: build a hard village and fight a stupid battle.
One word long snake array, eight golden lock array, which good? IOS is a single process, wechat Android version 3.5 before the single process, 3.5 after the independent network process; The process architecture of PC browsers is more complex, the UI process, the kernel process, the Render process, and the process tuning model based on the number of pages.
They’re all good, they all make sense, and they all work with current products. So my point is: first analyze the scale and nature of the current product, and then design the architecture.
At the current stage: development efficiency + architecture balance; And look back three months, six months or so, to see how the architecture fits in.
When I worked as a translator for Tencent, I was hesitant to copy wechat and join an independent network process. Later, we reverted to the first and second tier competitors and finally adopted the current single-process model of main function.
Product scale, personnel scale, functional stage, specific problems specific analysis.
Four, both to have the power to attack the city, but also to have the gas to endure the war – BUG
When a product is developed, there are bound to be bugs. In fact, developers in the process of work, there is a certain intuition or psychological prediction, that is: the quality of a functional module. These qualities include maintainability, extensibility, algorithm rendering efficiency, and bug and crash rates.
After feature development is complete, it’s time to defend the city.
Bugs, in part due to architecture, such as complex architectures, lead to complex implementation details;
But there are also a large number of bugs, which are actually caused by three reasons:
1. Do not know about an API, or a platform, or SDK version. For example, the non-main thread in Andrid can’t handle UI-related tasks directly. JAVA memory free is not absolute, and mutual pointing cannot be freed; Number () function with DEX problems restrict the — — — — — — — — — — — — — — — — — — — — – the production of these bugs, and developers fumble the process of learning, experienced a just won’t do it again. It’s a matter of breadth and proficiency;
2. There are also some bugs caused by carelessness. For example, the null pointer problem, the wild pointer problem. In the development of C, the problem of wild pointer, GDI handle release problem, these are serious code to avoid; And some tools or methods can avoid these problems, such as the use of @Nullable and @nonNULL in Android to strengthen null pointer detection and other methods;
3. There are also some bugs “caused by different usage”. For example, I crash a module. The essence of this is that the exception boundary of logic is not handled well. Examples include OOM issues on Android and object release issues caused by UI focus on PC. Some of these exceptions are found by testing, some by user feedback, and some by your own exception handling. Try catch in Android, for example, is an opportunity to correct an exception.
Five, self-examination
Every once in a while, you need to stand on a high plane and look down at yourself and ask yourself whether you are taking on the past or changing the future.
If the quality of the program code is not good before, it will take more time to fix problems later. In the middle of development, it’s important to ask yourself whether you’re constantly correcting past mistakes or doing something new. If it takes more time to fix errors, pay attention to the quality of your code!
Six, comments,
I love writing comments. Some people say: code is the best comment. Unfortunately, I’m not there yet. So, I’ll make the comments very clear. One: for their own future maintenance of convenience; Second: for the convenience of others to take over.
This is how I write comments in the Translator project. 1: For very complex logic, be sure to write clearly in order of 12345; 2: For a function parameter, you need to explain why the parameter is set, especially for a function in a common utility class – explain the background meaning of the parameter so that other callers can understand it more clearly.
I don’t usually write in English. Although this looks very low style, the victory is that everyone can easily understand. Don’t be too arrogant with your code, don’t be too arrogant with your comments, the goal is to make it easier for your partner, or your successor, to understand and work less overtime.
Vii. Code structure
The code structure should be clear. Some by function, some by UI structure. There are common utility classes, data management, master logic control. Either way, an orderly code structure makes everyone feel clean. For example, Japan’s collection and arrangement skills let a lot of petty bourgeoisie praise, nothing more than clean, neat, easy to manage.
And there is an important benefit: what the code structure represents — a modular logic idea of the program — is that everyone works in different areas.
Code style
Uniform code style! Like a family, there is Tom, there is Anthony, there is Rukawa Kato, Ishibatten, St. Jeffrasky, not knowing what to do. In theory, by looking at a function, you can distinguish between member variables, local variables, and global static values by name.
In addition to naming conventions, there is also a convention on the maximum width of a line of code, the length of successive calls to functions, and the inclusion style of header files. The time of occurrence of the class, the creation of the name, preferably also, seems useless, but when it comes to tracing the problem, you can see the benefit of the timeline.
Security and reverse
This is for Android, but there are also PC plugins to consider. The first thing to do on Android is to avoid being reverse-engineered by others. I’ve successfully reverse-engineered and repackaged competing products with first and second places. It seems crazy, but it’s done. Reinforcement + obfuscation + code judgment, preferably both.
Security, you can see the vulnerability of king Kong scan, modify one by one on the line. Company a lot of tools are very easy to use!
X. Development efficiency
Development efficiency can be improved in these ways:
1. Build common utility classes for everyone to use
2. Use open source packages, such as ORM databases
3. You can find problems quickly. In development, the time to find bugs is often a lot. I use three methods: try catch; Intercept all crashes to the location I specified; Too many logs. Logs have a unified control switch.
4. Borrowing power: Data report with lighthouse, crash report with Bugly, company KM experience, bring it to use.
Xi. Volume of installation package
1. TINY compress pictures
2. Delete invalid resource files
UI rendering efficiency
The UI is the user’s first instinct; The UI is fast and stable, so the first feeling won’t be too bad. Manage memory, basically manage half of crash; Good management of UI is equal to the management of human-computer interaction experience.
UI development is: render efficiency and render effect balance.
It was written in a hurry. There must be some childish places. Welcome to correct them.
Related to recommend
Futu Niuniu cloud small program development experience simple but not simple — Public comment + small program development experience talk
This article has been published by Tencent Cloud Technology community authorized by the author. If reproduced, please indicate the source of the article. For more cloud computing technology dry goods, please visit the Cloud technology community