Front-end early chat conference, a new starting point for front-end growth, jointly held with the Nuggets. Add Scott WeChat codingdreamer into assembly technology group, the twentieth | front special management, 2021-1-23, online live broadcast.

New a live round table this afternoon, the ant group researcher, pay treasure to experience the department head – jade “to talk to you the front end of the” how to build good team, “registration stamp: www.huodongxing.com/go/tl20

This is the 14th session of “Early Talk about growth and Promotion” and the 102nd session of “early talk”. The text version of the speech is from the Experience Technology Department of Ant Financial (now renamed Ant Group) – Dead Horse (please see the video and PPT for the complete version).

First, introduce yourself

I am not four, after graduation has been in Ali and ant work, not four is I in Ali flower, community generally to another flower “dead horse”. I’ve been working on Node.js and Web development for over 8 years, and I’ve also been involved in a number of open source projects in the community, including Koa, Egg, and CNPM, etc. I was lucky enough to be involved in the early days of Node and catch up with the big wave of front-end revolution brought by Node. Everyone’s growth trajectory is different, and the opportunities they encounter are also different. This time, I will share my growth experience and some personal habits running through it from the perspective of an ordinary engineer.

Second, the growth process

internship

In the summer of 2011, DURING my junior year, I came to taobao data platform for internship. I was recruited as a C++ engineer and assigned to a Web product team in the data product department. I still used the newly born node.js as the server-side development language and practiced full-stack development. I still remember that the version of Node was only 0.4 at that time. I was a rookie who could not even distinguish JS from JSP. I only wrote C++ with black boxes for three years in college, and I didn’t even know what HTTP was, so I began to learn JS foundation in a puzzled way.

Many years later, I became a colleague of the author of the introductory textbook

Fortunately, the team gathered at that time, including the first batch of Domestic Node.js evangelists, the promoters of Node Party, Kongwu, Qingdu and Xuancheng, as well as the core contributors of the Domestic Node community, Su Qian and Pu Ling, etc., all gathered in this team and followed their steps. During my internship for more than half a year, I forgot C++ smoothly and became a rookie JS engineer.

Data Product Department

After graduation in 2012, I officially joined the Data Product Department of Taobao. That was the hottest era of big data. Sitting on the golden hill of Taobao data platform, we mined data products such as rubik’s cube, Taobao Index and Taobao Time Machine. As I got deeper into the business, I gradually understood why the team chose the Node technology stack. The calculation and business logic of most data products themselves are relatively not too complex and rely on a large number of back-end data sources to provide data, which is a typical IO intensive application. The full JS stack can also bring more efficient research and development efficiency.

Data cube

Taobao Time Machine

With more and more scenarios covered by data products, we need to connect various internal systems of Ali Group, so we use Node to realize internal micro-service framework, login system, configuration system and other middleware. With the more and more prosperity of Node ecology, the construction of an internal NPM package management system is also put on the agenda. We tried to use the official SOLUTION of NPM to build, but it was difficult to operate and maintain, and could not fully meet the demand. Finally, we developed CNPM to build an internal NPM package management platform and provide a domestic NPM image. Later facts proved that, A fast NPM package management platform is crucial to enabling Node and the large front-end community to thrive.

In the first two years after graduation, MY skills grew rapidly. On the one hand, there were many talents in the team to learn from, and on the other hand, I also caught up with a wave of welfare period when Node technology was just born. I also completed my first promotion from P4 to P5 here.

Tmall front-end

In 2014, due to some changes in the team, I transferred to the front end team of Tmall. At that time, there was no full-time Node development engineer in the front end team of Tmall. A big challenge for the team was that the activity page was run on PHP before operation. With the gradual reduction of PHP engineers in Ali, the PHP system in disrepair could no longer support the Double 11 event with increasingly exaggerated traffic. So I set out to implement the next generation of page rendering services through Node.

