※ 引述《Jokering5566 (揪客56)》之銘言：
: 小弟之前看到一篇文章，大意在講說台灣的軟體工程師大部分都只是在做CRUD的事情
: 這也跟我目前上班的心得差不多。
: 我開始後端工程師的工作也不到1年，大部分的時間就是依照以前留下來的框架寫法
: 串接資料庫資料到前端，而前端畫面是別人負責就是。
: 感覺到這樣的事情似乎在職涯競爭力上非常的薄弱，
: 這種一個隨便剛畢業的人就能勝任的工作，公司也不可能開高薪吧，
: 甚至中年失業都有可能。
: 這樣後端工程師該如何提升自己的能力呢
: 精進不同框架的使用不太可能，產品一開始就規劃好了使用框架，要整個翻掉很少遇到
: 往前端發展，我認識前端畫面做得好的幾乎都有美術底子，往前端跳又不太明智
: 不曉得各位後端工程師有什麼想法嗎?
有趣的問題，來一些激盪吧～
Q: 你怎麼知道 CRUD 分別吃多少系統資源？需要多少 IOPS / CPU?
Q: 承上，要如何知道 CURD 吃了哪些資源？
Q: 承上，怎麼解開這些資源的分配問題？
Q: 1 個連線的 CRUD、10 個連線的 CRUD、100 個的 CRUD ..... 類推，
他們的架構是怎樣？
Q: CRUD 的對象是 RDBMS? NoSQL? Block Storage? Cache? Buffer?
Q: 承上: CRUD 的對象怎麼選？我只會 MySQL 啦，都往裡面塞就是了 .....
Q: 前端怎麼知道 CRUD 瓶頸在哪？
Q: CRUD 的操作對象，不管是 RDBMS, NoSQL, Storage, Cache，
瞬間流量衝進來怎麼處理？會遇到什麼問題？
Q: 線上的系統 CRUD 出問題了，怎麼知道哪裡出問題？
Q: 當現有的架構要拆分的時候 (microservices)，你的 CRUD 還是 CRUD?
Q: 當系統是分散式的時候，CRUD ... 要怎麼辦？
Q: 你的 CRUD 考慮的是 ACID or BASE? 還是這啥？
Q: 寫十年的 CRUD 然後都做一樣的事情？那中年一定失業。
但是可以處理瞬間百萬 qps 的 CRUD，你中年一定很忙。
下一系列的 Q
Q: 哪裡有百萬 qps 的系統啊？qps 是啥？
Q: 當有的時候，你準備好了嗎？
Q: 台灣沒有百萬的 qps 啊，國外有，你準備好了嗎？
Q: golang 很屌，可處理百萬 qps，是這樣？node.js 不行？C# 不行？
Q: 買一台 2048 core 的機器就可以搞定了，需要說那麼多嗎？ .....
....