回應 PTT Soft_Job 版
https://www.ptt.cc/bbs/Soft_Job/M.1557333152.A.BB7.html
嗨，台大學弟(妹)，我是 B96 與 R00 的資管系所學長，資管 vs 資工還是台大 vs 其他學校的選擇，一直都是戰點，只是沒想到畢業 N 年了竟然還在討論 (笑)，以下是我的建議，也歡迎私下交流討論。
台大資管 vs 台大資工硬實力？修課？升學？
根據歷史排行，台大資管一直都是排名在資工之後，台大資管最高曾到過全國二類組第 3，其餘大多是排在二類組 5~10 名左右，我個人覺得不用太擔心同儕競爭力問題啦，至少以我兩邊修課狀況成績位於班排差不多。然而看課程必修選修就知道，台大資管相對『他校』資管更吃重工程科目不少，如果資管都修得很高，不用擔心基礎理論部分。如果真的覺得要額外加強，也可以去跨修電資學院的課，像我就有上過機器學習 / 機率 / 線代 / NLP 等等課程，台大本身並沒有限制你一定要修什麼。至於升學部分，也有資管系同學後來申請電資相關系所(像電機系底下的資訊組/資工網媒所等)，說真的，有實力想去哪就去哪。
念資訊科系的必要性？非本科有差嗎？
我個人認為，如果一直考慮抵免學分或是最低畢業門檻學分，代表你都在盤算好不好轉系或好不好畢業，也代表比起技術本質，你更重視外在指標。事實上，我現在認識的一些新創界大神，有台大歷史系也有台大國企系材料系等，都不是本科生。我相信都可以念到台大了，聰明才智如基礎數理天賦會有一定水準，從哪裡畢業，只有新鮮人丟104找第一間工作有用而已，至於獵頭找人 / 新創界，幾乎都看自學實力跟經歷，除非，你要去 XX 輪班救台灣，(但資工資管沒差，XX 裡面一樣有超多台大資管，信不信)。
想不想出國？會想去矽谷嗎？
Y -> 建議去美國 UC 系列刷個學歷比較實在，台大學歷無用。念完書刷個 leetcode 找個 FAANG 實習，要怎樣都行，台灣純本土要去比較難要靠機緣。
N -> 在台灣出路，如果純 RD ，資工會比資管略優，但如果想當管理職或去新創團隊，我感受是資管系比資工系略優 (認真說，管院磨練比較容易跟 User 或跨部門溝通)。我在大學時間也覺得管理課程很廢很無聊，但後來發現開始參與經營公司後，那些知識又慢慢回來找我了，所以真的看個性，如同前面推文說的，不想跟別人互動或專攻特定領域的『純 RD』，我覺得念資工比較適合。
—
題外話，畢業之後，到了新創圈，跑了幾個地方，也到美國跑一下後，才覺得，學歷真的只是證明自己高中蠻認真/生下來蠻聰明而已(特別是會考試的部分)，出社會一陣子後也沒什麼好說嘴的，鬼混的人無論台大資工資管都大有人在。
過程中，你是怎樣去精進你的技術/溝通能力比較重要，(個人建議去台大車庫 / 報個創創學程 / 到大小公司實習)，不用侷限在選校/選系之分，等你出社會後就會知道了。
最後告訴你一個真相。
真正大神都是用學校以外的時間在練功的。
Facebook just announced the release of React v16.0.
New features
- fragments
- error boundaries
- portals
- custom DOM attributes
- improved server-side rendering
- small lib size
- better render perf (with react-fiber)
https://github.com/facebook/react/issues/10686v15
render functional component tree x 115,932 ops/sec ±4.10% (55 runs sampled)
render class based component tree x 255,407 ops/sec ±4.46% (58 runs sampled)
render class that renders functional components x 252,045 ops/sec ±5.47% (56 runs sampled)
Fastest is render class based component tree,render class that renders functional componentsv16
render functional component tree x 204,931 ops/sec ±2.21% (59 runs sampled)
render class based component tree x 339,215 ops/sec ±2.98% (58 runs sampled)
render class that renders functional components x 326,880 ops/sec ±4.51% (56 runs sampled)
Fastest is render class based component tree,render class that renders functional components
Install
Just update your package.json
No other configurations, and no migration issues :D
(It’s true !!!!!)
yarn add react react-domPratical performance (in chrome devtool)
v16
v15
You maybe also need to update (optional)
yarn add prop-types recompose reduxReference
本篇將會介紹 webpack 3 中常見的優化方式 包含問題分析，plugin介紹等等
優化成效
- 大部分的情境下，使用者用量(專案為內部使用者為主) 從 3.6 MB 降到 51 KB (app) 降為原本的 1.38 % (縮減 98.62 %)
- 在完全沒有 cache 機制，必須重拉 vendor 情況下 也是從 3.6 MB 降到 726 KB (app + vendor) 降為原本的 19.6 % (縮減 80.4 %)
優化流程
1. 觀察現有狀況與問題
僅使用 DefinePlugin(with production), UglifyJsPlugin(with minimize) bundle 出來的大小為 3.6MB, 存在很大改善空間(3G網路讀取時間過長) 因為不是所有 module 都在每次 build 都改動到
2. 利用 BundleAnalyzerPlugin 分析 bundle 成分
BundleAnalyzerPlugin 會協助解析 bundle 中有哪些單元 他會生成一個網頁，透過該網頁可以看到用到的 module 以及它的大小
3. 利用 CommonsChunkPlugin 抽出 lib
透過分析發現，第三方 lib 佔了大部分的成分(例如 react, rxjs, redux, moment, antd …etc) 但這些 lib 的改動(例如升級 react 版本)，在 production build cycle 中次數是很少的 因此透過 CommonsChunkPlugin 把所有第三方都抽出來，與我們自己的 code 分開 (例如產生出 app.js, vendor.js 這樣一來就每次只更新 app.js 即可)
ps: 也可以在 entry 中，指定那些比較大的 lib
4. Uglyify 優化
除了調整 minify, souceMap 外，compress選項也可以另外調整 (例如不要在生成支援 ie8 的 code, 去掉 dead code…
About
