前端是不是沒有地位？
前端地位
最近的，最遠的最近，或者說在過去的幾個月里，我與幾個前端同事，一直在討論一個話題：『作為一個前端開發人員，我們面臨怎樣的困境?又該如何去解決?』。
而在較老的一次歷史討論(可能是在 6 小時以前)里，我便想重新理清一次其中的思路，也就有了這篇文章。
前端是不是沒有地位?
答案：不是，也是。
當我們在技術領域，技術團隊，討論地位的時候，說的實際上是話語權——技術的話語權，KPI 的話語權。技術話語權，是因人而異，當你可被信賴時，你就有了話語權。而 KPI 話語權，實際上指的是 title。
1. 來得晚的前端沒有 Title。Title 是一個很有意思的東西：先到先得，你去了一家高速發展的創業公司，你的 title 就升得很快——站在風口，大象都能飛。而，大部分 Web 應用，前期注重的往往都是應用的功能，這也導致了：這些組織在前期并不需要優秀的前端開發。而發展起來之后，便開始追求用戶體驗、視覺效果、多平臺，到了這個時候呢，關鍵的坑位已經被后端占據了。畢竟好的前端很貴，但是能實現頁面的前端到處都是——甚至是后端也是。
2. 后端懂點前端，而前端不懂 CRUD。事實上，大部分的組織對于團隊負責人，都有一個默認的要求：『精通』整個系統——無論是前后端。這就意味著，前端需要懂后端，后端也需要懂前端。所以，一個不懂后端的前端，站不到 title 上;一個不懂前端的后端，站不到 title 上。可是呢，對于普通的開發人員來說，要達到中等前端水平的時間花費，要比后端少得多。而如果放到大前端的領域來考慮，這個問題就需要額外商榷了。
PS：懂后端也并不要求，你精通后端。因為***的籃球教練，并不要求會打籃球。而打籃球***的不一定會當技術負責人/Coach，比如——科比被女兒懟：“你不會打籃球，教練是這么教我的” 。當然了，有技術底子是***的，但是它也可能在一定程度上限制你。
3. 需求導向(可選)。對于服務型公司，如我司，需求方決定了架構的復雜性，決定了其所需要的 title。而需求方對于架構、復雜度的考量，往往是來自于整個市場的平均知識水平。也就是說，一旦業務方需求不復雜，也就不需要高級的前端開發，便談不上就不話語權。
綜上所述，若是想爭取地位需要：去得早，懂后端，機會好。
扯太遠了，那么繼續往下扯。
5 個因素決定前端
一. 復雜度，決定前端
同樣是做一個手機，諾基亞的功能機，和 iPhone 有不一樣的成本。
項目的業務人員/產品經理/產品負責人對于產品的需求，出因此決定了應用/產品的復雜度。諸如于，同樣是一個搜索功能，它有不同的實現方式：
- 普通模式。前端生成搜索的 URL，跳轉到對應的搜索結果頁。
- 標簽搜索 + 普通搜索。后端返回標簽
- AutoComplete + 普通搜索
- AutoComplete + 標簽搜索 + 普通搜索
- AutoComplete + 地圖搜索 + 標簽搜索 + 普通搜索。對了，還要有地圖和標簽的聯動。
- AutoComplete + 地圖搜索 + 標簽搜索 + 普通搜索 + 熱門搜索。
- ……
復雜度，決定了對于優秀前端工程師的需求。也因此在某種程度上，決定了前端的話語權。比如說，『出于設計上的需要，決定了后端應該這么做 xxxx』
也因此，諸如于騰訊這樣的產品型公司，前后端都沒有地垃。
但是，它避免了后端決定了前端需求的要素——這一點非常重要。在產品話語權不高的團隊，必然是先到先得的后端管理者，決定了整個產品的走向，也由后端決定了前端的設計。
二. 團隊規模，決定前端
只有組織內的前端團隊達到一定的規模，才能迫使組織的管理者意識到：『我們需要更優秀的前端開發，才能解決當前的瓶頸』。
按 xx 劃分：
- HTML 5 廣告頁
- 小型前端應用(微信小程序)
- 中型前端應用(普通的 Web 應用)
- 大型前端應用(toB)
按團隊規模來劃分：
- 頁面級
- 6 人團隊
- 兩個 Pizza 團隊級
- 組織級
所以，如果你只是在切圖，如果你只是在畫 HTML5
3. 流水線式開發
大型組織，需要更明確的分工，以便于機械工的生產更多的應用。
也因此需要更明確的分工，來解決效率的問題。
- 工具支撐團隊
- 框架開發團隊
- 業務開發團隊
- DevOps 團隊
4. 客戶端多樣式
在最近的幾年里，前端走向大前端的原因也在于此，對于多種客戶端開發的需求：微信小程度、桌面客戶端、跨平臺應用等等。使得一個個前端開發人員，身為多技。
作者手疼，省去了幾十個字。
5. 新的領域
嗯，只有新的領域，才存在更多的機會。
- 邊緣計算
- 區塊鏈
- 客戶端計算
- ……
作者手疼，省去了幾十個字。
6. 業務熟悉度
如果你不關心業務，對業務不了解，那么你哪來的自信，去領導整個前后端團隊。
作者手疼，省去了幾百個字。
結論
言而總之，總而言之：只有優秀的前端，才有必要討論地位。抱怨，解決不了問題——只有起而行動，才能有效地解決問題。
這些也意味著，我們需要更深入的學習。笑~ :)
可是，到底從哪里開始學呢?有沒有一本書，能解決這樣的問題。
TBC...
作者：Phodal(黃峰達)是一個咨詢師、Geek、作者和設計師，現作為一個資深咨詢師為 ThoughtWorks 工作。作為一個 Geek，他是一名狂熱的開源社區貢獻者，在 GitHub 上擁有大量的開源項目，擁有 40k+ 的 stars。作為一個*** markdown 印刷工，他是《自己動手設計物聯網》繁、簡體版、《全棧應用開發：精益實踐》作者等三本書的作者，并合譯有兩本物聯網相關書籍;并作為技術專家，審閱了七本英文技術書籍。
