"Web full stack engineer self-accomplishment" read notes

Before buying it, I thought it was a book that taught you how to do a Web-based full-stack engineer, as well as an introduction to what technologies need to be mastered, but the process of seeing it was a methodological book. It feels a bit like the Red Master's "My Internet methodology", to some of their own experience and understanding of the Web full stack of engineers need to have what qualities, and not just what technology needs. This is the fastest book I have bought.

Before reading this book, my understanding of the entire stack of engineers still stay in the node phase, with node in the service side of the wind, there is a time to think that the use of Nodejs as a server development, the front and back end of the unified use of JS development, is the so-called full stack development, the more popular technology stack belongs toMEAN and Meteor. However, many startups, there is no full-time front-end, most of the simultaneous completion of the front-end and back-end code writing, that can also be called a full stack of engineers?         The book's understanding of all-stack engineers is that, in addition to having in-depth research in a field of expertise, there is a need for extensive knowledge and problem-solving skills. Abstract is 1, a special how long, 2, the ability to solve problems (rather than dazzle technology). The entire stack engineer's growth route, must be first refined after broad, comprehend by analogy. If you want to directly pursue the whole stack at the beginning, it will only lead to miscellaneous and not fine, no core competitiveness. All-Stack engineers also feature a high degree of sensitivity to the product business and user experience. And not just about their own part of the technology implementation.  All-in-one HTTP this chapter analyzes the focus of front and back from the perspective of frontend and backend respectively. The front end can find the optimization point by grasping the package tool or Chrome devtools to see each request, the number of resource requests in the same domain, etc., more attention is a page of the number of requests, resource size and so on directly affect the page display speed factors. The backend is more concerned with how to respond to requests more quickly and to reduce server pressure. An HTTP optimization scheme which needs to work together with front and back is given, bigpipe.         the web has become more and more segmented today. Starting the database design is done by the relevant Rd, and now has a dedicated DBA to operate and manage the database, while some of the front-end companies are also divided into UI engineers (also called CSS refactoring engineers), JS engineers. After subdivision of a bit of the career threshold is lower, long-term in one direction may have a deeper attainments, but the shortcomings are also obvious, everyone is delineated in a title limited circle, contact knowledge narrowed, close to the upstream and downstream, there is a part of the gray area, the responsibility is not very good division, project communication costs increased.  transform to Mobile. Whether it is a big company or a start-up company, the transition to mobile is an inevitable trend. In the process of transformation, there are great opportunities and challenges for the front end. As we all know, H5 page has been in the experience of The Spit groove, webview loading and rendering performance is far from the native application, however, H5 as a Web application, natural flexibility is not the native application can do, in order to combine the advantages of two applications, Hybrid was born, for hybrid applications, There must be a certain understanding of native applications, scheme protocols, H5 resources offline, communication between native and H5 to help front-end engineers work better with native application developers.  design principles: Regardless of the direction of development, some design principles are common. For example DRY principle: don ' t repeat yourself. This means that in a system, there should be only one local configuration for any data or variable, and the rest is simply referencing the data here. In fact, in many cases, there may be only one place to use variables when they are defined, and as the business develops and functions iterate, there is a reference in other places, does it need to be drawn off every time we encounter one? In fact, the code refactoring common law is three rules: Allow to copy the code once, when the same code fragment occurs at the same time more than three times, you need to extract it as a public module.  Many of the above mentioned are specific methodologies under certain scenarios, and many of them are not listed. In fact, the book also mentions a lot of non-technical soft quality. For example, how to report. How to communicate with your upstream and downstream collaborators as you report to your superiors. Users who want to make their own products. To be an all-stack engineer is the most important not all the technology stack, but the need to have a full stack of thinking, but also need to assume more responsibility, including understanding of the upstream and downstream work content and knowledge, and then consider the design of the time can also consider the impact of the upstream and downstream, with cross-team driving force and influence.

"Web full stack engineer self-accomplishment" read notes