Why should you try "full stack" [reprint]

Editor's note: This author Zhou Xiwen, founder of the Ceo,catch team (http://catchchat.me/), the developer of the whole stack.

Specializes in IOS development, UI design, Ruby on Rails, interface dynamic, 3D modeling and more.

has independently developed Piner, Coinsman, Milkpass and other apps. Love the open source community, there are Pnchart, Waver and other open source projects.

Programmers see the concept of full stack, there are probably two kinds of reactions

1. Lying trough, this is good, bunker

2. You know Mao, the whole stack is everything.

The above two reactions are biased, even if only to do a technology, do a lot of food, and the whole stack but everything is done well, not to mention the world there is another kind of explosion-type programmer, what to do what fine.

A full-stack apprentice must have at least the following skills

1. Web Front-end development, mastering at least one front-end framework

2. Server backend development, mastering at least one backend framework

3. Server operations, mastering the construction and maintenance of Linux server

4. Client development, IOS and Android have at least one

5. databases, mastering SQL and NoSQL databases

And get the full stack this term should at least independently a person to complete the construction of a product, and really experienced a commercial operation, by their own stupid pit countless times.

Thus, the entire stack of the threshold is still very high, not to say that mastering the above five skills, it can be called full stack, at least to add an apprentice to decorate, it is because too many apprentices boast full stack, only to lead to the second reaction so broad.

However, the title of this article is-why you should try the whole stack, so the discussion point is not to do the whole stack, but to try.

Layman and expert

Over the past few years, I have talked to a lot of people in the team and found that the majority of team contradictions are

• Server-side do not understand the client, design out an API after the blind BB

• Designers do not understand the client, design an interactive blind BB

• Client does not understand Server, to the API blind BB

• The client does not understand the product, to the demand blind BB

• Product managers do not understand the needs of the Team blind BB

In addition to the final product manager should be burned to death, the first four contradictions are still saved.

The programmer is a god-mode career, and the job of the day is to create, which is why the profession looks cool. But because of this, the programmer is somewhat conceited, and the result of conceit is to speculate on the work of others with his limited knowledge.

If the Server side does not understand the client, then it is easy to design out of the API that does not conform to the client mechanism, the thinking of the Web page to understand the client, at this time better to do the client's patience to explain, each API delay a day or two to run, bad words will quarrel.

But the Server side is not always wrong, the client wants all the data to be no reprocessing, and often in accordance with the structure required by the client, some queries may take two seconds. If the client does not understand the service-side mechanism, blindly to the "service side is to the client service" to demand, it will also quarrel.

If the argument between technical people is the Cold war, then if the more layman of product managers or bosses, it will be a nuclear war.

"You just change the page, 10 minutes to get it done?" ”

"How can the effect be difficult to do, I'll make you a"

"Tomorrow on the line, hurry"

"I don't care what your technical difficulties are, you have to give it to me anyway."

And the scene, no matter which company, is almost always on.

Try to understand each other's technology

First of all, talk about my technical trajectory, starting from the middle school to use Linux, Ubuntu as their main system, and then switch to ArchLinux, and then back to Ubuntu, has been used to a freshman, these years of Linux use experience laid the foundation of the Server architecture, Freshman began to try to make a product of their own.

At that time, I should write a Web version, and then write a client.

So from the back end, I started with Django, but soon I moved to the rails camp, and the agile development of rails greatly reduced the cost of development, and its convention habits allowed the rookie to fly safely through many dangerous areas.

Start to write the front end of the page, do not know that there is a front frame this thing, until after using rails to find something called ember.js, so began to rewrite with Ember.js, the beginning of the understanding or how to use Rails to render the front end, and later found that it actually introduced the front end frame The role of Rails has become an API Server.

So starting from a new perspective to consider how to design the Rails API, read a lot of API design data, how to design the front-end to use, how to reduce query time, server cache, Redis, security and so on.

The automation of Rails has helped a lot, and many of the things that you don't know about it have helped, and when you want to know it, you'll find that its implementation is so subtle. Not to mention rails ' acceptance of new technologies, so that you always have something new to play with, Coffeescript and Sass are the first rails to absorb the default front-end technology as their own framework.

Then by Ember.js and switch to Angular.js, with Angular rewrite again, during the touch of the front-end tool Grunt (front-end changes rapid, now the use of something is not this)

Finally to the iOS client, the interface implementation of iOS and Web page HTML and CSS have a lot of different, and therefore spent a lot of time to understand the UI concept of iOS, the thinking from the Web page to the interface development of iOS.

The database also changed from MySQL to MongoDB during this period, because the trend of those years was just the same.

Fortunately I am a person in this process, so no one can quarrel, or I think at all stages there are a lot of places worth arguing about.

Project on-line, with the complexity of operations gradually increased, but also to contact chef and Ansible this automated operation and maintenance, and then newrelic this kind of monitoring services, in order to a stable development environment, and then use the Vagrant.

And it all happens only for a year, but the funny thing is that many times I write about iOS suddenly trying to understand the principles of HTML and CSS, doing Rails suddenly come up with a better iOS architecture, and the comprehend by analogy between different technologies is happening every day.

In later times, this experience made it easy for me to communicate with different technical people, because I started to study OpenGL when I was a filter for last year, and after I regained my blender, a lot of the places I used to indefinitely, suddenly became as simple as Hello world, So it's just a matter of playing unity, and after all this accumulation, Unity's learning has changed so easily that it's been my evening's leisure project, and maybe soon you'll see a game I've done (probably RPG).

I don't think the whole stack will make you full of mediocrity, each technology can provide ideas for other technologies when you do it, and in the premise of understanding the various technologies, deep into one of these technologies, often can bring back to other technologies. On the contrary, understanding of the technology if very narrow, it is likely to limit their potential reasons.

Respect and peace

When communicating with the team, understanding each other's technology can reduce the cost of communication and bring about respect and peace.

Seldom see the great god together arguing who should come to give in, the opposite is often the first glimpse of the people all day noisy, temper a little burst.

Although it is difficult to say the level of the entire industry can quickly have a qualitative change, but I think if the product needs can be described in detail, explain why, the technical staff can learn from each other, patient discussion, the designer can respect the technical latitude of things, design more in line with the current prototype, then all will be good for the direction of development, It all starts with getting to know each other's work.

Transferred from: http://www.ifanr.com/551905

Why should you try "full stack" [reprint]