The new service was verified on the homepage of Tmall on November 11, 2014, and was much better than the old PHP service in terms of performance and stability. Then we started to implement a new visual page building system based on the new service layer, which perfectly supported the double Eleven for 15 years. This system has been serving up to now, of course, it has evolved to be more complete and complex.

Benchmark for PHP and Node.js systems

In tmall, I realized an important business system with a brand new technology stack and achieved great business value. Therefore, I was promoted from P5 to P7 in 2015.

Ant Experience Technology Department

In early 2016, I decided to transfer from the front end team of Tmall to the Experience Technology Department of Ant to provide internal Web framework and BFF research and development mode support for the large front end team. In fact, BEFORE I went to Ant, I had been maintaining Koa and some services of Web framework ecology and middleware. The first thing I participated in after joining Ant was to draw egg.js from Ant’s Web framework Chair at that time, so as to unify the big front-end Web R&D system of different BU in Ali economy. Egg.js has subsequently been made open source to the community.

An Egg. Js ecology

After more than two years of development, THE BFF research and development mode has gradually been accepted by Ant, Ali economy and even the domestic market. I have also been promoted to P8 here.

Language finches

With an opportunity to adjust the internal organizational structure, I came to the Language finch team. It is one of the ants experience department internal innovation incubation projects, provide hundreds of ali people knowledge synergy and document management services, 18 years, language finches began to external services, and went to work around a circle, I returned to use JS application development stack completely, the Chelsea team, we do a product engineer culture, efficient complete product research and development.

Language sparrow product engineer culture

In the past eight years after graduation, I have been wandering around in a company, but I have been focusing on one technical field and exploring in different directions such as underlying technology, basic services and product research and development. There may be a lot of luck in growing up. It’s hard to completely control what kind of teams and bosses you have, what kind of things you can do, but what we can control is how you develop your technical skills as an engineer to be ready to take advantage of opportunities.

Three, engineer growth password

Looking back over the years, I’ve developed some habits at work and in the community that have probably had a big impact on my technical growth.

Keep writing code

Obviously, as engineers, our most important job is to write code. Practice makes perfect, and coding must be one of the most important things in the engineer’s handbook. Coding must be one of the most important parts of my daily job, whether I’m working on a technical project or leading a team.

While low-quality repetition is meaningless, we should keep writing code, and keep writing good code.

What is good code? This question may have different answers to different people’s eyes, but for me, good code has at least three requirements:

  1. Good code is simple, simple code has a clear architecture and makes coding easier;
  2. Good code is for people to see, the vast majority of applications are to continue to maintain, do not dig holes for others, also do not dig holes for the future of their own;
  3. Good code is testable. By writing unit tests, it not only ensures the logic completeness of the code, reduces bugs, but also facilitates later maintenance and reconstruction.
Keep your code simple

Starting with simplicity, simple code is easy to understand, but trying to write simple code is more complex to structure. This is to put forward higher requirements for myself, constantly optimize and refactor, and grow in this process. When meeting some complex requirements, I always believe that if a logic is difficult for us as implementors to sort out, and if and else conditions in the code are determined, the user must also be unable to understand.

So when faced with this situation, we need to think from both the product side and the architecture side, what causes complexity? Whether we should optimize the product requirements or the underlying architecture also forces us to think more deeply about the product and architecture.

Code Review

Another habit that my team and I have been adhering to is Code Review. CR is a great way to improve the quality of your code. It requires a lot of effort from your team, but it will pay off.

We face CR’s soul with three questions:

  1. Why do WE do CR? The business is so pressing, how can we have time to do CR?
  2. Who will do CR? Is it the team leader, the core engineer who can help others CR?
  3. CR is a lot of energy, how to stick to it?

The subject of Code Review is people, and the object of Review is Code

  • For code submitters, quality is definitely more important when you know your code will be seen by others. I remember the pressure I felt when I started submitting code to mature open source projects in the community. It would make you design and code more carefully before submitting code, and after CR after CR, you would see the quality of your code improve dramatically.
  • For reviewers, each CR adds to your familiarity with the overall code base or different businesses, and can impart experience and impact on the team.
  • Finally, through Code Review, we can improve the quality and maintainability of project Code, unify the Code style of the team, and make every business logic find back up as far as possible. CR is a win-win-win thing.

