为什么你应该尝试全栈

admin

程序员看到全栈这个概念，大概会有两种反应：
# `7 u& U/ J4 |  u& j' H　　1. 卧槽，这个好，碉堡了
　　2. 你懂毛，全栈就是样样稀松
1 d5 W" a% o& U　　以上两种反应其实都有失偏颇，即使只做一种技术，做的很菜的多的是，而全栈但是样样都做的不错的也不少，更别说这个世界还存在另外一种爆栈型的程序员，做什么什么精。
# b2 ]& j' C6 A  C　　全栈学徒至少要掌握以下几种技能：
, c/ u7 H. K' pWeb 前端开发，至少掌握一种前端框架
Server 后端开发，至少掌握一种后端框架
9 l& P! I; A- U) q1 W; sServer 运维，掌握 Linux Server 的搭建与维护
+ A! ^1 b. z7 e客户端开发，iOS 和 Android 至少掌握一种
  e/ U) I  C; R; \/ P数据库，掌握 SQL 和 NoSQL 数据库
; j( G! R" B( [# L3 J　　而获得“全栈”这个称谓则应该至少独当一面的一个人完成一款产品的构建，并且真的经历过商业化运作，被自己的“愚蠢”坑过无数次。
; o$ Q/ I6 j. M; N6 J* ]* W. R　　由此可见，全栈的门槛还是挺高的，并不是说掌握以上五种技能，就能称为全栈，至少要加个学徒来修饰一下，也正是因为太多学徒自诩全栈，才导致第二种反应如此广泛。
4 u$ V/ B3 R/ [& N3 v) }2 T0 e+ Z　　不过，这篇文章的题目是 —— 为什么你应该尝试全栈，所以讨论点并不在要不要做全栈，而是尝试。
# c) F9 F/ Q9 |　　外行与内行
  H4 F6 B- K- C, C* L; r+ z　　过去几年里，我和不少团队的人聊过，发现绝大部分的团队矛盾都在于——
