Long time no more bo, read the last time is two months ago, scared me. After changing the job, often 11 o ‘clock at night, 12 o ‘clock back home, really a little busy, but no time to sum up is their excuse.

I have been working for two companies for exactly one year. I have done front-end service for users and front-end service for management system. Now I am mainly engaged in active page of mobile terminal. I write business-related code every day. I am afraid of being reduced to cheap labor over time, so I am thinking about how to increase my value.

Learn to cut demand

Lesson one is to take a kitchen knife to your demand side

For example, we received a demand last week to conduct a promotion activity for our partners. Users can get coupons by purchasing products of our partners through our H5. At the review meeting, the product manager blurted out that the management background could configure the event city, product name, price, introduction and so on. With a rough timeline, it would take at least three weeks of work to complete the big picture he described. Add in background testing, and you have monthly activity.

However, the registration period for this event was only three days. After three days, the event was offline, and the entrance was no longer available, and only 15 products were displayed.

** Product Manager!!

Requirements were cut down at the demand review meeting, separated from the activity participation logic and page display content, the front-end displayed content through JSON configuration page, JSON configuration directly in the operation background. The messy configuration was written directly in JSON, and the back-end provided another interface back to the front-end to achieve the same configurable active page. Finally, the front-end took four days to test.

Learning to cut demands isn’t about being lazy, it’s about thinking about spending your time in ways that are more valuable. A month spent implementing an activity page that was only used for three or four days and didn’t match the team’s main goals was a waste of life. Programmers have the right to say no to unreasonable requirements.

Proactively think about the purpose of development

Make clear what users the page you are doing is ultimately for, what purpose users need to accomplish through your page, for example, do the company’s internal management page, take the operation management system as an example, take the initiative to think about what purpose operation colleagues need to achieve through this page, and how to improve their work efficiency.

There are two main reasons to consider this: the person making the requirement doesn’t understand the code, or they think a better way will lead to higher development costs, and you are the one who understands the requirements and knows the development costs.

As mentioned in the last article, the front end is cute. Actually, the interactive draft I got at the beginning is like this

Operation colleagues manually fill in the ID of the corresponding component and assemble the avatar, which only takes half a day. But there is a serious problem, the match does not know what he matched the thing looks like, can not preview, fill in too many things easily confused. One avatar requires 12 ids, and 100 avatars require 100 * 12 lookups.

After some reflection, I decided not to use this implementation, preferring to spend more development time making a more reasonable facial MOE. The final implementation is exactly the same as the client.

Little point… Done!

Development time is 3 days longer, but this implementation reduces operational staffing time, communication costs, and error probability.

Understand the requirements, implement more humane, more reasonable implementation.

Code reuse, scaffolding

Cut down the requirements and enter the development phase.

After doing more than one activity page, you will find that the same UI designer provides the same script, many common styles, such as popovers on the page, used in the last activity, the designer directly moved over to change a few words to continue to use. (Keep the UI uniform)

More abstractly, popover is a behavior that almost every activity has. It is a common component that can be used for content filling and event binding for specific actions, so that the next active page can reuse this common component directly.

If the page is slightly larger, you can consider writing a scaffold. The so-called scaffold is some templates. By configuring different information and pulling different templates, you can quickly build a prototype of the page.

After familiarizing yourself with the common patterns of pages, modularize your code, abstract your modules, write more common components, and reduce the coupling between components. General-purpose components should be plugged in and played, then removed, like plugins.

Speaking of code reuse, by the way, I recently found that vscode snippets are particularly useful. Configure your common snippets and set the slot so that when editing files in the corresponding format, you can output snippets by typing keywords.

This kind of code is simple, but almost every page needs the same. Simple configuration can save a lot of time for copying and pasting.

workflow

The development process will meet all kinds of problems that need to be optimized, which product managers and designers may not care about, but as a programmer with feelings should pay attention to the point.

For example, images that show the same content may be ten times smaller in different formats. Crop images to the right size, choose a reasonable image format, use acceptable compression algorithms, and ultimately save several megabytes of data per user.

Manually perform the above operation, one round next hour disappeared. Repetitive work should be done and used by machines

  • Sips command – Tool: Sips, the image tool of the Mac
  • gulp-tinypng

Easy to do, no longer in the clumsy optimization one by one.

Sips -s format JPEG *.* --out jpegs // Sips -s format PNG *.* --out pngsCopy the code

Nowadays front-end development basically uses webpack, gulp and other tools. These tools provide interfaces, plug-ins, and can be implemented with minimal configuration code. Coding repetitive tasks to machines saves us a lot of time doing repetitive tasks. Without tools, you have to do it manually, and it might take you two minutes to annotate a line of code.

Can use code to solve the problem, try not to fight manual strength.

Small tools

In addition to business development, there are other things that annoy you, such as the backend team using ApidOC to automatically generate interface documentation. It can be used normally, but I think the apidoc page is not written well, each copy interface is easy to copy to other content, unbearable manual write a page plug-in.

Combine tamperMonkey with Clipboard.js to implement several common copy operations. To copy something, just click on it.

summary

At the end of the day, improving development efficiency is a matter of time cost. Investing less time can achieve the same effect, or investing a little more time can save ourselves and others a lot of time, and we all have more flexible time to change the world.

If reproduced, please indicate the source:
w3ctrain.com / 2017/07/01/effective-work/

My name is Zhou Xiaokai

I am a front-end development engineer now, and I am still a rookie in the way of programming. W3ctrain is the place where I record my learning and growth.