As you can see, my commit log is fairly clear, and I can basically see what the commit is doing.

In the first month, I was mainly familiar with the project, and then made some simple and less relevant requirements, such as the modification of the homepage of live broadcast and the personal information card.

New people do not know enough about the project, and it is best not to start with complex and wide-ranging requirements. That is too risky.

At this stage, I did ok, naming variables and constants is reasonable and easy to understand, and considering abnormal situations is also thoughtful, and there are basically no bugs after the launch (in fact, the function is relatively simple haha).

November is mainly to create live, this demand is more typical, is a page with multiple states, edit, preview, modify and so on.

To develop requirements with similar page styles and interfaces, it is best to abstract out a common base class or interface, and then choose different implementations based on different logic, avoiding various judgment lopes via if-else. This pattern is often referred to as the “strategic pattern.”

Like me:

private ILiveCreateOrEdit getImplByType(int type) { switch (type) { case TYPE_LIVE_PREVIEW: return new LivePreviewInfoImpl(); case TYPE_PREVIEW_EDIT: return new LivePreviewEditImpl(); default: case TYPE_COMPOSE: return new LiveCreateImpl(); }}Copy the code

ILiveCreateOrEdit defines the functions required to create live broadcasts, preview live broadcasts, and edit live broadcasts, such as UI initialization, interface request, and logic for clicking fixed buttons.

Three implementations complete the corresponding state layout display and interface request, avoiding the use of if-else clutter.

This pattern can be used not only for page similarity, but also for logic similarity. For example, some ICONS, badges, pendants download, query, are the same logic, I put them into a manager, define the interface and then specific implementation.

Our latest development. A demand, not in a hurry, we can take time to think about the current demand for what may be similar to this, you could change their logic abstract in common, so behind have similar demand can be based on the common development, expand direct seemingly right now is to do more work, is to save time for later.

Inheritance is better than extension

It is best to abstract out a common base class or interface for repeated layouts and classes, and then implement it by inheritance, avoiding the use of if-else judgment logic in it.

In the past, I always like to use a class for many businesses, resulting in a lot of judgment code in it, which is difficult to maintain over a long time. It is really a bad style.

As you can see from the log, I’ve been working on a few bugs this month.

Part of the problem is UI. When I encountered uncomfortable styles during development, I would modify the interaction by myself. Then I would communicate with the products and designers with the modified styles. Sometimes they would be moved by my wit and agree to modify. But more often than not, my opinions are overruled, it seems that my aesthetic is not good enough.

Part of the problem is that ** is caused by “excessive optimization”. Sometimes write business, can’t help but want to optimize, such as reuse, recycling, preloading. The intention is good, but my heart is too thick, just thinking about the benefits of optimization, not for optimization may cause problems to deal with. Such as state exception handling at reuse time, additional overhead of object pooling, timing of preloading selection, and so on.

Any optimization is a double-edged sword, considering not only the benefits but also the costs.

There is the code is not familiar with their own cause. For example, I am not familiar with the implementation of view.post (); The maxSize and sizeOf() of LruCache are not understood properly. Not familiar with iterators for CopyOnWriteArrayList; Unfamiliarity with the project component lifecycle, and so on.

Be respectful of the project, of the code that runs on many users, and understand as much as you can about what you’re writing to make sure there are no problems.

Finally, I did not develop the habit of reviewing the submitted code at that time. Sometimes I submitted wrong code, such as refactor affecting irrelevant code. This problem was corrected later, and will be checked before commit.

What is not done well is that the cause of the bug is not clearly written in the submission log. For some problems that may occur again, it should be clearly written in the log.

At this stage, I didn’t know what medicine I was taking, so I started to write the submission log in English, probably thought it was cool.

Looking back, I found that this kind of submission is not intuitive at all. Because some details are not easy to express in English, the submission log is relatively simple and fuzzy, which undoubtedly increases the difficulty when troubleshooting problems later. It is not recommended to do so.

In May and June, I developed a relatively complex function, which involves more state and abnormal conditions, and more bugs, so I have the above neat bug log.

What did you learn from the experience?

When you get a requirement, consider what it is for rather than how it will be achieved. Once you know the goal, even if the current requirement is technically impossible or too expensive to achieve, you can try to come up with an alternative rather than just reject it.

Get the business, first layer, interface -> data -> message, although the code is not MVP mode, but thinking can be like THE MVP to define each layer interface, and then determine the dependency, between different classes as far as possible not directly rely on the class, but to rely on an interface.

Avoid direct dependencies

If class B calls A lot of methods from class A, let class A implement interface X, and then B holds references to X, so that future changes to who class A inherits from won’t affect the old code.

Instead of calling a member of another class directly, call it through the getter method, so that the handling of value exceptions can be done directly inside the method without having to change all the places called.

Attention should also be paid to the handling of abnormal situations. For example, weak network, flight mode, APP crash, strong kill app, how to recover the scene after the state is restored to the normal state? Client-side style states are best governed by the server side, some sensitive, often variable can use polling.

The data of the server side shall prevail, but the client side shall do a good job of the bottom pocket, and the data that directly affects the status shall be the bottom pocket. When the data is abnormal, it is better to provide the default state than to display the exception.

As you can see, my optimization log is not detailed enough to write clearly what is being optimized. In the future, I have to write down the content of optimization.

Static code testing helped me find many details, such as:

• StringBuilderIf the number of strings to be concatenated is larger than 16, the construct needs to declare its initial capacity; otherwise, it will expand frequently
• In the use ofStringBuilder.append()Methods the connectioncharacter, avoid usingstringType,charType conjunction character
• Instead of wrapping the new class, usevalueOf()Methods to replace
• Integer.parseInt() 和 Integer.valueOf()The right choice
• DateFormatMultithreading is unsafe
• …

There are also business logic optimizations, such as data comparison, partial refresh, animation efficiency, memory leaks, and so on, that are common. It’s a shame that there are more business requirements and not enough performance.

I communicated with the leader that in addition to awe and responsibility, the development should also have the mentality of pursuing perfection. I should play more and use more of the projects I wrote, and take the initiative to find deficiencies and optimize them. I have to worry more about performance and experience in the future.

Before I got into the habit of writing a weekly report and properly treating submission logs, I was often at a loss to recall what I had done, what I had learned, and what value I had created.

In the past year or so, my submission log has been of some value. After a brief review of what I have done in the past year or so, I found that there are a lot of areas that can be improved. I still need to work hard in the future.

Improvement suggestions:

1. [feature] [fix] [perf]
2. The commit should be fine-grained enough to be committed when standalone functionality is complete
3. Write the log information clearly, what function was done, what problem was solved (why), what optimization was made (what improvement was made)
4. Work needs to be reviewed regularly to suggest improvements