CR is a meaningful thing, but how should we do it?

The first step is to start from yourself, through their own initiative and persistence, to drive the team to participate. When submitting code, write a commit message, test yourself, pay attention to the readability of the code, take time to Review the rest of the team’s code, and take responsibility for each line of code.

However, CR is still a team matter, how to maintain the quality of team CR? We must strictly grasp the first CR of new recruits. Generally speaking, the first PR of new recruits in our team will be challenged greatly. New people may not be familiar with the code, and the coding style may not be consistent with the team, so the first CR is very important to align standards and requirements for code quality.

Hit the new guy hard

In addition to the code, the design and architecture of the upper level also need to be reviewed, so that every system function design and architecture upgrade can be reviewed, which can not only make the system more stable, but also quickly improve their system architecture ability.

Unit Tests
  • How is your code quality measured?
  • How do you ensure code quality?
  • Do you dare to refactor code at any time?
  • How do you make sure your refactored code is still correct?
  • Are you confident enough to release your code at any time without testing?

If you don’t have the answers to these questions, or if you don’t have 100% confidence, you need to unit test your code.

Now talking about unit testing, you still functioning of feeling, but I just work in 12, 13 years, unit testing is a relatively new concept, but the node of the open source community is already gradually became popular to write unit tests, when you submit code for other open source project, no test is impossible to be merged. The high-throughput TJ not only provided Web frameworks such as Express Connect, but also provided a series of underlying test modules, including test case driver Mocha, assertion library should. Js, HTTP request test library Supertest, and so on.

Follow the community together, we introduce the unit test to our early work, basically from my formal job to start writing the first line of the project code in the write unit tests, start the habit let I in eight years of work experience to keep the good quality of the code, in the absence of test engineers tested under the condition of my code, Ali fired him without a major glitch.

When it comes to writing unit tests for business code, the first thing you probably think about is when do you have time to write unit tests? Writing a single test is really not that time-consuming, as long as you find the right tools and methods. For unit testing, there are only four steps:

  1. Create some initial data;
  2. Mock external dependencies;
  3. Minimally granular execution of the method to be tested;
  4. Make a claim about the result.

All that remains is to structure the test case inputs in this way, covering every branch and edge scenario in the code as much as possible.

Unit testing is even more important in Web applications, where each test case provides a layer of stability for the application in a time of rapid iteration of Web products. With API upgrades, test cases are a good way to check code for downward compatibility, and for a variety of possible inputs, once the test is covered, its output can be identified. After the code changes, you can use the test results to determine whether the code changes affect the determined results. One of the most important things we did with egg.js was to write a testing framework for it, making it easier and less costly for businesses to write single tests to ensure code quality.

To improve the code coverage and see the test coverage report full green, not only to the online code more confident, but also a great sense of achievement.

Continue to share

If writing code consistently is practice and input, then another habit that has helped me grow is sharing, which seems like an external output, but in my view is a great learning opportunity.

When I first started working in The Data Product Department, our team organized an internal sharing salon called “Show Me The Code”, which was a very casual sharing meeting. We did not need to prepare a formal PPT or a long sharing time, but simply shared The new knowledge we learned recently and The interesting codes we saw. This cultivated my habit of sharing. At that time, IN order to find a topic to share, I often took the initiative to study some new modules and read their source code. I also built some small wheels to solve the repetitive work encountered in practical work. And now in the Language sparrow team, I also organize internal bi-weekly sharing sessions, which have been going on for more than a year.

Even a little sharing will be fruitful

During these years of work, I have also made a lot of external sharing in external meetings. Basically, every time you share, you need to carefully check what you want to share, and try to prepare it to be easy to understand. After each presentation, you will feel more deeply about the topic area.

