Share some of my own experiences in company development

I don’t know if the word principle in this title is correct or not. Let me call it principle. For those of us who write code, I will actually call it a standard later, but after thinking about it, for other aspects, it may be a principle, okay, don’t get entangled and go directly to the topic.

I have been in the new company for more than a month. The day I first arrived at the company happened to be the beginning of an iteration. Until yesterday, the backend version had been synchronized to the public network. The APP was slightly delayed because it needed to be reviewed, but the internal test It is also in full swing. I have just changed to another environment, and the development model, code specifications, code submission mode, etc. in the new environment are all new. The most profound thing about me is naturally the method of code submission. I am used to the previous code review method. After coming here, there is no such mandatory mechanism, so I indulge a little bit. Because of this, I relaxed myself.

The price of laxity is a bit tragic. It was not until yesterday, the eve of the version's launch, that I truly understood that many things require principles, rules, and standards. Without rules, there is no circle. Without standards, the code cannot be called good. I develop products for Android, so naturally I can’t produce a good APP. Let me talk about regulations first from my perspective. From the perspective of programming standards, especially Java programming standards, null pointers are one of the most common problems. If a field is added to the background, but the APP version wants to connect to the old background first and compare the functions before and after, this has not been done at this time. Entering the parameters to judge, you can imagine what the result will be, the APP crashes. If the judgment is made, then OK, at least from the user experience point of view, the APP does not have fatal problems. However, entering parameter judgment is only one step. Without judging null, it can also prevent it from crashing. This is a trick that can be found on the Internet, and it can only use constants as the prerequisite for judgment. In fact, when I was writing this paragraph, the classmates who read it must have thought that such a simple thing was easy. That’s good. It means that I was stupid for this little mistake. This was also the first deep feeling I had after I got home yesterday. It’s not that you don’t know how or that you don’t understand, but that you didn’t pay attention and a small detail caused a murder.

Non-null judgment, as well as array out-of-bounds exceptions, these are problems that easily occur in both Java and C. I remember that in the previous project team, there were military regulations for Java and C. These low-level errors needed to be eliminated. A good way to avoid this is code review. Even a company as awesome as Google needs to do it, let alone us. I remember that when I first arrived at the Hangzhou company, my colleague asked me to do a review. I didn’t respond for a while. Later, I gradually became familiar with the process and listed some common mistakes as prerequisites for review. I have read a lot of chicken soup articles on the Internet, and the importance of reviews has been mentioned many times. Reading more about other people's codes is also a way to improve your capabilities. Code review used to be a must for the project team, but now because it is not enforced, I have slacked off, and there are problems with the code when the new version goes online. In fact, I can also shirk the responsibility. There was an error in the backend when the version was launched. It took three rollbacks to fix it. However, there were still parameters that were not configured, resulting in incorrect configuration and incorrect parameters obtained by the APP. Logically speaking, in a situation where the APP and the backend are strongly related, I actually confirmed it with the backend before, but the reason is irresistible, so it doesn't mean that the backend colleagues tell you that there will be no problem, you have to be 100% convinced. This is also a problem. This kind of self-judgment ability requires you to strictly abide by your own inner programming standards and principles. No matter when and where, you need to make a complete plan for the APP and ensure the user experience.

This is the first time I participated in the launch of a new company's version. The client encountered a crash caused by the input parameters not being judged to be non-null and the array length not being judged. I really felt guilty. In fact, this was the case before. Necessary operations, this time the problem was entirely caused by my not strictly following it. Fortunately, it was only pre-launched and the problem was solved internally. I don't know much about the background problems, but I know that it was rolled back several times. Fortunately, it was within control and there were no near misses. As far as I know, most of the backend problems are caused by the configuration not being synchronized and the code not being synchronized online. Suddenly I discovered a common problem. On the day when the version I encountered was launched, the development team was fully prepared. There will always be problems, big or small, either during deployment or when the APP was suddenly tested. I don’t know if you have experienced this, haha.

This is my first experience, and I know the routine. I also want to share another feeling of mine. Making products is a very serious matter. I still remember that when I was developing together with several new colleagues, because one of them was slacking off, the boss of the group said in front of everyone during the morning meeting: Our product development will no longer be like the graduation project in school. Yes, everyone needs to be product aware. Since then, I have kept this sentence in mind, but unfortunately, I have not done it well myself, especially when it comes to writing code, and I have lost the awareness of the product in my self-relaxation. To make a product, writing code is just one of the things. There are also needs analysis, needs assessment, and even flow charts, etc. I will make the most of what I have learned in the past three years to make the product better. I also used the experience of releasing a version for the first time to warn myself, don’t lose the principle of whatever you throw away, otherwise what you will always do is just an APP, not a product.

The above is the detailed content of Share some of my own experiences in company development. For more information, please follow other related articles on the PHP Chinese website!