7 V/ t# B* z1 M+ T; yServer 端的不懂客户端，设计出来个 API 后瞎 BB
" v1 }: N, E  T# `# l. v1 x设计师不懂客户端，设计个交互瞎 BB
! N' ]" D- n6 ~, o/ z9 n+ c+ F% K客户端不懂 Server，对着 API 瞎 BB
; d1 L" P! X$ u1 M5 X客户端不懂产品，对着需求瞎 BB
产品经理不懂需求，对着 Team 瞎 BB
　　除了最后的产品经理应该被烧死以外，前四个矛盾都还是有救的。
( U1 F; q4 W, a" o% F8 Z0 P; e$ w　　程序员是一个上帝模式的职业，每天的工作就是创造，这也正是这个职业看起来很酷的原因。但是正因如此，程序员多少都会有些自负，自负的结果就是以自己有限的知识去揣测别人的工作该怎么做。
　　如果 Server 端不懂客户端，那么很容易设计出来不符合客户端机制的 API，以网页的思维去理解客户端，这时候好点的话做客户端的耐心解释，每个 API 耽误一两天的时间来磨合，不好的话就要吵架了。
　　但 Server 端并不总是错的，客户端希望所有数据给出来后不需要再加工，而往往按照客户端需要的结构给的话，有些查询可能要耗时一两秒。客户端如果不理解服务端的机制，一味以 “服务端就是给客户端服务的” 来要求，就又要吵架了。
2 q  a3 L- K, A! i( u! U　　如果说技术人之间的争论是冷兵器战争的话，那如果碰到更外行的产品经理或者老板，那就要爆发核战争了。
　　“你就改个网页，十分钟能搞定吗？”
( ?2 f) I  ]1 O. H, F0 b8 L+ x　　“效果怎么可能很难做，我给你做个”
　　“明天上线，赶紧的”
9 }6 f' ]) k) v# E8 E　　“我不管你技术上有什么难度，反正你就得给我实现出来”
　　而这样的场景，无论是哪家公司，几乎都在不停上演。
& x9 @/ b" I/ e; h# U7 ^* B　　尝试了解对方的技术
4 T& n0 z* I8 p7 h! P! s$ |　　先聊聊我的技术轨迹吧，从初中开始使用 Linux，以 Ubuntu 作为自己主力系统，而后切换到 ArchLinux，再回到 Ubuntu，一直使用到大一，这几年的 Linux 使用经验奠定了 Server 架构的基础，大一开始尝试自己做一款产品。
　　那时候就琢磨，我应该先写一个网页版，然后再写个客户端。
　　所以从后端开始，我使用 Django 作为起步，不过很快我转移到了 Rails 阵营，Rails 的敏捷开发极大的降低了开发成本，而其的约定习惯，也使得菜鸟能够平安飞过很多危险区域。
4 E/ ?4 p) E- ]4 S5 ~　　开始写网页前端的时候，并不知道有前端框架这个东西，直到用 Rails 写完了后才发现原来有东西叫 Ember.js，于是开始用 Ember.js 来重写，一开始的理解还是如何用 Rails 来渲染前端，后来发现其实在引入了前端框架后 Rails 的角色已经变成了个 API Server 了。
; V6 ]0 ~- n- q& C　　于是由此开始从新的角度去考虑如何设计 Rails 的 API，阅读了大量的 API 设计的资料，怎么样设计前端才好用，怎么样降低查询时间，服务器缓存，redis，安全等等。
( W, F+ g: @5 q' @　　Rails 的自动化帮了不少忙，很多自己并不知道的地方它已经帮忙做好，而当你想了解的时候，又会发现其实现是如此精妙。更别说 Rails 对新技术的接受程度，使得你总是有新东西可以玩，CoffeeScript 和 Sass 最早就是 Rails 吸收作为自己框架的默认前端技术。。
　　随后由 Ember.js 又切换到 Angular.js，用 Angular 重写一遍，期间又接触了前端工具 Grunt （前端的变化一日千里，现在用的东西已经不是这个了）
& x- J1 @. j: \; }+ ?9 h　　最后到了 iOS 客户端，此时 iOS 的界面实现又与网页的 HTML 和 CSS 有着很多不同，也因此又花费了不少时间去理解 iOS 的 UI 概念，把思维从网页转换成 iOS 的界面开发思想。
8 b* d+ j, K( h9 E8 b! R7 f3 Q7 U　　数据库也在这个期间从 MySQL 换成了 MongoDB，因为那几年的潮流也正好是这个转变。
　　这个过程里幸好是我一个人，所以没人可以吵架，不然我想各个阶段都是有很多值得争吵的地方。
　　项目上线后，随着运维的复杂程度逐渐提升，也因此接触了 chef 和 Ansible 这种自动化运维方式，再往后 NewRelic 这类的监控服务也上了，为了一个稳定的开发环境，继而使用了 Vagrant。
7 P# o' f( ?! h, m5 k2 g　　而这一切都只发生在一年的时间里，不过很有趣的事情是，很多时候我写着 iOS 突然想明白了 HTML 和 CSS 的实现原理，做着 Rails 突然想出了更好的 iOS 架构方式，不同的技术之间触类旁通的感觉在每天都发生着。
4 o. T6 i4 u4 ]/ a4 {/ m　　在后来的时间里，这段经历使得我和不同的技术人沟通都非常轻松，因为去年“秒视”做滤镜的原因，我开始研究起 openGL，在重拾了Blender 之后，很多以前似懂非懂的地方，实现突然变的像 Hello World 一样简单，因此也干脆玩起 Unity 来，在这一切的积累之后，Unity 的学习变的非常轻松，成为了我晚上的休闲项目，或许不久之后，你会看到一款我做的游戏（可能会是 RPG）。
! ?! ~# L- w! a" {8 m3 ^& K　　我并不觉得全栈会使得你全面平庸，每种技术在做的时候都可以为其他的技术提供思路，而在你了解各种技术的前提下，深入其中的某个技术，时常能够带来对其他技术的反哺。相反，了解的技术如果非常狭隘，很可能才是限制自己潜能的原因。
　　尊重与和平
* [8 g# `7 S4 u6 T3 P# h　　在团队沟通的时候，对对方技术的了解能减少非常多的沟通成本，并带来尊重和和平。
* g2 x1 {; Y7 K' q　　很少见大神在一起争论谁该来让步，相反往往都是初窥门径的人整天吵个没完，脾气一点就爆。
　　虽然很难讲整个行业的水平能很快有质的变化，但是我想如果产品需求能够详细的描述清楚，说清楚原因，技术人员之间能够在一起相互学习，耐心的探讨，设计师能够尊重技术纬度的事情，设计出更符合当下的原型，那一切就会往者好的方向发展，这一切就从了解对方的工作开始。