Re: [請益] web前後端的選擇
我覺得你對 C10K 可能有誤解
以你文中的例子來說:
"據上個月vpon座談 如果我沒記錯 最複雜的子系統 qps約6000~7000左右吧?"
這並不代表他們的系統沒有達到 C10K 標準
C10K 的背後意義是什麼 ?
我的理解是硬體跟架構要恰當, 在合理的硬體條件下, Concurrent 數量要合理
並且隨著 clients 數量提升越來越高, 系統的資源花費不會離 Linear 差太遠
這跟後端背後的應用相當有關係, 我認真覺得後端一定要學好 C / C++
以及 Linux Kernel 背後一些重要參數的意義
後端要碰的坑可多了, 例如一個不太懂 Linux 的人, 即使寫出可以跑的程式
他可能也會在 scale 越來越大的時候碰到 ulimit 內的限制問題而不自知
然後就出包了, 還是在半夜出包, 等著收一堆客戶抱怨信
資深的因為踩過一堆坑, 就能在系統開發初期就預料到可能會碰上哪些問題
這些都是經驗累積而來的, 後端要做到很好難度確實比前端高不少, 要踩的坑太多
還沒踩到只是你還沒碰到而已 (也很可能跟際遇有關, 沒有合適的環境跟應用去踩坑)
就算想做前端, 最好也是要稍微摸一下後端, 不然後端對你來說只是黑盒子
身為一位 RD, 應該勇於解開所有黑盒子, 了解透徹, 減少自己未知的領域
※ 引述《stillboy (joey)》之銘言:
: 我自己full stack 對兩端都有粗淺的了解
: 但
: 看到這麼多前端的hater就覺得無奈QQ
: 你不懂前端 你要說啊! bro
: 客觀來說好了 台灣的後端??
: 除了幾家走出國際的大數據公司 or 本來就是國際大公司
: 有多少公司的後端達到C10K的等級? (新手不知道的 請自行Google)
: 據上個月vpon座談 如果我沒記錯 最複雜的子系統 qps約6000~7000左右吧?
: 如果連C10K都沒有的話 這種規模和複雜度就不要拿出來嘴惹
: 如果是大陸的一二線軟體公司的後端 C100K C1000K都有
: 這種後端 我舉雙腳和雙手贊成 如果是台灣的
: 台灣 除了少數的公司 其他去了 就算年資10年 最後還是領低薪
: 解決問題的scale就在那裡 ..你解決問題的等級多高 薪水就多高
: 領底薪也是合情合理
: 然後
: 順便釐清一下
: 真正的前端 跟 美術
: 一 點 關 係 都 沒 有
: 說有關係的 大概還停留在dreamweaver 和 fontpage的時代吧
: 或 所待個公司和產業 太過老舊.
: 在現代
: 美術和體驗的職位 叫做『UI/UX』 看公司大小 有些公司例如Google
: 會再細分 叫做 UX researcher 這種相關職等的人 會跟工程的人有許多討論。
: 前端在近10年來因為硬體日新月異 導致client端能做的事情變爆幹多
: 原本的架構是後端處理所有的事情 client端收到資料 顯示出來
: but 現在可能一個頁面有幾百個api的需求 加上行動裝置的出現
: 導致原本back-end request數量變超級大
: 比較爛的解法當然就是直接買更多機器 但成本會變很高
: 所以 有人想 既然前端硬體效能變好 那為啥不好好利用前端?
: 所以前後端分離出現了 也就是所謂的SPA 之後為了改善SEO and initial loading slow
: 的問題 又走到了 進階版的server-side rendering 但是 based on SPA.
: 走到這個SPA level之後 前端有自己的server 後端也有自己的server
: 因為這樣的配置 導致後端的工作量大為減少 而把這些工作量丟給client端
: 從而後端可以handle更多的工作量
: 所以為啥會看到 有些前端職位的需求要會redis node.js nginx
: but 這只適用於不需要太複雜的情況 複雜一點的情況的client server
: 還是需要考群以及分散式的需求 這樣的話 可能還是會由後端來處理。
: 而此時的前端基本上就變成應用程式軟體一樣
: 需要什麼資料跟後端要 要回來自己處理
: 同時也要效能 安全性 兼容性 design pattern 也是不容忽視的一環
: 所以說 為啥前端有些你看徵才文 薪水不比後端差
: 就是因為前端 早就不是以前的前端了
: 最後總結一下
: 走到極端的後端 VS 極端的前端
: 論複雜度 毫無疑問 後端屌打前端
: 但前提是 產品的scale要很大 (例如server的數量及至少至少要 > 50)
: 且 有很多real-time和巨量的數據的issues需要處理
: 這種架構以上都是分散式或微服務 跨區以上的等級
: 需要處理很多race condition/一致性/...等 複雜的問題
: 而一堆公司的後端常常會包含DBA 那就更複雜
: 如何取捨該功能是使用sql or nosql 並且對sql or nodql底層原理有通盤的了解
: 但台灣走到這種scale的軟體公司 屈指可數
: 所以如果要在台灣工作的話 選自己爽的比較重要
: 什麼叫做自己爽? 有些人天生喜歡面對client 喜歡面對畫面
: 有些人喜歡always面對程式碼 有些人喜歡自己寫一些web or app應用來玩
: 只要你在任何一端強的話 薪水早就不會是什麼大問題了
: 當然普遍來說 後端天花板會比較高
: 最後 不建議新手 走什麼full-stack拉
: full-stack 要顧 前後端 devops 然後五年後 全部都半桶水(半桶水其實是很高估)
: 很多事情欲速則不達 full-stack代表你要做的事情就是爆幹多
: 根本沒時間反芻 根本沒時間好好理解原理 基礎根基根本就不穩
: 比較好的path是你先走任何一端5~7年以上 再走任外一端5~7年以上
: 先把一端的基礎好好打好 念熟 到講一堆觀念 就像吃飯喝水一樣的解釋給旁人聽
: 當然一個最重要的前提是 你們公司做的產品是很有挑戰性的
: 所謂有挑戰性就是 後端至少朝C10K 甚至C100K走
: 前端 朝做tool走 而不是一直在那邊單純無腦刻畫面
: 而不是 product的 level一直在 0~1 1~10打轉
: 在這種有挑戰的公司各呆至少五年 我想 應該可以自稱 junior full-stack惹
: 看到一堆人 寫沒幾年 react+node.js+mongoDB就自稱full-stack
: 問他為什麼是node.js 為什麼mongoDB 也說不出個所以然
: 也是沒錯 大概是產品scale < 100 簡單應用的 full-stack . 也沒啥問題!
: 好拉 講太多惹 大概是這樣
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.93.30 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1576552011.A.5AE.html
推
12/17 12:43,
4年前
, 1F
12/17 12:43, 1F
→
12/17 14:49,
4年前
, 2F
12/17 14:49, 2F
→
12/17 14:49,
4年前
, 3F
12/17 14:49, 3F
→
12/17 14:50,
4年前
, 4F
12/17 14:50, 4F
通常前端的坑, 越補只是越被牽著鼻子走而已
因為太過於 high level, 反而容易變動
例如 IE / Edge / Android / iOS / react / .. 更新
你的某個 UI 元件就壞掉了, 然後你就勢必要 hotfix
hotfix 完了可能也一知半解
而後端的坑, 以 Linux 來說好了, 你碰到的坑會有大量的 source code 輔助
這些 source code 可以慢慢累積該有的經驗, 這種經驗不太容易因為時間變得沒用
簡而言之, 差異就在, 後端你可以越學越舉一反三, 學到的不容易過時
前端的東西沒幾年你可能就過時了 (幾年前哪來的 vue.js ?)
當你年紀越大, 越需要這種容易隨著年紀也帶著走的經驗
※ 編輯: kloer (1.160.93.30 臺灣), 12/17/2019 16:24:27
→
12/17 17:16,
4年前
, 5F
12/17 17:16, 5F
→
12/17 17:17,
4年前
, 6F
12/17 17:17, 6F
→
12/17 17:18,
4年前
, 7F
12/17 17:18, 7F
→
12/17 17:18,
4年前
, 8F
12/17 17:18, 8F
當然不會完全過時, 但是以會過時的比例來說, 前端是相當高的
10 年後誰敢保證 react / angular / vue 還佔有一席之地 ?
但是 10 年後蠻可以保證 C / C++ / Linux 還佔有一席之地
這兩者的信心程度是不同的, 容易過時的程度差太多
※ 編輯: kloer (1.160.93.30 臺灣), 12/17/2019 17:33:14
→
12/17 17:40,
4年前
, 9F
12/17 17:40, 9F
因為我玩的後端已經太靠近系統了, 幾乎不太需要而外引用絢麗的框架
所以我才會這樣比
當然後端也有些如 redis / memcached 之類
10 年後可能也有新東西出現, 但是差別在於
就算有新東西出現, 你用舊的東西也比較不會有過時的感覺
這種感覺有點難解釋, 除非架構與效能有極大差異
不然你都不會覺得這個老東西過時了, 還是用得很開心
反之前端可能就不同了
應該不少人還記得 Yahoo 以前風流一時的 YUI ?
現在拿來用也是可以用啦, 跑是能跑, 但是給外部的感覺就是另一回事了
※ 編輯: kloer (1.160.93.30 臺灣), 12/17/2019 17:50:18
推
12/17 19:10,
4年前
, 10F
12/17 19:10, 10F
推
12/17 22:59,
4年前
, 11F
12/17 22:59, 11F
推
12/18 08:27,
4年前
, 12F
12/18 08:27, 12F
推
12/18 12:34,
4年前
, 13F
12/18 12:34, 13F
推
12/18 14:40,
4年前
, 14F
12/18 14:40, 14F
推
12/18 18:57,
4年前
, 15F
12/18 18:57, 15F
→
12/18 19:31,
4年前
, 16F
12/18 19:31, 16F
→
12/18 20:59,
4年前
, 17F
12/18 20:59, 17F
推
12/18 21:57,
4年前
, 18F
12/18 21:57, 18F
→
12/19 00:46,
4年前
, 19F
12/19 00:46, 19F
跟什麼比什麼無關
我上面說了, 是我個人的後端玩得比較接近系統
根本無需要套用框架, 我才這樣比
或許你可以提出一下該什麼比什麼, 然後提個合理的理由為何要這樣比
重點其實也不在於後端比前端好, 而是兩者都應該碰
但是我會偏向推薦後端, 比重大概是 70% 後端 30% 前端
※ 編輯: kloer (1.160.91.182 臺灣), 12/19/2019 10:13:05
→
12/19 11:15,
4年前
, 20F
12/19 11:15, 20F
→
12/19 11:15,
4年前
, 21F
12/19 11:15, 21F
→
12/19 11:16,
4年前
, 22F
12/19 11:16, 22F
會提到框架原因是, 現代前端你不用流行的框架你就落伍了
偏偏這些流行的框架可能也不這麼持久
※ 編輯: kloer (1.160.91.182 臺灣), 12/19/2019 11:29:13
→
12/19 11:33,
4年前
, 23F
12/19 11:33, 23F
→
12/19 11:33,
4年前
, 24F
12/19 11:33, 24F
→
12/19 11:43,
4年前
, 25F
12/19 11:43, 25F
比的點不是這麼好我同意
我的點在於前端比後端更容易變化
所以我一律推薦後端比重要高一些
推
12/19 12:16,
4年前
, 26F
12/19 12:16, 26F
→
12/19 12:16,
4年前
, 27F
12/19 12:16, 27F
→
12/19 12:16,
4年前
, 28F
12/19 12:16, 28F
→
12/19 12:17,
4年前
, 29F
12/19 12:17, 29F
※ 編輯: kloer (1.160.91.182 臺灣), 12/19/2019 13:44:13
→
12/20 01:19,
4年前
, 30F
12/20 01:19, 30F
→
12/20 01:20,
4年前
, 31F
12/20 01:20, 31F
→
12/20 01:20,
4年前
, 32F
12/20 01:20, 32F
→
12/20 01:21,
4年前
, 33F
12/20 01:21, 33F
→
12/20 01:22,
4年前
, 34F
12/20 01:22, 34F
→
12/20 01:23,
4年前
, 35F
12/20 01:23, 35F
→
12/20 01:23,
4年前
, 36F
12/20 01:23, 36F
框架當然必須要用就該用
我的重點一直都不是該不該用框架
而是前端比後端變化快, 所以造成這些東西不容易累積
※ 編輯: kloer (1.160.91.182 臺灣), 12/20/2019 10:12:04
推
12/20 12:22,
4年前
, 37F
12/20 12:22, 37F
→
12/20 12:23,
4年前
, 38F
12/20 12:23, 38F
→
12/20 12:55,
4年前
, 39F
12/20 12:55, 39F
會有這種感覺是正常的, 不是容不進其他想法
而是網路上文字打打很難描述清楚真實的想法
描述不清的情況下就會有這種排斥性
A 覺得 B 說的錯, B 也覺得 A 說的錯
這是還好, 不要有太錯誤的東西都是可容忍的
※ 編輯: kloer (1.160.91.182 臺灣), 12/20/2019 13:45:06
推
12/22 12:36,
4年前
, 40F
12/22 12:36, 40F
→
12/22 13:04,
4年前
, 41F
12/22 13:04, 41F
→
01/07 18:58,
5年前
, 42F
01/07 18:58, 42F
→
01/07 18:59,
5年前
, 43F
01/07 18:59, 43F
→
01/07 19:00,
5年前
, 44F
01/07 19:00, 44F
→
01/07 19:00,
5年前
, 45F
01/07 19:00, 45F
→
01/07 19:01,
5年前
, 46F
01/07 19:01, 46F
→
01/07 19:02,
5年前
, 47F
01/07 19:02, 47F
討論串 (同標題文章)
本文引述了以下文章的的內容:
請益
45
93
完整討論串 (本文為第 4 之 10 篇):
請益
11
49
請益
45
93
請益
4
22
請益
11
47
請益
15
99
請益
7
20
請益
13
42