For me, sharing is more a good opportunity for me to make a phased summary. The best way to learn is to teach others, because no one wants to make a fool of himself on the stage, right? To listen to a technology sharing, the knowledge you heard will be forgotten in an instant, and you will prepare a speech carefully. The speech will benefit you the most.

Participate in the open source

Another factor that has had a big impact on my technical growth is open source, which is essentially sharing.

It’s a time when a hundred flowers are blooming and projects in the open source world are on the rise, with 44 million new projects created in 2019, according to GitHub. Every engineer with a technical bent has probably thought about writing something on GitHub, but open source doesn’t mean submitting code on GitHub. It’s more of a mindset.

  1. Open source means that you will give all developers to Review your Code, like the previous Code Review said, when the Code to people is a very stressful thing, what’s more, after submit to making, everyone can see, your colleagues, the interviewer can see, must be seriously every line of Code, every time.
  2. And when someone uses your open source project, it means that you take responsibility, even though the open source license may be very lax, for the code you write.
  3. Open source should make you feel the “pain”, the need to put more stringent requirements on open source code, the pursuit of optimal code architecture, complete testing, clear description, the process of writing high-quality code will make you feel the pain, but there will be faster growth.

It may sometimes be hard to come up with a good idea or implement a high-quality open source project on your own, but don’t worry, the barrier to entry is not that high.

The first step is to pick a high-quality open source project in a field that you can use in your work, and why it’s important to use it in your work, so that you can better identify the direction of improvement and pain points. For example, Koa was the open source project THAT I chose to be deeply involved in at that time, because MY work was also focused on Web research and development, and I thought Koa’s asynchronous programming model based on CO must be the trend of the future.

The second step is to get involved gradually, perhaps at first just tinkering with the documentation, finding Bug fixes, and adding a few test cases. Gradually, as you improve the code and surrounding ecology, you can further realize some missing surrounding ecology, and try to submit some functional improvements to the project according to your actual problems.

There are many high quality projects abroad, we can also help them do the translation of documents. Don’t underestimate document translation. Translating documents means you need to understand the project in depth, which can be difficult and rewarding, and can increase community impact.

Open source is a achievement-driven business, and because you don’t get any tangible benefits from it, one of the most important things about continuing to participate in open source is that you get a sense of accomplishment from it.

Grow with the team

Having said so much about personal growth, I want to talk a little bit more about teams. As individuals, we work in a team, and only by helping the team grow together and gain business value can we “monetize” our technical growth. The Code Review or unit test mentioned before all need the cooperation of the team.

  1. If your team doesn’t already have an internal sharing session, try to organize one yourself on a regular basis.
  2. Do CR and single test from now on, use yourself to influence the team;
  3. Try to build an engineering culture within the team that fits the team.

In fact, the first two points have been mentioned in the previous sharing, which is what our team has been insisting on and advocating. Chelsea team culture, I want to say the language in language finches we hope every engineer is the product engineer, he is the product of technology partners, participate in product discussion, complete the research and development of product function, at the same time he was also a technical experts in the field of concrete, such as front-end UI components, editor, the service side, and so on. In our workflow, all engineers participate in project development as a whole stack, and follow up the whole process of the project from product design, to system analysis, r&d self-test, CR and launch. Through the product engineer culture, we encourage every engineer to find their own growth direction in business and technology, and grow with the team and the business.

Personal growth is important, and in order to achieve good results and get promoted, it is important to tie personal growth to the growth of the team. Help your team create business value by doing what you do best, and in the process increase your impact both inside and outside the team. Find that individual and team win-win point to exert efforts, you can get twice the result with half the effort.

Five, commercial time

Our team is looking for node.js full stack product engineer and editor engineer. Students who are interested in productivity synergy or full stack engineer are welcome to grow up together. Please refer to “Ant Financial Language Team Recruitment” for detailed job description.

The lecturers of the conference are very helpful in each episode. Sign up to share the latest live broadcast in 2021. See the link at the beginning of this article.