【為什麼我們要挑選這篇文章】Shell 在 GitHub 排行榜「機器學習領域最熱門的程式語言」中排名第七，熱門程度可想而知。不過多人使用不代表程式語言沒有罩門，本文作者統整了四個可以加速 Shell 作業效率的技巧，好用的功能懶人包你能不存下來嗎？（責任編輯：陳伯安）

本文經 AI 新媒體量子位（公眾號 ID：QbitAI）授權轉載，轉載請聯繫出處

作者：量子位／曉查

在機器學習的實踐過程中，用好 Shell  能幫你很多節省時間。

最近，有位來自 ETHZ  的學生分享了一些 Shell  小技巧。對工程師來說，這些技巧更重要的是讓你的思維從瑣碎小事中解脫出來，大大提高了工作效率。

下面就是他分享的 4  個 tips。由於本文中涉及到的 shell  腳本過多，你可以去文末地址中查看所有腳本的程式碼。

在千萬文件中，快速抓到你要的那個

當你在遠程服務器上監視程式運行時，如果想把一個遠程文件抓取來查看，通常你會怎麼做？

記下文件路徑，打開終端，用 rsync  之類的工具同步到本地，再到文件瀏覽器中查看。

實際上不必這麼麻煩。只需要事先寫好幾個 shell  腳本，就可以避免重複的機械勞動。

在這裡強烈推薦 iTerm 2，它比 Mac  自帶的終端要強大得多，可以指定某個觸發關鍵詞執行某個相應的命令。

iTerm 2 傳送門，點這 。

先在遠程服務器上設置一個腳本 t 。當我們輸入 r awesome_video.mp4 時，它會搜索 awesome_video.mp4  文件所在路徑，並連同主機名以字符串 rtransfer <host> <path>  的形式列印出來。

rtransfer  作為 iTerm2  的觸發關鍵詞，解析出主機和路徑，然後調用另一個本地腳本 t2。腳本 t2  將這個影片文件傳輸到臨時目錄，然後在該目錄中打開 Finder。

使用 iTerm 2  觸發關鍵詞功能調用腳本，可以大大提升效率，而你要做的只是在前期花費時間定制腳本。

遠端訪問 TensorBoard

除了抓取遠程文件，另一個讓人痛苦的是訪問遠程服務器上的 TensorBoard  實例。你可以設置 SSH  端口轉發，但是哪個端口對應哪個服務器？它們都在 Docker  容器中。

ngrok可以讓你把訪問本地端口變成訪問 URL ，比如輸入 ngrok http 6006 後，它會為你生成一個 URL  網址 ，你可以在 這個網址 中查看 TensorBoard  實例。

結合腳本 n，以更快的速度啓動 ngrok，然後用腳本 tb  打開 Web  瀏覽器，啓動 TensorBoard，在十秒內就能從運行目錄轉到顯示圖形。

ngrok  有個缺點是它一次只能允許一個對話筐，因此在使用前需要刪除上一個 ngork 程式 。如果你忘記在另外一台服務器上刪除 ngrok，可能會比較麻煩。

ngrok下載地址， 點這 。

用  tbplot 代替  TensorBoard 繪圖

對於運行大量 metrics  的情形，我們需要等待較長時間讓 TensorBoard  加載所有圖形。如果使用 tbplot  腳本，速度會快很多，並且能直接生成圖像文件。

tbplot  實際上調用的是 Matplotlib，缺點是目前只能生成標量圖。

tbplot下載地址： 點這 。

自動監測程式會不會讓電腦停機

運行程式碼時，最耗費精力的事情就是是擔心遇到了錯誤並停機，因此需要不斷檢查他們的運行情況。

當程式出現問題時，通過警報自動監控可以緩解這種擔憂。一般可以把警報發送到郵箱中，為了避免這麼麻煩，可以使用 sqs-alerts，它依靠 AWS AWS Simple Queue  服務存儲和接收消息。

在每台遠程機器上，使用 cron  運行一個腳本，監控日誌並在檢測到運行中斷時向隊列發送消息。然後在本地機器上運行一個服務來監控隊列，並在收到消息時彈出警報。

sqs-alerts下載地址： 點這 。

最後，本文使用的所有 shell 腳本都可以在以下地址中找到： 點這 。

（本文經 AI 新媒體 量子位 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈4 个 Shell 小技巧，帮你提高机器学习生产效率 〉，首圖來源：Pxhere, CC Licensed。）

你可能感興趣

GitHub 神人整理出一份 Python 開源清單：15 個領域、181 個開源項目任你用

Python 早就落伍了！AI 權威 LeCun 直言：深度學習需要更靈活的程式語言

最新「數據科學」自學清單：六個月無師自通，菜鳥新手趕快存起來

【為什麼我們要挑選這篇文章】有人想當數據科學家，積極學習各種程式與演算法並取得證照，求職卻一直碰壁，於是寄信詢問一位在 YC 新創公司工作的物理學家的意見。那位物理學家看完他的經歷後，點出了兩個盲點……

這兩個盲點不只是應徵數據科學家需要注意，只要想當工程師，都要以此為鑑。（責任編輯：郭家宏）

或許你在慕課或者 courses 上面學習了許多的數據科學課程，又或許你看了許多這方面的書。

你很努力，但是卻拿不到一份相關的 offer。你很苦惱，你一直在猜想自己是不是不夠聰明，猜想是否是自己的學歷的原因，無法在求職路上提供幫助。

其實，事情遠遠沒那麼簡單。

Edouard Harris，一名在 YC 新創公司工作的物理學家，由於工作的關係，他收到了很多有關數據科學職業建議的郵件。下面他將從一封郵件談起，告訴你一些罕為人知的數據科學求職經驗。

以下是原文請欣賞！

為什麼一直拿不到數據科學 offer？

這是那封我收到的郵件，為保護當事人，內容有所增減：

發件人：Lonnie（化名）
主題：努力找數據科學方面的工作

我是大學輟學者（我之所以這麼開始，是因為如果你出生時沒有一個理論物理學博士學位以及長達 15 年的數據科學經驗，那麼一定是你的出生方式不對，作者想表達的意思是，每個求職者都在找工作時都困難重重）。

[…] 在我仔細研究了整個工作市場之後，我發現最喜歡數據方面的工作。我努力學習 A/B 測試方面的知識，並在 Google Analytics 中以及 Optimizely 的測試平台上獲得了它們的認證。然後我開始接觸和學習 Python、SQL 等。從某著名數據科學訓練營結課以後，我就開始極力地尋求求職面試的機會。我發出了 100 多份申請，但是幾乎沒有收到面試通知。

為了保持不斷學習和提升技能的狀態，我一直在 Udacity NanoDegree 和 Dataquest.io 報課學習。

我認為我的致命問題在於缺乏學術履歷，而不是工作技能的問題（雖然我確實需要提高各項技能，並且正在這樣做）。我認為學歷是短板，是因為我甚至都沒有面試機會來展示我的技能。

我在 A 公司有一次面試的機會，那是我第一次當場編寫代碼和在白板上寫偽代碼，自然很不順利。

除此之外，我還面過一個可以帶回家做的面試程式題，那是關於 xxx，一個大的新創公司的生存分析面試題，但之前我從來沒有研究過生存分析，所以也做得不好。

我之後面過另一個大公司 B，我順利通過了他們的第一面 —— 程式測試，但去公司進行第二面時，因為學歷沒有讓我通過。（這讓人很無語，因為他們其實有我的履歷）。

原因一：你用錯求職平台了

Lonnie，謝謝你的來信。

事實是：根據你申請工作的情況來看， 2~3% 的面試機率可能是正常的，有兩個你無論如何都想不到的原因。

第一個原因是，大多數招聘團隊使用一個稱之為 申請人追蹤系統 的東西來告訴他們最佳候選人的來源。 如果你透過一個過去反映不佳的管道申請，他們會花更少的時間看你的履歷和申請材料 ，因此你被選入面試名單的機率也更小。

例如，如果你通過 Indeed（求職平台）申請技術類的工作，非常有可能會失敗。每個人都知道 Indeed，這是一種很容易的申請工作的方式。這就意味著，大多數透過 Indeed 申請工作的人很可能是非常普通的人（台灣的話可能就是數字人力銀行）。因此，招聘經理會花更少的時間查看來自 Indeed 的履歷，因為她的預期就是 Indeed 上的應聘者就是普通的的。

您可以透過在大多數人還不知道的網站申請工作，來解決這個問題。Key Values 和 Y Combinator 的 Work At A Startup 都是不錯的求職網站。透過使用大多數人還不知道的網站，你將自己標記為有意主動積極尋找機會的人。在這些網站上申請工作的人最有可能高於平均求職者的水平，所以，公司對他們更感興趣。

原因二：不是每個 HR 都會辨識工程師人才

從類似於 Indeed 這些網站申請工作成功率低的第二個原因，你可能很難相信這一點，實際上，許多求職網站上的公司（尤其是大公司）並不是要透過它來找到他們想僱用的人。

這聽起來很瘋狂：為什麼他們還會在求職網站上發佈消息呢？你需要知道的是，在大多數大公司內部，人力資源團隊（HR）和招聘部門（例如工程師）之間存在著非常大的的分歧。通常，其實是 HR 在 Indeed 上發佈招聘信息。

不幸的是，人力資源部門裡面並沒有工程師，所以他們無法很好地辨別哪些候選人真正有能力，哪些人沒有。HR 只知道如何篩選履歷，也就是說，他們會看你是否來自一所好學校（比如史丹佛）或以前在一家大公司工作（比如 Google）。

這就是你的命中率為 2~3% 的殘酷真相：HR 無法辨別好、壞訓練營之間的區別。所以他們只好默認說所有的訓練營都是「壞」的，因為他們不想浪費工程團隊的時間來辨別可能不是很好的訓練營畢業生。這種事我見過很多次了。

幸運的是：大多數工程團隊都知道他們的 HR 無法篩選出合適的人選。因此，最好的工程團隊會透過他們自己的人際網絡和管道來招人，而不是通過求職網站。而我給你的最好的建議是： 多參加工程師舉辦的機器學習聚會 。這沒什麼難度：只需要去 meetup.com 網站，找到看起來不錯的聚會，然後去參加就行了。

你很快就會發現哪些活動有價值，哪些沒有。拓展你的人際關係網絡是有很多益處的，提出聰明的問題，嘗試進行有益的對話，就一定會在聊天時聽到「我們正在招募」的消息。

提升面試技巧的最好方法：多參加面試

簡單地說：求職面試是一種殘酷的，神秘的儀式。每個公司的流程都不一樣，並且每家公司都認為它的面試才是真正的面試。

有很多方法可以在面試中表現得更好，但最好的方法是多參加面試。所以我讓你參加聚會的建議也會幫助到你：面試得越多，你就會越好。 即使你毀了第一個，你也會像掌握其他技能那樣，在日後參加面試的經歷中慢慢學會如何面試。

最後，我很遺憾求職系統被如此對待。我知道這對職場新手來說特別難，也不公平。但是寶劍鋒從磨礪出：在你有 1 到 2 年的經驗後，那些公司會搶著要你。苦心人，天不負。

原文請參照此 連結

（本文經 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈 嘘！这有几条没人会告诉你的数据科学求职秘密 〉 。首圖來源：Wikimedia Commons）

更多工程師求職消息

求職市場最搶手的 5 個程式語言技能，Python、Java 居然都沒上榜！

年後求職履歷寫起來！LinkedIn 公布 2019「十大硬技能」與「五大軟實力」

找工作半年沒著落！交大碩士求職碰壁，苦喊學歷無用

【為什麼我們要挑選這篇文章】科技變化快速，因此科技業（特別是網路、軟體業）有個現象，就是偏好年輕的工程師。在矽谷，工程師平均年齡大約只有 30 歲；很多年長的工程師，雖然經驗資深，卻被認為無法跟上最新的科技趨勢而被「嫌棄」。

當然也是有不少公司重視資深年長的工程師，但如果你決定要以工程師作為人生志業，除了持續學習新知，跟上科技趨勢之外，也要知道如何規劃自己的職涯，以避免被淘汰。下文，是作者給工程師們的職涯策略建議。（責任編輯：郭家宏）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

在紐約，PyGotham 每年召開之際，都會有超過 600 名工程師聚集在一起討論工作。

為了讓會議更加多元化，組織者儘量邀請一些女性工程師以及各種膚色的工程師。

但是，本文作者 A.Jesse Jiryu Davis（MongoDB 的軟體工程師）發現會議似乎忽略了「年長工程師」這一團體。

那麼，老工程師都去哪了？他們去了大學教書，還是成為了管理人員。

以下是作者的調查結果，請欣賞。

缺愛的群體：老工程師

每年都會有 600 名工程師聚集在紐約一個名為 PyGotham 的會議上討論工作。由於科技行業以男性為主，因此組織者特別努力地招募了多元化的演講者陣容。他們給女性工程師發郵件告知這個活動，並為業內女性舉辦研討會，鼓勵她們發表言論。組織者要求發言人填寫人口統計調查，以便他們跟蹤會議多樣性的進展情況。

我在會議委員會任職，在今年的 PyGotham 會議結束之後，我意識到我忽視了一個群體：老工程師們。與女性相比，四十歲以上的工程師的缺乏現象大多都沒有引起注意。在紐約沒有針對他們的聚會或郵件列表，也沒有專門針對他們的知名倡導組織。雖然我會尋找年長的工程師明年在 PyGotham 發言，但我還不知道從哪裡找起。

軟體業非常年輕。谷歌和亞馬遜員工的平均年齡為 30 歲，而美國工人的平均年齡為 42 歲。2018 年 Stack Overflow 對全球 100,000 名工程師的一項調查發現，其中四分之三的人未滿 35 歲。黑客新聞總會有定期發佈的帖子問到：「老開發者會怎麼樣？」。30 多歲的焦慮開發人員會跟帖並稱自己為「老年人」。

我今年 10 月滿 40 歲，在紐約一家名為 MongoDB 的數據庫公司工作了 7 年。我這個年紀的許多工程師已經轉行到學校任職，或者成為經理。作為一名工程師，我付出一生，但我未來幾十年的職業道路並沒有因此而變得明朗。而且可供參考的比我年長的工程師的經驗很少。那些老工程師們都去了哪裡，我們這些留下來的人的職業前景又如何呢？

2007 年，22 歲的馬克．祖克伯大聲說出了許多軟體業人士的想法：「年輕人才更聰明。」12 年後，與其他多樣性的研究相比，缺乏老工程師的問題仍然很少被研究。

例如，谷歌的年度多元化報告統計了它僱傭的女性或有色人種數量。微軟統計美國印第安人和阿拉斯加原住民的工作人員人數，蘋果公司以能僱用退伍軍人為傲。值得稱讚的是，這些公司已經披露了一些多樣性的衡量標準，但有一個遺漏：沒有人報告他們公司的年齡分佈。

老工程師辭職原因：「被嫌棄」

Ari Rapkin Blenkhorn 是一名 47 歲的工程師，她說她辭去了上一份全職工作，因為該公司想要「一群廉價的年輕人」。他們不想僱傭擁有更多職業背景的資深人士。「她沒有透露僱主的名字，但稱她的僱主重視她的職業人脈，但不派她參加會議，即僱主並不在她身上投資。」「我相信他們真的不明白為什麼這很重要，以及讓我參加研究會議與初級開發人員參加有什麼不同。」

Blenkhorn 說，一旦她回到就業市場，她所經歷的年齡歧視就會因性別歧視而變得更加複雜。儘管她具有資深的技術能力，但作為一名「媽媽」，在招募人員眼裡，她顯得既不重要又遲鈍。她最近獲得了電腦科學博士學位，並希望學歷能提高她在就業市場的機會。

55 歲的工程師 Kevin Stevens 六年前在申請 Stack Exchange 的工作時，也經歷了類似的態度。他由一位年輕工程師面試，那個年輕人告訴他，「我對年長的工程師能否跟得上技術感到懷疑。」Stevens 因此而被拒絶。他現在是一家酒店公司的工程師，他說在這裡他的年齡不再是問題。

對於其他工程師來說，結果可能會更糟糕。ProPublica 公司的 Peter Gosselin 和 Ariana Tobin 在 2018 年對 IBM 的年齡歧視進行的調查發現，從 2014 年左右開始， IBM 試圖透過用年輕人取代年長者人來實現人員更新。

IBM 解僱了成千上萬的有經驗的員工。一位名叫 Ed Kishkill 的 60 歲系統工程師收到了一份裁員通知，並告訴他有三個月的時間在 IBM 找到另一份工作。儘管他有數十年的經驗，但他被其他所有職位拒絶。截止至 ProPublica 文章發表時，Kishkill 正在 Staples 商店做營業員。

工程師永遠在學習新技能

終身工程師必須保持他們的技能是最新的，但這其實是在不斷變革的行業中與時間賽跑。根據 2018 年的一篇研究論文所說，科學、技術、工程和數學（science, technology, engineering, and mathematics，統稱 STEM）工作的技能變化比其他行業更快，而工程師面臨的變化率尤為嚴重。

該報告的作者之一 Kadeem L. Noray 表示，「STEM 比其他領域更注重技能」，與持久的智慧相比，更重視短期能力。每當 STEM 專業人員學習一項新技能，都有另一項技能已經過時，這也就導致從業者幾乎沒有機會積累技能和增加工資。

儘管科技行業的起薪很高，但與其他行業相比，這些優勢在就業的前十年裡減少了一半。「大多數經濟學家都不知道這一點」，Noray 說道。Hired.com 網站 2017 年的一份報告指出，50 歲以上的技術人員的薪資待遇實際上比年輕人要低。因此，許多 STEM 工作者會為了尋求持續的薪資增長，轉而從事變化更慢的職業。在 24 歲的時候，STEM 專業人員中的 89% 從事與 STEM 相關工作，但到了 35 歲的時候，這個數字下降到 71% ，並且還會繼續下降。

有一個方法可以讓工程師擺脫不斷更新的「技術輪迴」而又能留在這個行業，那就是成為管理人員。馬薩諸塞州一位 54 歲的工程師告訴我，「我的公司為新人提供了清晰的職業路線：他們以開發人員的身份進入公司，然後逐漸晉陞到管理層。」

老工程師晉升之路：成為管理者

但並不是所有人都適合做管理工作。MongoDB 的一位 54 歲高級工程師 Sue LoVerso 說道，「管理者需要具備某些性格特徵，但我是一個內向的人，解決技術問題才是我的興趣所在。」一位 63 歲的谷歌的工程師表示，他的一段短暫的管理者經歷讓他感到不舒服：「我知道我可以依靠自己完成一項工作，但我不知道如何依靠其他人。」

谷歌，微軟和其他大公司定義了「個人貢獻者（individual contributor, IC）路線」，作為管理路線的替代選擇，這是高級工程師的職銜劃分，與管理職銜相平行。IC 路線讓工程師可以在不放棄他們熱愛的行業的情況下，獲得更高的職位。

但 IC 路線也存在弊端。不少工程師告訴我說，IC 路線上的晉升速度比較慢，而且職稱之間的區別也很模糊。現年 45 歲的 MongoDB 工程師 David Golden 表示：「在只做開發的路線上，要進入下一個級別面臨著更大的障礙。你甚至弄不清楚如何從這個級別到那個級別，也不清楚你是否真的能對此做些什麼。」

根據對這些工程師的採訪，我意識到，公司應該為最資深的個人貢獻者創造不同性質的職位。和遴選管理人員一樣，我們應根據以往的工作效率，而非快速變化的技能清單，來評定這些職位的候選人。使這個過程更加清晰意味著工程師們可以更快地往上爬，而在每個級別獲得的聲望和迎來的智力挑戰將使工程師在五六十歲時依然保持活力。

經驗豐富的工程師應該被放在合適的位置上，以解決最關鍵的項目中最棘手的問題。他們應該透過寫作，演講和指導來凸顯技術領導力的作用。

由於有著深厚的知識和豐富的經驗，年長的工程師能夠用普通的術語傳達自己的知識，從而充當非程式世界的「大使」。Ari Blenkhorn 在特效工作室 Industrial Light and Magic 領導一個布料模擬項目時，就充當了這一角色。

她說道：「尤達大師（源自星球大戰電影系列人物）的長袍，哈利波特的魁地奇斗篷，攝魂怪的長袍（源自《哈利波特》小說系列人物）——我幫助開發的軟體裡包括所有這些東西。我需要同時講物理模擬研究團隊和動畫團隊的溝通語言。他們不考慮偏微分方程；他們想到的是這些絲滑的、有彈性的布料，以及其隨風漾起的波紋。」

我很幸運：我的公司對我在職業生涯中期表現出的倦怠充滿同理心，並允許我踏上了一次職業探索之旅。今年，我將在三個團隊中輪流待幾個月，在此期間好好規劃一下未來。

其他公司可能就沒有這麼慷慨了。我特別擔心這個行業中的年齡、性別以及種族歧視。公司必須為在 IC 路線上前進的工程師定義有意義的級別。與此同時，工程師應該更積極主動，組織起來並向公司施加壓力，以消除年齡偏見。工會可以規範工資標準，保護高年級員工免於被裁；這樣做也可能會縮小在種族和性別上的工資差距。

讓軟體行業對 30 歲以上的工程師更加開放，並為經驗豐富的工程師創造合適的職位，這將使公司更有效，更公平。這些變化也將使我們其他人受益 — 在一個日益受到軟體和演算法控制的社會中，工程師必須更具智慧以駕馭他們的力量。

他們必須從最近的黑客行為，有偏見的演算法和網路煽動種族滅絶的事件中吸取教訓。這樣做的唯一方法是讓年長的工程師留在行業中足夠長的時間，以便把他們的知識傳授給他們的繼任者。培養終身程式人員可以確保今天學到的經驗教訓在 50 年後仍能被記住。

原文 出處

（本文經 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈 老程序员都去哪了？〉 。首圖來源：Pixabay CC Licensed）

工程師該具備的認知

總是懷疑自己能力不夠？58% 的工程師有這個症狀：冒名頂替症候群

機器學習成效開到最大！介紹 4 個超好用的 Shell 程式技巧

求職市場最搶手的 5 個程式語言技能，Python、Java 居然都沒上榜！

【為什麼我們要挑選這篇文章】很多想當工程師的人都會學程式，但只會程式的工程師只能當碼農，負責調整既有的程式碼、維護系統等等。若要更上一層樓，工程師需要熟悉演算法和資料結構，它們是程式背後的邏輯思考架構。下文作者要跟工程師分享 3 個重要的資料結構。（責任編輯：郭家宏）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

又要面試啦！

工程師面試時該表現什麼？當然是你淵博的電腦知識，以及聰明的腦袋瓜。

如果你學富五車，上知深度學習，下知財務會計，那短短幾小時也絶不夠你表演。所以，你一定得知道面試官的套路，隨口丟出幾個應景的「冷知識」。

如果你基礎不行，三天前才練了幾條程式碼，那就更得準備幾個小把戲，不用打腫臉也能充個胖子。

基於這兩個需求，今天文摘菌（本文作者）就來介紹三個資料結構，讓你撐撐面試場面。

這三個資料結構就是：

1. 布隆過濾器（bloom filter）
2. 前綴樹（prefix trie）
3. 環形緩衝區（ring buffer）

先來說一下，為什麼挑這三個資料結構。

首先我覺得，你提到的資料結構要稍微冷門一些，這樣別人就會認為你瞭解很多不同類型的資料結構。但它不能太冷門，以免你的面試官要求你真正解釋實現細節或原理，那時你就 game over 了。最好是你提到的資料結構有點冷門，但你的面試官聽說過，對它有印象。

面試官都希望自己什麼都知道，他們聽說過這種資料結構但又不太瞭解，當你向他們介紹時，他們就會覺得你懂得特別多。

除此之外，這些資料結構還應該具有實際用例，以便在技術面試的時候，你能有機會展開介紹。它雖然稍微有點冷門但也不能太 low，你如果只知道一些菜鳥水平的資料結構（比如雙向連結串列），你的面試就掰了。

所以，這三個資料結構就被完美選中啦！

布隆過濾器（bloom filter）

布隆過濾器是集合的機率版本。檢測集合是否包含某元素的時間複雜度為 O(1)、空間複雜度為 O(N)。Bloom 過濾器也可以檢測出集合是否可能包含該元素，它的時間複雜度為 O(1)，而空間複雜度只需要 O(1)！

誰會真正使用布隆過濾器？

Chrome 需要在不犧牲速度或空間的情況下保護你免受訪問垃圾郵件網站。

想像一下，如果每次你點擊一個連結，Chrome 都必須進行網絡通話來檢查它龐大的垃圾郵件 URL 資料庫，然後才允許你訪問這個頁面，這會不會讓你等瘋掉。此外，設想一下，如果 Chrome 改善延遲的解決方案是在本地儲存整個垃圾郵件 URL 列表，這根本就是不可行的！

所以，chrome 在本地儲存了一個潛在垃圾郵件 URL 的布隆過濾器，這既節省時間又節省空間，可以快速檢查給定的 URL 是否為垃圾郵件。對於普通的 URL，布隆過濾器對「非垃圾郵件」的響應就足夠判定了。如果一個 URL 被標記為「可能是垃圾郵件」，那麼 Google 可以在跳轉之前檢查它真實資料庫。事實證明，當你願意犧牲絶對時，你可以做出偉大的事情！

布隆過濾器的原理

布隆過濾器的維基百科頁用大量的術語描述了實現細節，所以在這裡我會用簡單的描述一下實現過程。如果你想要更精確的細節，你應該去看看維基百科。我會略過很多步驟，但我會讓你有一個大致瞭解。

如果你想在 Bloom 過濾器中插入一個元素，首先假設有 N 個不同的確定性雜湊函式（Hash function）。當同一個元素輸入不同雜湊函式時，會得到不同的值（衝突是可以有的）。

使用每個雜湊函式的輸出作為數組的索引 [註釋 1，註釋 2]，並對應每個索引 i 將數組 [i] 設置為 true。插入元素就完成了！插入元素的時間複雜度是 O(1)，因為對每個插入元素所做的唯一工作是運行恆定數量的雜湊函式，並設置恆定數量的數組索引。

那該如何檢查布隆過濾器是否包含該元素？ 再次運行所有相同的雜湊函式！

雜湊函式是確定性的，因此相同的輸入應返回相同的輸出。所以相對應每個索引，檢查布隆過濾器的數組是否在該索引處設置為 true 即可。如果雜湊函式輸出的數組的每個單元都為真，那麼可以很高的機率說這個元素已經插入到了布隆過濾器中。這一方法總是存在誤報的可能性。不過，布隆過濾器的一大特色是永遠不會出現漏報。

那麼，你需要多少個雜湊函式，又需要多大的數組呢？這你就得好好算一番了。維基百科對它們的解釋更詳細，你值得一讀。

註釋 1：如何使用雜湊函式的輸出作為索引：設雜湊函式輸出整數值 M，取長度 N。N%M（N mod M）得到一個值 Q，即 0≤Q<M。這是一種取任意值並在一個範圍內均勻分佈的簡便方法。如果你以前沒有遇到過這個問題，那麼應該閲讀關於 mod 運算符的內容，繪製一些示例數組，並使用 M 的不同值進行實驗，以瞭解 N%M 的效果。

註釋 2：實際上，你應該使用位數組而不是普通數組。數組的每個元素至少需要 1 個位元組，而你只需要為「數組」的每個元素存儲 true / false。因此，你可以透過將其儲存為位數組來節省空間，這是這個資料結構的重點。如果你想要聽起來很聰明，那麼位數組（也就是位向量）也值得你在面試時提出。

註釋 3：嚴格來說，如果你的所有雜湊函式都在 O（1）時間內運行，那麼插入的複雜度才是 O（1）。

前綴樹（prefix trie）

前綴樹是一種資料結構，允許你透過其首碼快速查找字元串，還可以查找有公共首碼的字元串。

我對介紹這一資料結構的第一條建議是，將它稱為「前綴樹」，而不僅僅是「樹」。這樣，你就讓面試官知道你是那種了解與首碼和尾碼相關演算法的人，並且你也希望對你的 fancy 資料結構進行準確描述。後綴樹也是一個非常有趣的話題，但實現細節十分殘暴。這就是為什麼我只是談論前綴樹，並且假裝瞭解後綴樹。

誰會真的用前綴樹？

基因組學研究人員！

事實證明，現代基因組研究在很大程度上依賴於字元串算法和資料結構，因為你試圖從組成基因組序列的數百萬個核苷酸中探索奧秘。對於基因組數據，你經常需要對齊序列，找到差異或找到重複的模式。如果你想瞭解更多相關信息，可以先閲讀生物訊息學讀物，然後參與「DNA 測序演算法」或「生物訊息學演算法」等課程。

如果你想要閲讀一些真正有意思的讀物，我強烈建議你讀一讀藥物基因組學。隨著基因組測序和字元串演算法的進步，我們實際上可以預測使用個體的基因組，來確定它們是否具有對藥物正確反應的正確基因。例如，如果他們的基因組缺少用於產生處理某種藥物的酶的基因，那麼藥物可能會對他們產生副作用。如果我們知道什麼基因是重要的，我們可以給他們一種不同的藥物！

我承認，前綴樹和基因組學之間的聯繫不太緊密。其實前綴樹的最直接用法就是用來查字典啦！但只講字典有點太無聊了。

前綴樹的原理

想像一下，你有一棵樹，每個節點都有一個包含 26 個子節點的數組，每個子節點對應一個英文字母。（如果要包含其他字元，可以將 26 更改為不同的值。）要在你的樹中表示單詞，你將從根節點開始，沿著路徑向下走，並在每個節點添加一個字母。

例如於「tea」這個詞，你從根開始，被引導到 t 節點，然後是 e，最後是 a。因此，搜尋單字需要 O（N）的時間（其中 N 是單字的長度），如果單字的首碼不存在，則可以提前結束。如果我查詢「zzzzzzzz」，樹可以在「zz」之後結束查詢。

環形緩衝區（ring buffer）

環形緩衝區是使用普通數組的一種非常好的方式，它主要被用於處理數據流。

誰會使用環形緩衝區？

說不定 Netflix 會用？

我用 Google 搜尋「Netflix ring buffer」，發現了他們發佈了一些開源環緩衝區代碼。但問題是，公司真的會用他們已經開源的代碼嗎？

環形緩衝區的原理

好啦好啦。真的還有人在讀這篇文章嘛。

如果你讀到了這兒，說明你基礎一定還不錯，那就直接去維基百科看一下這個資料結構吧，比前兩個簡單多了！

總結一下，今天文摘菌介紹了三個重要的資料結構：布隆過濾器（bloom filter），前綴樹（prefix trie），環形緩衝區（ring buffer）。

想當一個聰明工程師，這些結構知識值得你熟記！

原文 傳送門

（本文經 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈想伪装成资深程序员？知道这三个数据结构就够了 〉 。首圖來源：Wikipedia Commons）

更多工程師技能大補帖

程式、演算法差在哪？比起學程式，你更應該了解演算法

程式自學十年心得：想吃這行飯，學好演算法與資料結構才能讓你站穩腳步

機器學習成效開到最大！介紹 4 個超好用的 Shell 程式技巧

【為什麼我們要挑選這篇文章】工程師是出了名的勞累命職業，加班到 10 點是常態，9 點下班叫做幸運。Github 日前有個專案反諷職場上 996 的壓榨工程師現象 ，叫做 996.ICU，內含多家公司黑暗內幕與工程師燒肝換錢的血淚。你是不是也感同身受企業過度加班現象？讓本文作者帶你來看這一個 GitHub 上破萬顆星的專案風波。（責任編輯：陳伯安）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至  jobs@fusionmedium.com」

哪裡有壓迫，哪裡就有反抗。

作為工程師的你，這幾天一定被名為 996.ICU  的 Github  項目洗版。

3 月 27 日，有開發者在 GitHub 上建了一個名為 996.ICU 的 repo ，該 repo 引用法律條款，控訴了當前社會 996 的亂象，並呼籲「Developers’ lives matter.」，生命健康重於泰山。

才創立一天，GitHub 星數就衝到 4,000 顆

截止到文摘菌（本文作者）動筆，星星數量已經增加到了  10  多萬顆，而且該項目已經有多國語言版本，有人稱「GitHub 上 星 數上升最快專案誕生」。

996.ICU 傳送門：點這 。

除了控訴之外，此 Github  上還有一個小本本（投票），專門記錄目前正在實施 996  工作制的公司。

根據投票統計， 關於 996  工作制出現最多的企業是京東，其次是有贊、阿里、字節跳動等，以加班文化著稱的華為，排名第 5。

不僅國內，這一貼文也受到了不少海外媒體和論壇的關注。

可能原  po  也沒有想到會受到如此高的關注。就在昨晚文摘菌查看相關帖子的時候發現，這一項目的 issue  版塊已經被關閉 。大家轉而紛紛在 Pull requests 下吐槽。

當然，有實行 996  公司，那麼也實行 955  工作制度的公司，即每天早 9  點打卡，一直工作到晚上 5  點，每周工作 5  天。

此處上榜的基本都是外企大公司， 排名前三分別是 Cisco、eBay、EMC。

此 Github  一天前創建，目前已經有接近 4000  顆星星數量，自稱旨在讓更多人逃離 996，加入 995  的行列。

995 GitHub 傳送門：點這 。

工程師血淋淋的生活：No sleep, No sex, No life

其實，關於中國科技公司的 996  工作制度，前幾日香港《南華早報》就發過一篇名為《No sleep, no sex, no life: tech workers in China’s Silicon Valley face burnout before they reach 30》的文章。

文章中指出，字節跳動一直執行一項所謂「大小周」政策，公司中 6,000 多名員工大部分每隔一周都要在周日加班。

文章中還引用了一些由於加班過度導致死亡的案例，比如 2015 年，騰訊互娛技術研發中心語音引擎組副組長李俊明在與懷孕的妻子散步時突然暈倒死亡；一年後，34 歲的天涯在線論壇副主編金波在北京地鐵站心臟驟停；去年，深圳無人機製造商大疆的一名 25  歲員工也死於心臟驟停 ……

這篇報道中具體舉了一名電腦專業畢業的 26  歲工程師的例子。余浩然在 2014  年創立計蒜客，具體業務是教孩子寫程式。因為有風投的支持，他的公司已經估值 2  億元人民幣（約 10 億台幣），但是付出的代價卻是慢性失眠，每天只能睡兩個小時。

余浩然表示：其實，他一點都不想過這種創業生活，但有任務要完成，在完成它之前，心裡一點容不下別的東西。

工作和生活的界限越來越模糊，一些公司雖然為員工提供了津貼，例如免費餐、班車、健身房和理髮店等其他許多娛樂和休閒場所。但是根據《南華早報》的調查， 其實這是一種變相的剝削 。一位  26  歲的產品經理的說到：公司正在想方設法解決你生活中的所有麻煩，不需要你考慮其他的事情，要把工作放在第一位 。

報導傳送門： 點這 。

這種關懷效果如何也需要衡量。根據一項統計，中國科技公司的員工平均任期不到 2.6  年，而在矽谷這一數字為 3.65  年。當然，這一統計沒有涉及一些國企。

大數據文摘曾到訪矽谷以「尊重工程師文化」著稱的大數據公司  Pivotal Lab，並採訪了其負責人 Terry。他對文摘菌表示：「工作是做不完的，如果長期處於加班狀態，工程師長期比如 2-3  年肯定堅持不下去會跳槽。而國內對於 工程師加班是因為努力程度不夠的說法也是我們想轉變的觀念之一 。

每週自願加班 6 天，連假還得隨 Call 隨到

國內工程師對於加班並不陌生，且近來有愈演愈烈的趨勢。

例如在 2019  年 1  月下旬，就有報道稱「杭州有贊科技」的公司，在會上宣佈，今後將實行「996」工作制，即每天早 9  點半到崗，一直工作到晚上 9  點。遇到緊急項目時，每周工作 6  天，每天工作時間可能會更久。除了要求員工每天工作 10  多個小時外，有參與年會者還爆料，該公司高管發言時曾提出如果無法將工作和家庭妥善平衡，可以選擇離婚。

在此以前，也有人在知乎爆料稱，來自濟南浪潮集團內部的「奮進者申請書」要求員工，必須每周自願工作 6  天，每天工作 12  小時，自願放棄所有帶薪年假，自願進行非指令性加班。不僅如此，「奮進者」還要在春節、國慶等節假日無條件加班，隨叫隨到。

另外，還有字節跳動今年也制定了一項所謂的大 / 小周工作政策，每隔一周，大部分員工周天也需要加班。

最近，在脈脈上，有自稱京東員工的網友表示，京東未來將實行「995」工作制，且是「強行規定」；還有網友表示，京東時尚居家平台事業群甚至收到了「996」工作制的通知。不過京東也針對這一消息做出了回應：不強制，但鼓勵「全情投入」。

馬斯克：沒有人只工作 40 小時就能改變世界

那麼加班背後能帶來收入嗎？

996.ICU  也幫大家算了一筆帳，996  工作制下只有拿到當前薪資的 2.275  倍 ，才在經濟帳上不吃虧。

根據胡潤百富榜，在 2018  年中國每周新增 4  名億萬富豪，其中科技是新財富的最大推動力，其次是房地產。

不過的確，每一個成功故事背後的主人公都付出了無比艱辛的努力。

特斯拉 CEO 伊隆・馬斯克（Elon Musk）曾在 Twitter  上發文稱，要想「改變世界」，人們每周需要工作大約 80  到 100  個小時。他自己是每周工作 120  個小時，特斯拉人每周要工作 100  個小時。

馬斯克表示，特斯拉要想生存下去，長時間工作是必要的，沒有別的辦法。他還說 ：「有很多更容易工作的地方，但從來沒有人能在每周工作 40  小時的情況下改變世界。」他自己當然也是這麼做的。

但在 CB Insights  的一項研究中，101  家創業公司的失敗，創始人勞累過度的原因佔比 8%。報告稱：「在必要時候減少損失，以及當你看到一個死胡同時重新調整精力投入的方向並且避免過度疲勞被認為是獲得成功的一種重要能力。」

那麼，加班還是不加？你怎麼看？

（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈Github 标星十万+！愤怒的程序员发起 996.ICU，小本本投诉过度加班公司 〉。）

你可能感興趣

GitHub 神人整理出一份 Python 開源清單：15 個領域、181 個開源項目任你用

破千顆星的 GitHub 超強資源包，所有好用的「深度學習」資源都在這裡啦！

擁有 17,000 顆星的 GitHub 大神開課！90 分鐘傳授，如何只用 JavaScript 建構神經網路

「韓流」席捲台灣之後，打開新聞，隨時都會看到韓國瑜的消息。於是有工程師寫了程式，計算某個新聞台提到「韓總」的次數，了解我們被韓總「洗版」的程度。

有工程師寫程式，追蹤某電視台報導韓國瑜的次數

韓國瑜是近期台灣高討論度的政治人物，「發財」等口號更成為時下台灣人愛用的「梗」。因為話題性高，也讓許多媒體密集追蹤與報導韓國瑜的行蹤與言論；然而國家通訊傳播委員會 NCC 調查，認為中天新聞台報導韓國瑜新聞的比例失衡，以 2 月 16 日的晚間新聞為例，比例竟高達 56.7%。

因此，有一名 PTT 帳號為 givemoney（香榴槤） 的工程師用 nodejs 寫了程式，從 4 月 1 日早上 8 點開始，追蹤某新聞台提到韓國瑜的次數，並在 PTT 上分享 及時數據 與 程式開源碼 。截至今（2）日早上 10 點，次數已突破 1,700 次。計數器上不只有數字，還會載入即時的字幕與時間。

該工程師：響應韓總發財政策，決定用程式碼協助追隨韓總腳步

該工程師在 PPT 上 表示 ，「身為高雄北漂工程師，響應韓總發財政策，決定用程式碼協助追隨韓總腳步。」同時也自問自答提出一些關於程式方面的問題，例如可以計算其他新聞台或關鍵字嗎？資料會存下來嗎？會記錄到什麼時候？該工程師回答，礙於成本，目前只能記錄某電視台的韓總關鍵字，資料無法留存，而且大概只能記個兩三日，也就是到今（2）日或明（3）日，免費額度就會用完了。

媒體會去追熱門的話題與人物，但比例失當的話，就會造成報導失衡，讓閱聽者對情勢造成誤判。傳統媒體是所謂的「第四權」，有監督政府的重責大任；現在則有人說，社群是「第五權」，除了監督政府，也監督傳統媒體，讓社會大眾知道媒體們的立場，以及報導是否偏頗等等。這位工程師就用他的程式專長，做出這樣的優良示範。

該工程師的 PPT 發文
韓總計數器 Web 端
程式 開源碼

參考資料來源：
1.《PPT》：〈 韓總計數器 (開源)〉
2.《新頭殼》：〈 網友設計「韓總計數器」統計新聞台提關鍵字次數 〉
（本文提供合作夥伴轉載。首圖來源： 韓總計數器）

延伸閱讀

有神快拜！網友把「台灣共識」翻成程式語言，理組不用再被文字遊戲玩了
【工程師葵花寶典】記憶體不夠怎麼辦？一條程式碼，幫你節省 50% 以上的空間
【附完整程式碼教學】教你一步一步用 Python 打造數據實驗室，輕鬆預測比特幣價格趨勢

【為什麼我們要挑選這篇文章】複雜度分析式演算法的重要概念，下文作者將透過寶可夢的故事，帶工程師認識複雜度分析的 5 個基本技術。（責任編輯：郭家宏）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

啥是演算法？

演算法就是，工程師懶得給你解釋程式碼時，堵你嘴的東西。（這一步使用了 XX 算法。）

開個玩笑！不論什麼演算法，寫出來之後你都得對它負責。

提到演算法，就不得不提到複雜度分析——這也是工程師面試跑不了的一關。

「複雜度分析」，說起來概念特別簡單，可真分析起來，又常常讓人手足無措。

今天，文摘菌（本文作者）就引用一些寶可夢的例子，給大家回顧一下複雜度分析的概念，然後從易到難給大家介紹複雜度分析的常用方法。

文章分為 5 個部分：
1. 為什麼要做複雜度分析？
2. 如何做複雜度分析？
3. 從排序演算法說起
4. 遞迴演算法分析
5. 如何選擇最好的演算法？

其中，1、2 部分會對複雜度分析做簡單介紹（熟悉複雜度分析基本概念的同學可以跳到部分 3）。部分 3 會以排序演算法為例，給出複雜度分析的經典案例。 部分 4 會重點分析遞迴演算法，並介紹遞迴演算法複雜度分析的兩種方法：「遞迴樹法」和更通用簡潔的「主定理法」。最後，部分 5 會簡要討論，在實際情況中我們如何根據複雜度分析選擇最好的演算法。

為什麼要做複雜度分析？

舉個例子來解釋。

我們假設可愛的寶可夢們設立了一場錦標賽。每場比賽都有兩個寶可夢參賽，勝者的等級會得到提升。

每次比賽，我們都會隨意選出一個寶可夢，然後選出和它等級最接近的一位作為它的對手。

很簡單嘛！在選取第一位寶可夢後，你可以將它的等級和其他所有寶可夢比較，這基本上是線性搜尋。

但在比賽當天，我們假設有 1000 個寶可夢報名比賽！這個演算法還可行嗎？

由上面的簡單例子可見，可擴展性往往是是演算法性能中不得不考慮的重要一環。

如何評估演算法的可拓展性，我們就要講到漸進分析。（通常，複雜度分析也就是我們這講的漸進分析）

漸近分析是僅根據輸入大小（N）來評估演算法的性能，其中 N 可以非常大。漸進分析可以讓你瞭解應用程式的侷限性，因此對於衡量程式碼的性能非常重要。

例如，如果參與戰鬥的小寵物的數量是 N，那麼線性搜尋演算法的漸近複雜度是 O（N）。如果你不知道這個符號是什麼，請不要擔心。我們馬上就告訴你。

簡單來說，你要詢問 N 個小寵物他們的等級是什麼，然後做出決定。想像一下，問所有 1000 個小寵物，這絶對是個累人的工作！

對於一台機器來說，O（N）可能並不壞，但對於一個看重響應速度和處理速度的網站而言，它可能不是最好的選擇。

不考慮輸入巨大的情況，你早晚會遇到可拓展性問題。

回到上面的例子。如果我們使用字典，或雜湊表來查找具有相同排名的所有小寵物，我們就可以將演算法時間複雜度降低到 O（1）。

這就號像我們有個知曉所有寶可夢等級的經理人。我們只要問一下他，就能知道匹配答案了！

如何做複雜度分析？

讓我們再來舉一個漸進分析的例子吧！

我們假設皮卡丘正在尋找一個具有某種特殊能力的合作小精靈。皮卡丘開始逐一向所有小寵物詢問他們的能力。這種方法被稱為線性搜索，因為它是逐個線性地完成的。但是為了方便參考，讓我們稱之為「皮卡丘搜尋」。

在上面的程式碼片段中，pokemons_list 是參與錦標賽的所有寶可夢的列表。因此，該列表的大小為 N。

皮卡丘搜尋的運行時間分析：

1. 第 2 步是一個循環，因此，其中的操作將重複 N 次。僅當步驟 3 中的條件為真時才執行步驟 4。執行步驟 4 後，循環中斷並返回結果。
2. 如果步驟 3 花費的時間是常數級的，比如 C1，那麼 for 迴圈所用的總時間將是 C1×N。
3. 所有其他操作都是不受迴圈影響的常數時間操作，因此我們可以將所有這些操作作為 C2 的累計常量。

總運行時間 f(N)=C1×N+C2，是一個與 N 相關的函數。

讓我們把 N 放大。如果 N 的值非常非常大，該怎麼辦？你認為常數會有什麼意義嗎？

注意！在演算法分析中，一個重要的想法是，忽略不太重要的部分。

例如，如果演算法的運行時間漸近表示為 10N²+ 2N + 5，則只有高階項 N² 才有意義。這使得演算法之間的比較更容易。

不同情況下的分析

每當輸入不同，演算法呈現的效果也不同。這意味著，我們需要討論如何定義這種行為或演算法的複雜性。

1. 最佳情況〜絶對樂觀。皮卡丘非常幸運，因為他接觸的第一個精靈就擁有他正在尋找的特殊能力。
2. 最差情況〜絶對悲觀。皮卡丘不得不去拜訪所有的小精靈，更令他沮喪的是，最後一個才擁有他想要的超能力。
3. 普遍（平均）情況〜實事求是。皮卡丘現在已經長大，並且很有經驗，他知道這一切都是時間和運氣的問題。他估計在他遇到的前 500 個左右的精靈中找到超級口袋精靈的機會很高，他是對的。

上述三種情況都可以被用來分析演算法。

「最佳情況複雜度」沒有太大用處。它可以作為演算法複雜度的下限值。如果你執意要用它來表示演算法複雜度，那麼你就只考慮了最佳情況。你必須得非常幸運，這樣你的演算法才能達到最佳情況。從實際意義上說，這對演算法沒有多大幫助。

「平均情況複雜度」通常很難計算，因為它需要你分析演算法在各種輸入上的性能，因此也沒有被廣泛的使用。

「最差情況複雜度」幫助你做好最壞的準備。在演算法中，這種悲觀主義是好的，因為它給出了複雜度的上限，這樣你就知道你的演算法有哪些限制！

複雜度分析工具

前面我們看到，皮卡丘搜尋其他小精靈的總運行時間是 N 的函數，f(N)= C1.N + C2。讓我們來瞭解一下有哪些工具可以用來表示運行時間，以便比較各演算法。

Big O ：哦，沒錯！它的發音就是這樣，Big — Oh！它是演算法複雜度的上限。因此，它用於表示演算法的最差情況。

它實際的意思是，不管輸入是什麼，演算法的最大運行時間是多少。

這是使用最廣泛的表達，因為它可以透過最差情況來分析演算法。

對於皮卡丘的搜尋，我們可以說 f（N）或運行時間對於非常大的 N，會向上達到 C.g(N)，其中 c 是一個常量，g(N) = N。因此，O(N) 表示皮卡丘搜尋的漸近上界。

Big Omega（Ω）：與 Big O 表示法類似，Ω 表示法用於定義演算法性能的漸近下界。因此，它用於表示最佳情況場景。

Ω 下界本質上是在不考慮輸入的情況下，演算法執行所需的最短時間。

在實際情況中，這種表示法並不常用，因為研究最佳情況不能成為演算法比較的正確衡量標準。

對於皮卡丘的搜尋，我們可以說 f（N）或運行時間對於非常大的 N，會向下達到 C.g(N)，其中 c 為常量，g(N) = 1。因此 Ω(1)  表示皮卡丘搜尋的漸近下界。

Big Theta（Θ）：演算法行為的嚴格約束，此符號定義函數的上界和下界。這稱為緊確界，因為我們將運行時間限制在上下兩個常量因子內。就像這樣：

每個演算法可能有不同的最佳和最差情況。當兩者相同時，我們傾向於使用 Θ 表示法。否則，最佳和最差情況需要被分別表示：

（a）對於很大的 N 值，最差情況的 f（N）受函數 g(N) = N 的限制。因此，緊確界複雜度將表示為 Θ(N)。這意味著最壞的情況下皮卡丘的搜尋時間是最少要 C1⋅N，最多要 C2⋅N。
（b）類似地，其最佳情況的緊確界複雜度是 Θ(1)。

空間複雜度

我們之前一直在討論時間複雜度。複雜度分析中的另一個重要概念是空間複雜度。顧名思義，它是指演算法在 N 非常大的情況下占用多少硬碟空間或內存。

每當我們比較用於解決特定問題的各種演算法時，我們不僅僅關注時間複雜度，空間複雜度也是比較不同演算法的重要方面。是的，可能目前我們的機器有大量可用內存，因此，多消耗些空間沒什麼影響。但是，我們不應該一直忽視它。

時空權衡

通常，你希望你的演算法速度要快，而這樣做可能最終會導致很糟糕的空間複雜度。

但有時，我們會犧牲一些時間來換取空間的優化。

在實際應用中，犧牲時間或者空間以換取另一方的優化被稱為演算法分析領域的「時空權衡」。

皮卡丘現在意識到了，他每隔一天就要尋找一個寶可夢。這意味著一遍又一遍地運行皮卡丘的搜尋。嗯！他肯定厭倦了每天的大量重複工作。

為了幫助他加快搜尋過程，我們決定使用雜湊表。我們可以使用寶可夢的能力類型作為雜湊表的鍵值。

如果我們需要找到具有某種特殊能力的小精靈，最壞的情況就是複雜度為 O(1)，此時雜湊表的搜尋時間是一個恆定值。

所以現在所需要的只是創建一個雜湊表，然後使用它進行查找以降低整體運行時間！

但事情也不是這麼簡單，你可以看到這麼做帶來了空間成本。雜湊表對每個 Pokemon 精靈會用一個條目來存儲。因此，空間複雜度是 O(N)。

選時間 O(N) 空間 O(1) ？還是時間 O(1) 空間 O(N) 呢？

這樣的選擇取決於實際應用的需要。

如果我們有一個面向客戶的應用程式，它的響應速度就不應該很慢。在這種情況下，優先考慮的是，無論使用多少空間，應用程式都應儘可能快速響應。但是，如果我們的程式受到可用空間的限制，則必須放棄快速響應來彌補空間的緊缺。

從排序演算法說起

時間和空間的複雜性始終是緊密相連的。我們需要進行數學運算並且採用最好的方法。

現在，我們就來進行一些正兒八經的複雜度分析啦！

首先，皮卡丘想分析所有的排序演算法。

讓我們看看基本但關鍵的排序演算法。假設要排序的輸入數組 pk_rank 的大小為 N.

如果你不熟悉下面提到的任何一種排序演算法，建議你在閲讀後面部分之前先瞭解一下它們。以下示例的目的不是為瞭解釋不同的演算法，而是去解釋如何分析它們的時間和空間複雜度。

氣泡排序

氣泡排序是最簡單的排序演算法之一，它反覆比較數組的相鄰元素，如果它們亂序則交換位置。可以類比水裡的泡沫最後會上升到水面上。隨著數組元素的排序，它們會逐漸冒泡到數組中的正確位置。

就像皮卡丘玻璃杯中的氣泡。

時間複雜性：現在我們已經有了演算法，再來分析它的時間和空間複雜性。我們可以清楚地從步驟 2 和 3 中看到演算法中存在嵌套循環結構。第二個 for 循環的範圍是 N-1-i，表明它依賴於上一個循環。
當 i = 0 時，第二個 for 循環會被執行 N-1 次
當 i = 1 時，第二個 for 循環會被執行 N-2 次
當 i = 2 時，第二個 for 循環會被執行 N-3 次
當 i = N-1 時，第二個 for 循環會被執行 0 次

現在我們知道了氣泡排序演算法在整個過程中的每一步所花費的時間。我們之前提到過，演算法中有一個嵌套循環。對於第一個循環中的每個變數值，我們知道在第二個循環中所花費的時間。現在剩下的就是給這些加總。我們這樣做：

S = N-1 + N-2 + N-3 + … + 3 + 2 + 1
~ N * (N+1) / 2
~ N² + N（忽略常數）

如果你查看步驟 4 和步驟 5，這些是常量時間操作。它們並沒有真正增加時間複雜度（或者空間複雜性）。這意味著，我們有 N²+ N 次疊代，並且在每次疊代中，我們都執行了這些常量時間操作。

因此，氣泡排序演算法的運行時間複雜度為 C.（N²+ N），其中 C 是常量。因而我們可以說氣泡排序的最壞情況是時間複雜度為 O（N²）。

這是一個很好的排序演算法嗎？我們還沒有看過任何其他類似的演算法來進行比較。但是，讓我們看看這個算法需要多長時間來排序十億個皮卡丘。

我們將計算留給你，結果是：排序十億個皮卡丘（假設每個指令需要 1 毫秒執行）將需要大約 31,790 年。

空間複雜性：與該演算法的時間複雜度相比，分析空間複雜度相對簡單些。氣泡排序算法僅僅重複執行一個操作：交換數字。同時，它不使用任何外部儲存器。它只是重新排列原始數組中的數字，因此，空間複雜度是個常量，即 O（1）或者 Θ（1）。

插入排序

你喜歡打牌嗎？

在抓牌時，我們往往需要對牌組進行排序。插入排序的思想非常類似於對牌組進行排序。

比方說，你有幾張按升序排序的卡牌。如果你被要求在右邊插入另一張牌，同時要保證你手中的牌仍然是有序的。你會怎麼做？

你可以從手中牌的最左側或最右側開始，將新牌與每張牌進行比較，從而找到合適的位置。

同樣，如果有更多新牌，則對每張新卡重複相同的過程，同時要保證手中的卡是有序的。

插入排序原理相同。它從索引 1 開始（數組排序從 0 開始）並將每個元素視為一張新卡。然後，每個新元素就可以放置在已經排序的子陣列中的正確位置。

這裡需要注意的重要事項是，給定一張新牌（即我們例子中索引為 j 的一個元素），手中的所有卡（即該索引前的所有元素）都已經排序完畢。

讓我們看一下插入排序的正式演算法：

時間複雜度：從步驟 1 和 4 開始，在 for 循環中有一個嵌套的 while 結構。 while 循環運行 j + 1 次，其中 j 依賴於 i。讓我們看看 j 的值如何隨著 i 的變化而變化。

當 i=1 時，j=0，while 循環會被執行 1 次。
當 i=2 時，j=1，while 循環會被執行 2 次。
當 i=3 時，j=2，while 循環會被執行 3 次。
當 i=N-1 時，j=N-2，while 循環會被執行 N-1 次。

現在我們知道插入排序演算法在整個過程中的每一步所花費的時間（即疊代）。總時間是：

S = 1 + 2 + 3 + … N-2 + N-1
~ N * (N+1) / 2
~ N² + N（忽略常數）

步驟 2 到 7 是常量時間操作。它們並沒有真正增加時間複雜度（或者空間複雜性）。這意味著，我們有 N²+ N 次疊代，並且在每次疊代中，我們都執行了這些常量時間操作。

因此，插入排序演算法的運行時間複雜度是 C.（N^2 + N），其中 C 是常量。因此，我們可以說插入排序的最壞情況是時間複雜度與氣泡排序的時間複雜度即 O（N^2）相同。

空間複雜性：與該演算法的時間複雜度相比，分析空間複雜度相對簡單些。插入排序演算法僅重新排列原始數組中的數字。同時，它根本不使用任何外部儲存器。因此，空間複雜度是常量，即 O（1）或者 Θ（1）。

注意：基於漸近複雜度比較演算法簡單快捷。從理論分析來看，它是一個很好的衡量標準。但是從實踐層面上看，如果兩種演算法具有相同的複雜性，也不一定意味著它們在實際場景中具有相同的表現性能。

在計算演算法的漸近複雜度時，我們忽略所有常量因子和低階項。

但是這些被忽略的值最終會增加演算法的運行時間。

當數組幾乎已經是按順序排列好的時候，插入排序比氣泡排序快得多。對於每次遍曆數組，氣泡排序必須一直走到數組的末尾並比較相鄰數字的大小；另一方面，如果數組其實已經被排序，插入排序則會提前終止。你可以嘗試在一個已經被排序的數組上執行這兩個演算法，並查看每個演算法完成執行所需的疊代次數。

因此，當你在為自己的應用程式尋找最佳演算法時，總是需要從許多不同方面進行分析。漸近分析肯定有助於淘汰較慢的算法，但更多的觀察和更深入的見解有助於為你的應用找到最適合的演算法。

合併排序

到目前為止，我們已經分析了兩種最基本的排序演算法。這些排序演算法算是入門級必須介紹的，但它們具有高漸近複雜性，因此通常在實踐中我們並不使用他們。

讓我們來看一看更快、更實用的排序演算法吧。

合併排序演算法摒棄了我們在前兩個演算法中看到的嵌套循環結構化排序，採用了我們將在下面討論的全新範例。

合併排序演算法基於一種被稱為各個擊破的編程範式。這種編程範例基於一個非常簡單的想法，並且在許多不同的演算法中都很實用——包括合併排序。各個擊破分為三個基本步驟：

劃分：將一個大問題分解為更小的子問題。
攻克：最佳地解決子問題。
合併：最後，結合子問題的結果，找到原始大問題的解決方案。

讓我們看一下合併排序演算法是如何利用各個擊破方法來解決問題的。

1. 劃分：該方法中的第一步是將給定的數組劃分成兩個大小相等的較小子數組。這其實還是挺有用的，因為我們現在只需要對兩個只有原來元素數量一半的數組進行排序啦。
2. 攻克：下一步是對較小的數組進行排序。這部分被稱為攻克步驟，因為我們正在試圖以最佳方式解決子問題。
3. 結合：最後，我們看到原始數組的兩半，他們都被排序好啦。現在我們必須以最佳方式來組合它們，以得到一整個排序好的數組。這其實是上面幾步的組合步驟。

可是等等。這樣就完了嗎？

給定一個包含 1000 個元素的數組，如果我們將它分成 2 個相等的一半，每個 500，我們仍然有很多元素要在數組（或子數組）中進行排序。

我們不應該將這兩半進一步劃分為 4，以獲得更短的子陣列嗎？

當然應該啦！

我們遞迴地將數組劃分為較小的數組們，並對它們進行排序與合併以重新獲得原始數組。

這實質上意味著我們將例如 1000 的數組分成兩半，每組 500。然後我們進一步將這兩半分成 4 個部分，每部分 250 個，依此類推。如果你無法在複雜性分析方面直觀地考慮所有這些問題，請不要擔心。我們很快就會談到這一點。

我們來看看合併排序演算法。該演算法分為兩個函數，一個遞迴函數對給定數組的兩半分別進行排序，另一個則將兩半合併在一起。

我們將首先分析合併（merge）函數的複雜性，然後分析合併排序（merge_sort）函數。

上面的函數簡單地將數組的兩個已排序的一半合併為一個已排序的數組。用索引來表示兩半的話就是，左半部分來自 [left, mid]，右半部分來自 [mid + 1, right]。

第 2-3 步將元素從原始數組複製到臨時緩衝區，我們使用此緩衝區進行合併。已排序的元素將被複製回原始數組。由於我們會遍曆數組的某個部分，假設該數組有 N 個元素的話，該操作的時間複雜度為 O(N)。

第 5 步是一個 while 循環，疊代兩個子數組中較短的一個。這個 while 循環和之後第 13 與 14 步內的循環涵蓋了兩個子陣列的所有元素。因此，他們的時間複雜度是 O(N)。

這意味著合併步驟演算法的時間複雜度是線性的。

合併排序的總體複雜性取決於調用合併函數的次數。

讓我們繼續看看原始的合併排序（merge_sort）函數。

第 4 步在數組的左半部分調用該函數（merge_sort）。

第 5 步在數組的右半部分調用該函數（merge_sort）。

然後第 6 步最後調用合併（merge）函數將兩半結合起來。

呃。一個函數調用自己？

如何計算它的複雜性？

目前為止我們已經討論過循環分析。然而，許多演算法（比如合併排序）本質上是遞迴的。當我們分析它們時，我們得到時間複雜度上的遞迴關係。我們獲得了計算輸入大小為 N 的演算法時間複雜度的函數；它依賴於 N，以及小於 N 的輸入的運行時間。

遞迴演算法分析

主要有兩種方法來分析遞迴關係的複雜性：

1. 使用遞迴樹
2. 主定理方法

遞迴樹分析

這是分析遞歸關係複雜性最直觀的方式。本質上，我們可以以遞迴樹的形式可視化遞迴關係。

可視化有助於瞭解演算法在每個步驟（讀取級別）完成的工作量。總結在每個級別完成的工作能夠告訴我們演算法的整體複雜性。

在我們畫出合併排序演算法的遞迴樹之前，讓我們首先看一下它的遞迴關係。

T（N）= 2T（N / 2）+ O（N）

用 T(N) 表示對由 N 元素組成的數組進行排序所完成的工作量（或所花費的時間）。上述關係表明，所花費的總時間等於將數組的兩半分別排序所花費的時間加上將其合併所花費的時間。我們已經知道合併兩半數組所花費的時間了——O(N)。

我們可以寫出遞迴關係如下：

T（N）= 2T（N / 2）+ O（N）
T（N / 2）= 2T（N / 4）+ O（N / 2）
T（N / 4）= 2T（N / 8）+ O（N / 4）
……

以樹的形式視覺化更容易。樹中的每個節點都包含兩個分支，因為在給定每個單個問題時我們都有兩個不同的子問題。讓我們看一下合併排序的遞迴樹。

每一個節點表示一個子問題，每個節點上的數值表示解決該問題需要花費的工作量。根節點表示的就是初始問題。

在我們的遞迴樹中，每個非葉節點有 2 個子節點，而且標有子所劃分處的子問題數量。從歸併排序算法中，我們可以可以看到在進行每一步遞迴的時候，給定的數組會被等分為兩份。

因此，為了分析歸併排序的複雜度，我們需要弄清楚兩件重要的事。

1. 我們需要知道樹結構中的每個層級（level）需完成的工作量。
2. 我們需要知道樹的總層數，也就是大家通常所說的樹的高度。

首先，我們要計算一下遞迴樹的高度。從上圖所示的遞迴樹中，我們能看到每個非葉節點都分位兩個節點。因此，這就是一個完整的二叉樹。

我們會一直拆分數值直到子數組中只剩下一個元素（也就是最底層），這時我們就可以不用排序直接返回了。

在我們的二元遞迴樹的第一層，有一個有 N 個元素組成的問題。其下一層由兩個子問題（需要進行排序的數組）構成，每個子問題都有 N/2 個元素。

我們真正關心的並不是有多少子問題，我們只想知道每個子問題的大小，因為在樹結構裡，同一層內的子問題都有一樣的大小。

節點內元素的數量按照 2 的次方遞減。所以按上述的模式可以表示為：

N = 2^X
X = log_2(N)

這表示樹的高度為 log_2(N)（N 以 2 為底求對數）。那就讓我們看一下演算法在每一步需要完成的工作量。

我們定義 T(N) 為對含有 N 個元素的數組進行排序所需的工作量。

T(N) = 2T(N / 2) + O(N)

這算式表示樹結構中的第一層的工作量為 O(N)， 其餘的工作量 2T(N / 2) 在下一層完成。在下一級，如上圖所示，需完成的工作量是 2 * O(N / 2) = O(N)。類似地，在第三層要完成的工作量就是 4 * O(N / 4) = O(N)。

令人驚訝的是，該算法在每層上的工作量是相同的，且都等於 O(N)，這是歸併操作所消耗的時間。因此，可以用層數來定義總體的時間複雜度數。

如我們前面計算的那樣，遞迴樹的層數是 log(N)，因此，歸併排序的時間複雜度就是 O(Nlog(N))。

很好，我們掌握了一種用遞迴樹形式進行漸進分析的方法。這是種有趣的方法，可以讓我們很直觀地認識遞迴關係的複雜度。雖然去繪製完整的遞迴樹是不可行的，但遞迴樹有助於我們建立對遞迴關係的理解。

主定理方法

我們研究了基於遞迴樹的分析方法，以實現對遞迴進行漸進分析。但是，如前文所述，每次為了計算複雜度去繪製遞迴樹是不可行的。

歸併排序遞迴只是將問題（數組）劃分為兩個子問題（子數組）。但是，當有演算法要把問題分成 100 份子問題時，我們要怎麼分析呢，顯然不能透過繪製遞迴樹的方式。

因此，我們要用一種更直接的方式來分析遞迴關係的複雜度。透過這種方式，我們不需要實際地繪製遞迴樹，而且這種方式也是基於和遞迴樹一樣的概念上。

主定理方法這時就強勢登場了，它也是基於遞迴樹方法。該方法能應用於三種不同的場景，基本上也就是涵蓋了大部分的遞迴關係。在展示案例之前，我們先看看通用遞迴關係的遞迴樹：

T(n) = a T(n / b) + f(n)
n 是總問題的大小。
a 是遞歸關係中子問題的數量。
n/b 每子問題的的大小（假設子問題大小相同）
f(n) 表示調用遞歸之外的工作成本，包括將問題劃分為較小子問題的成本及合併子問題解決方案的成本。

想理解主定理方法，有兩點最重要，分別是演算法在根節點的工作量和在葉節點工作量。

根節點工作量相對點簡單，就是 f(n)。葉節點的工作量取決於其所在樹上的高度。

樹的高度為 log_b(n)，也就是以 b 為底取 n 的對數。這和歸併排序的遞迴樹道理一樣，而在歸併排序中 b 就是 2。在任意層 l 的節點數量就是 a^l，所以最後一層的葉節點數可由如下算式所得：

a^{log_b(n)} = n ^ log_b(a) nodes.

假設在末層完成每個子問題所需的工作量為 Θ(1)，因此在葉節點處完成的工作量就是 n ^ log_b(a)。

如果你認真觀察通用遞迴關係，你會發現如下兩個成分：

1. 分部步驟 ( / ) 算子，這部分會不斷複製並不斷乘以值越來越小的本身。
2. 治理步驟 ( ) 算子，這部分會把迷你部分聚集在一起。

這兩股力量似乎在相互對抗，這樣一來，他們想控制演算法的總工作量，從而控制整體時間複雜度。

誰會占主導呢？我們需要分三種情況討論

情況 1（分部步驟獲勝）

如果 f(n) = Θ(n^c)，使得 c < log_b(a)，那麼可得出 T(n) = Θ(n^log_b(a))。其中 f(n) 是根節點處工作量，n ^ log_b(a) 是葉節點的工作量。

如果葉節點的工作量是多項式形式的，那計算結果就是葉節點的工作量。

e.g. T(n) = 8 T(n / 2) + 1000 n^2

在這個例子中，a = 8，b = 2，f（n）= O（n ^ 2）

因此， c = 2 且 log_b（a）= log_2（8）= 3

顯然 2 <3， 並且很容易看出這適用於 Master 方法的案例 1。這意味著，在樹葉處完成的工作量漸近地高於在根處完成的工作量。因此，該遞迴關係的複雜度是 Θ（n ^ log_2（8））=Θ（n ^ 3）。

案例 2（治理步驟獲勝）

如果 f（n）= Θ（n ^ c）使得 c> log_b（a），則 T（n）=Θ（f（n））。如果在根節點上完成的工作漸進式更多，那麼我們的最終複雜度就是根節點的複雜度。

我們並不關心較低級別的工作量，因為最大的多項式項依賴於控制演算法複雜度的 n。因此，所有較低級別上的工作可以被忽略。

例如 T（n）= 2T（n / 2）+ n ^ 2

如果在主定理方法中適合這種遞迴關係，我們可以得到：

a = 2, b = 2, and f(n) = O(n^2)

因此， c = 2 且 log_b（a）= log_2（2）= 1

顯然 2> 1，因此這符合 Master 方法的情況 2，其中大部分工作是在遞迴樹的根處完成的，這就是為什麼 Θ（f（n））控制演算法的複雜度的原因。因此，該遞迴關係的時間複雜度是 Θ（n ^ 2）。

案例 3（平手！）

如果 f（n）=Θ（n ^ c）使得 c = log_b（a），則 T（n）=Θ（n ^ c * log（n））。最後一種情況是，在葉上完成的工作和在根處完成的工作之間打成平手。

在這種情況下，治理和分步驟同樣占主導地位，因此完成的工作總量等於在任何級別完成的工作量*樹的高度。

例如 T（n）= 2T（n / 2）+ O（n）

等等，這不就是歸併排序嘛！

對！這就是歸併排序算法的複雜度。如果我們在主定理方法中採用歸併排序的遞迴關係，我們得到：

a = 2，b = 2，f（n）= O（n ^ 2）

因此， c = 1 = log_2（2）

這符合上述案例 3 中的標準。通過上面的數字可以證明所有級別的工作量都將相等。因此，時間複雜度等於在任何級別的工作量*所有級別數（或者是樹的高度）。

我們使用兩種不同的方法分析了歸併排序演算法的時間複雜度，即遞迴樹和主定理法。因為歸併排序演算法是一種遞迴演算法，我們之前看到的用於解決循環問題的經典漸近分析方法在這裡沒用到。

空間複雜度：對於空間複雜度，我們不必使用任何複雜的技術，因此分析更簡單。在歸併排序演算法中占用數據結構的一個主要空間是合併過程中使用的臨時緩衝區。這個數組被初始化一次，此數組的大小是 N。占用空間的另一種數據結構是遞迴堆棧。實質上，遞迴調用的總數決定了遞迴堆棧的大小。正如我們在遞迴樹表示中看到的那樣，歸併排序調用的次數基本上是遞迴樹的高度。

遞迴樹的高度是 log_2（N），因此，遞迴堆棧的最大也就是 log_2（N）。

因此，歸併排序的總空間複雜度將是 N + log_2（N）= O（N）。

二進制搜索

還記得嗎，皮卡丘想要尋找特定能力的寶可夢。小皮卡丘有 1000 個小夥伴，他必須找到一個具有特定能力的寶可夢。是的，皮卡丘對他的對手非常挑剔。

他的要求一天一個變，每當他的要求發生變化時，他肯定不能去檢查每一個寶可夢也就是說他不能通過執行線性搜尋來找到他正在尋找的目標。

我們之前提到使用雜湊表來儲存寶可夢的數據，用它們的能力作為 key，寶可夢本身作為 value。這會降低搜尋的複雜度至 O（1）即恆定時間。

然而，在考慮到有 N 個寶可夢可用的情況下，這會用到額外的空間使搜尋操作的空間複雜度提高到 O（N）。在這種情況下，N 將是 1000。如果皮卡丘沒有這些額外的空間，但仍然想加快搜尋過程，那要怎麼辦呢？

沒錯！皮卡丘可以利用他對排序演算法的深刻瞭解，想出一種比慢速線性搜尋更快的搜尋策略。

皮卡丘決定向他的好朋友代歐奇希斯尋求幫助。代歐奇希斯可以幫助皮卡丘根據寶貝的能力值重新排列寶可夢列表。

代歐奇希斯使用快速排序演算法，而不是傳統的排序演算法對寶可夢排序。

這麼一來，他沒有使用任何額外的空間，並且排序 N 個寶可夢所花費的時間與歸併排序演算法一樣。

之後，皮卡丘非常聰明地提出了一種搜尋策略，利用了寶可夢列表的排序特性。

這種新的策略/演算法被稱為二進制搜尋演算法。（註：排序是運行二進制搜尋的前提條件，一旦列表被排序後，皮卡丘可以在此排序列表上多次運行二進制搜尋）。

讓我們看看這個演算法的代碼，然後分析它的複雜性。

顯然，該算法的本質是遞迴。我們嘗試用新學到的技巧來分析二進制搜尋演算法的時間複雜度。這兩個變數 l 和 r 基本上定義了數組中我們必須搜尋對給定要素 x 的部分 。

如果我們看一下演算法，它所做的一切就是將輸入數組的搜尋部分分成兩半。除了根據某種條件進行遞迴調用之外，它實際上並沒有做任何事情。那麼，讓我們快速查看二進制搜尋演算法的遞迴關係。

T(n) = T(n / 2) + O(1)

這看起來好像是一個非常簡單的遞迴關係。首先讓我們嘗試分析遞迴樹並從中得出複雜性，然後我們將使用主定理方法，看看三種情況中哪一種適合這種遞迴。

哇！這種二進制搜尋演算法非常快。它比線性搜尋快得多。這對我們可愛的好朋友皮卡丘來說意味著，在 1000 隻小精靈中，他最多只需要去詢問其中的 10 個，就可以找到他特殊的寶可夢。

現在讓我們看看如何採用更「公式化」的方法進行遞迴複雜度分析。Master 方法在這種情況下對我們有所幫助。通用主方法的遞迴關係是

T(n) = a T(n / b) + f(n)

而對於我們的二進制搜尋演算法，我們有

T(n) = T(n / 2) + O(1)
f(n) = O(n^0), hence c = 0
a = 1
b = 2
c = 0

對於 Master 定理來說有 3 種不同的情況，而 c 和 log_b（a）是其中的影響因素。在我們的例子中，0 =log_2（1）即 0 = 0 的時候，二分搜尋演算法符合主定理的情況 3，因此 T(n) = Θ(n^0 log(n)) = Θ(log(n)

如何選擇最好的演算法？

在本文中，我們介紹了複雜性分析的概念，它是算法設計和開發的重要部分。我們看到為什麼分析演算法的複雜性很重要，以及它如何直接影響我們的最終決策。我們甚至看到了一些有效和正確分析這種複雜性的優秀技術，以便及時做出明智的決策。然而，問題出現了！

鑒於我所知道的兩種算法的時間和空間複雜性，我該如何選擇最終使用哪種算法？有黃金法則嗎？

很遺憾，答案是，沒有。

沒有黃金法則可以幫助你決定使用哪種演算法。這完全取決於很多外部因素。看看以下幾種情況的例子吧！

空間無約束

如果你有兩個演算法 A 和 B，並且你想要決定使用哪個演算法，除了時間複雜度之外，空間複雜度也會成為一個重要因素。

但是，考慮到空間不是你所關心的問題，最好採用能夠在更多空間的情況下進一步降低時間複雜度的演算法。

例如，Counting Sort 是一種線性時間排序演算法，但它在很大程度上取決於可用空間量。確切地說，它可以處理的數字範圍取決於可用空間的大小。給定無限空間，你最好使用 Counting Sort 演算法對大量數字進行排序。

亞秒級延遲要求和可用空間有限

如果你發現自己處於這種情況，那麼深入瞭解演算法在許多不同輸入上的性能變得非常重要，尤其是你期望演算法在你的應用程式中使用的輸入類型。

例如，我們有兩種排序演算法：氣泡排序和插入排序，你要在其中決定使用哪一種用於根據用戶年齡對用戶列表進行排序。你分析了預期的輸入類型，並且你發現輸入數組幾乎已經排序。在這種情況下，最好採用插入排序。

等等，為什麼有人會在現實中用插入排序或者氣泡排序？

的確，很多人認為這些演算法僅用於教育目的而未在任何真實場景中使用。但實際並非如此。

比如 Python 中的 sort（）功能。它就使用了基於插入排序和歸併排序的混合演算法，稱為 Tim Sort 演算法。

確實，插入排序可能對非常大的輸入沒有用，正如我們從其多項式時間複雜度中看到的那樣。然而，它卻能迅速處理幾乎排好序的數組，這正是它在 Timsort 演算法中使用的原因。

簡而言之，不同演算法之間不會有明確的黑白劃分。

演算法的屬性，如它們的時間和空間複雜性，都是非常重要的考慮因素。演算法使用的輸入大小以及可能存在的任何其他約束也有可能產生影響。

考慮到所有這些因素，我們才能做出明智的決定！

原文 傳送門

（本文經 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈 文章標題，附上超連〉 。首圖來源：大數據文摘）

更多工程師必備技能

R 語言可用來開發深度學習！不只是統計分析，R 還有這 10 個強大隱藏功能
GitHub 神人整理出一份 Python 開源清單：15 個領域、181 個開源項目任你用
【工程師葵花寶典】記憶體不夠怎麼辦？一條程式碼，幫你節省 50% 以上的空間

【我們為什麼挑選這篇文章】聽說冥想比嗎啡還有效舒緩疼痛，以及改變大腦結構、減少壓力改善憂鬱等等，或許因為這樣的魅力，矽谷悄悄席捲一場「冥想」熱潮，就來看看冥想到底是如何趕超瑜珈，在科技公司火了吧？（責任編輯：黃穗懷）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

即便你是死忠谷粉，用過 Google 所有（包括已經被砍掉）的產品 —— 如果你不是這家公司員工的話，可能也從來沒見過上面這個 logo 。

這個 logo 的背後，其實是矽谷巨頭 Google 內部一個小社團，名字叫做 gPause 。 命名方式和 Google 其他產品類似，但 pause 的意思是「暫停 」 。

gPause 旨在幫助員工獲得 「 正念」，達到情緒放鬆、工作減壓等目的。 Google 員工通過這個社團分享他們的正念經驗，推薦相關方面的叢書和幫助冥想或放鬆身心的 app，以及解答其他同事的關於正念的問題。

正念又是個什麼東西？ 它最初來自於佛教的禪修，後來逐漸演化成一種不限宗教信仰，更為廣泛的心理健康療法。 正念的英文名叫做 mindfulness，直觀地講就是通過冥想（meditation）等方式清楚、 有意識地觀察自己的心理狀態，但不陷入到這種心理狀態中。

每天或每隔幾天，當會議不斷、電子郵件爆炸的時候，停下來，呼吸，直面並審視自己的狀態，卻又不被其所擺佈。 通過這種方式，許多 Google 員工獲得了他們的正念，排解了壓力，能夠以更高的客觀效率和主觀積極性重新投入到工作當中—— 這不但是為了員工自己好，對於維持公司的正常高效運轉也頗有幫助。

（據說長期堅持冥想還能提高流感抵抗力，矽星人在此不建議作為 flu shot 替代品。 ）

其實也挺搞笑的：都說矽谷的高端人士喜歡叫自己 hacker ，沒想到當它們工作壓力大了，連自己的神經都敢 hack……

Google 曾經有個職位 「 員工心理健康官 」(superintendent of well-being) ，專門負責管理公司內部 gPause 這樣的正念項目。 這個職位的第一任比爾· 杜恩 (Bill Duane) 在 Google 開了一門課，名字就叫 Neural Self-Hack……

早在 Bill Duane 加入 Google 之前，公司裡就有過一位冥想大師了。 2007 年，新加坡裔員工陳一鳴（Chade-Meng Tan）在 Google 內部創辦了 Search Inside Yourself（探尋你的內心），一套糅合了正念理念的情緒管理免費課程。

前幾年，陳一鳴從 Google 離職，出了一本和課程同名的書。 現在的他，已經成了一名職業禪師，靠賣書、冥想課、付費演講，以及 2000 年加入 Google 獲得的巨額股權回報維生。 他的座右銘：Joy is when you are in deep sit.

在矽谷，員工熱衷於正念、冥想的科技公司不止 Google 一家。

位於倫敦市主教街的「蒼鷺塔」是英國首都最高的建築物之一。 而在這座高樓景色卓越的三十層上，坐落著 Salesforce 為員工設立的冥想間。 員工可以在這間房間裡進行冥想，或者只是為了逃避辦公室裡的壓力，來這裡靜修一小會也可以。 因此，任何人在房間裡都不得使用手機和筆記本電腦。

遵照公司的創始人兼 CEO 馬克 · 貝尼奧夫（Marc Benioff）的意願， Salesforce 在舊金山總部等全球較大的辦公室裡都設有冥想室。

貝尼奧夫本身就是一位佛教徒和禪修愛好者， 1999 年從甲骨文離職後，先是去了夏威夷進行正念訓練，發現不夠過癮，於是跟一位朋友直接飛去了印度，拜訪了許多的印度教靜修處，接受大師的教誨。 這一趟大師之旅過後，他「帶著對自己，對網絡行業，特別是對『軟件即服務 (SaaS)』更清晰的認識 」 回到了舊金山。

（不但成就了蘋果創始人喬布斯，居然還能在 SaaS 這麼具體的領域給貝尼奧夫提供指導 …… 印度可真是個神奇的地方。 ）

因為禪修的時候不讓用手機，我們好不容易找到了這樣一張貝尼奧夫參禪的照片：

他說，禪修讓他獲得了一種初學者的心態，讓他可以改進管理風格，加強傾聽。 這種心態告訴他我退後一步，這樣我才能創造出我想要的，而非過去已有的東西。 我知道未來不等於過去。 我知道我必須處在當下。

雖然有點聽不大懂，但是創辦了千億美元市值公司，自己淨值高達 67 億美元（約  2010 億台幣）的人，說話總不會錯的。

如果說貝尼奧夫是矽谷處在冥想的最高段位，那麼 「PayPal 黑幫 」 成員之一，傑克 · 多西（Jack Dorsey）可能不同意。 畢竟，他送給自己的生日禮物，就是去緬甸久負盛名的苦修所進行了為期十天的內觀久坐苦修（Vipassana）。

和內觀久坐相比，科技公司的 「 每天冥想五分鐘 」 簡直是請客吃飯。 多西採取的這種苦修方式，要求他「消除對於快感的渴望，直接面對痛苦」。

他去的是緬甸的 Dhamma Mahimã ，這是一座免費的苦修所，位於曼德勒省的山城彬烏倫。 多西分得一間只有床和廁所的小屋，苦修期間的大部分時間他都必須呆在裡面，不能讀書、寫字、與他人說話，即便打飯時也不能發生眼神交流。

他必須在早上四點起床，然後進行長達 17 個小時的內觀久坐訓練，長時間雙腿盤坐，每天只有 45 分鐘休息的時間——以走路的方式。晚上九點，他就要躺在床上直到明天四點，循環往復。他還去到了洞穴裡打坐，出來後數了全身有 117 個蚊子包。

他的手機只在拍照時打開， 用來檢測心率的 Apple Watch 也必須保持飛行模式。就在這間小屋裡，這位 Twitter 的創始人兼 CEO 從 2017 年聖誕節一直苦修到 2018 新年之後。現在，他晚上睡覺的心率可以保持在 40BPM 以下。

他說，這次 苦修是他長達 20 年來堅持冥想的巔峰，是一次「對心靈最深層次的破解和重新編程。」（hack the deepest layer of the mind and reprogram it.）

工程師就是工程師，再怎麼苦修，說話方式還是工程師……

有了貝尼奧夫、多西這樣的大佬，矽谷科技行業刮起一股冥想的熱潮就很容易理解了。

曾幾何時，中國的科技人士去加州拜訪，在矽谷公司裡看到沐浴間、午休房和母嬰室感到很神奇，把這種公司文化帶回了自己的公司； 而現在，蘋果、微軟 Twitter 、 Salesforce 、 Google 、LinkedIn 、雅虎、思科等矽谷和美國知名科技公司，都在貫徹冥想的潮流。

那麼，中國科技公司要不要在樓層裡多開一個冥想室？

面臨著工作壓力的不僅網路科技從業者。

現在，整個美國都掀起了一場冥想運動，流行程度已經直追瑜伽，甚至有趕超的態勢。

上面這段不是我在冥想時候想到的，而是事實。  來自於美國衛生部的數據 顯示：2012 年全美成年（下同）冥想者總量大約 1300 萬人，佔成年總人口的 4.1%（同年瑜伽修道者的比例是 9.5% ）；而截止至 2017 年，冥想者的比例翻了兩倍還多，達到了 14.2%，只比瑜伽修道者低  0.1 個百分點。

這份報告將瑜伽、冥想和按摩這種定義為 「 補充醫療方法 」（complimentary health approach）。 報告指出，「在 2012 年，瑜伽和按摩受歡迎程度相仿，之後才是冥想，排在第三； 然而到了 2017 年，冥想的普及程度已經超過按摩，第二大補充醫療方法 」 。

權威市調機構益普索的調研顯示，美國瑜伽產業每年的產值高達 168 億美元（約 5179 億台幣）…… 冥想是否也有如此大的市場機遇？ 還是說，這種修行更像是多西那樣，應該從簡，而非入奢？

顯然，在如雨後春筍般誕生的冥想創業公司看來，任何東西都有可能變成生意。

數據可視化服務 Quid 統計 ，從 2012 到 2016 年之間，僅僅在冥想 / 正念領域就有  142 家新公司成立 ，子領域包括冥想輔助 app 、實體店和社交網絡等，總融資規模超過了 2.6 億美元（約 80 億台幣）！

這份報告顯示， Y Combinator 、 HealthX Ventures 、 500 Startups 等創投機構是這股冥想潮流的主要推手。

就以創業學校 + 投資機構 Y Combinator 為例，從這裡畢業的冥想 / 正念類公司，有 2015 年的 Spire （智慧硬體）、 2017 年的 Simple Habit （課程 app ）、 2018 年的 Modern Health （綜合平臺）。

其中， Simple Habit 是時下最熱的冥想類 app 之一 ，  號稱「the Netflix of mindfulness」，上過蘋果的類別榜首和月度推薦 app 名單，也拿過 Google Play 2017 年整體和 2018 年幸福類 app 的最佳。

創始人 Yunha Kim 曾經是斯坦福  MBA 學生，只用了一天時間就決定輟學創業。她的公司成功從 YC 畢業，還在 2017 年上過 ABC 的著名創業類節目《創智贏家》（Shark Tank）。 截至去年年底，Simple Habit 用戶量已經接近 300 萬，平均每週新增 3 萬註冊。 公司目前已經完成三輪融資，總計 1,260 萬美元（約 3.8 億台幣）。

但如果從融資的維度來看，Calm 無疑才是冥想/正念類創業公司裡的龍頭老大，已經完成了四輪總計 1.16 億美元（約 36 億台幣）的融資，估值 10 億美元（約 308 億台幣），正式加入獨角獸行列。Calm 的投資方包括德太投資成長基金、Insight Venture Partners、AngelList 等。

Calm 算是 Simple Habit 的老前輩和模仿對象， app 內置了大量幫助冥想、睡眠的內容和功能，包括超過 100 節冥想指導、舒緩心情的背景音樂、睡前故事，以及 「 世界級冥想大師 」 製作的高端課程等等，用戶可以支付 $60（約 1800 台幣）年費，或者 $400 （約 1.2 萬台幣） 成為終身會員。

另一家冥想 / 正念領域的知名創業公司是 Headspace，和前面兩家公司的產品形態和商業模式大同小異，目前已完成 B 輪，融資總額 7,520 萬美元（約 23 億台幣），估值目前未知（ A 輪估值 2.5 億美元，約 75 億台幣）。 其他同類公司還有 Happify Health、Grokkar 等。

算上這些頭部的 app ，到應用商城裡隨便一搜，正經的冥想 / 正念類 app 至少有 50 個。 看來，熱衷正念、靈修的並不僅僅是年輕人的團體。 現在，冥想，以及「冥想創業」，已經成了一股真正的矽谷熱潮。

你看，過去矽谷科技公司發明了茫茫多的 app，前仆後繼地爭奪你的時間和注意力，摧殘你的心智……忙到以至於他們自己的時間和注意力都不夠用了。

現在，他們又想來幫助你恢復心智了……

（本文經合作夥伴 品玩 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈“冥想”怎么就成为了硅谷热潮？〉。）

活在矽谷壓力大？

給工程師的職涯警惕：矽谷工程師平均年齡只有 30 歲，老工程師去哪了？

「去矽谷面試最糟的經驗是什麼？」工程師匿名揭露矽谷徵人的黑暗面

蘋果盛世之下的黑暗面，矽谷種姓制度縮影的神秘辦公室「Black site」

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

在台灣，英語是求職的必備技能，考張金色多益證照也是許多台灣人的目標。但現在居然有軟體公司，在徵才條件寫下「英文能力愈差愈好」，還要求應徵者附上多益、雅思分數，證明自己英文有多「爛」。

水文資訊徵求工程師，要求英語能力「不要太好」

這間公司叫 水文資訊 ，根據他們在 104 上的描述，是一間專做軟體研發與整合的小型公司，主要為醫療、建築、連鎖店等客戶提供 RD 相關服務。近期，他們在招募 網站前端開發工程師 。

科技產業是變動相當快的產業，因此會要求工程師具備優秀的英語能力，以追求國外最新科技趨勢，可以讀懂國外的技術報告等等。然而，水文資訊卻特別要求應徵者的英語能力「剛好可以看懂原文技術文件就可以，口說最好愈爛愈好」，還要附上多益、雅思分數證明自己的「菜」英文，「成績越好，錄用機會越低」。

水文資訊：不希望工程師跳槽

至於原因，水文資訊坦白表示，不希望工程師跳槽到像 Google 這樣的頂尖科技公司，希望員工可以留下來穩定發展。薪資方面，水文資訊也講得很明白，比不上 Google ，但也不差，跟台灣同業比算是有競爭力。水文資訊也願意每年透過加薪、升職等方式，讓工程師願意留下來。

以水文資訊正在招募的 網站前端開發工程師 職缺來看，他們開出 80,000 到 120,000 元的月薪，待遇並不差，加上英文「不需要太好」，因此應徵者眾多（104 網頁顯示：30 人以上應徵）。

現在全世界的人多有這種思維：「英文是求職必備能力」、「英文能力愈好，機會愈多，薪資愈高」，但水文資訊的徵才條件要求卻顛覆這種思維。這讓人注意到，有很多工作，英文能力並不是必要配備，具備該職位所需要的技能，性格與企業文化相合，適才適所才是求職與徵才的重點。

參考資料來源：
1.《癮科技》：〈104 出現徵求英文能力不強的軟體工程師 怕以後跳槽到頂尖外商 〉
2.《104 人力銀行》：〈 水文資訊有限公司 〉
（本文提供合作夥伴轉載。Pxhere CC Licensed）

延伸閱讀

多益、托福走入歷史？英語的國際地位受到人工智慧和中文挑戰
什麼是複雜度分析？給工程師的寶可夢演算法指南，面試前讀熟它就贏啦
想當資深工程師？你需要熟悉這 3 種資料結構

【為什麼我們要挑選這篇文章】要如何成為數據科學家？國外有人在 Github 上分享了成為數據科學家的學習路徑，被大家狂按讚瘋傳。下文，是該篇學習路徑的中文翻譯，提供想當工程師，或是想進深程式實力的朋友參考。（責任編輯：郭家宏）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

試圖入門一個新專業時，多數人會感到不知所措；這時候，一份明確的學習路徑可以幫你去除這一焦慮。

數據科學當然也有這樣一套路徑。

一週前在 Github 上出現的一份超高讚數文章就總結出了這樣一份「入門套路」。據這位神秘的發文人所說，數據科學的學習不需要繁雜的準備和高深的數學知識，你只需有足夠的時間、正確的學習方法、對數據分析的好奇心就足夠了。

這個項目是 Github 上一位名為「維吉爾（Vigilio）」的開發者整理的。項目包括職業進階路徑、專業知識講解、工具介紹等，著重強調，不繞遠路，簡明扼要！

Vigilio 表示，這篇文按照層次結構和複雜程度組織編寫，以便讓學習者對事物的運作方式有一個連貫的想法。

另外，他還創了 Facebook 群組，並不斷往上面更新訊息，鼓勵大家一起學習，互相激勵。

5 天前，這份 Github 資料被中國網友 @jiaxianhua 翻譯出了中文版，讓不想費力讀英文的同學也可以輕鬆上手啦。

先附上網址：

github 傳送門
Facebook 社團

下面文摘菌（本文作者）根據這份資料讓大家了解如何高效入門數據科學。

數據科學入門者：學個 Python 吧！

新接觸數據科學需要什麼？當然，Python 這一基礎的程式語言需要掌握。一些數學的基礎知識當然也少不了。如果想進階的話，就需要再學習一些高等的數學知識和高級的 Python 啦！

在這份 github 項目裡，這位外國夥伴給出了基礎 Python 課程以及數據科學 Python 課程。其他的部分，包括高級 Python、高等數學以及數學科學裡的數學知識，目前都還是「即將推出」的狀態。

先學 Python 然後入門數據科學，這絶對是最高效的學習路徑。

在基礎 Python 目錄下，先給出超連結讓你學習基本算術運算和數據類型，然後介紹流程控制，包括 if 語句的使用，for 循環的使用等等。

關於函數的使用，在項目中，作者也給出了一個好的經驗法則是：如果一件事情要重複做 3 次以上，那就寫一個函數吧，並根據你的需要決定調用次數。

除此之外，一些基礎知識也有介紹。包括如何定義函數，如何調用等等。

總之，資料非常豐富，對於一些問題講的不夠清楚的地方也給出了超連結轉到了相應的答案。

完整的學習路徑：專注於 TensorFlow 和 Scikit-Learn

一個專業的機器學習工程師應該專注於 TensorFlow 和 Scikit-Learn。而使用 Scikit-Learn 主要能做的是端到端機器學習項目、線性迴歸、分類、訓練模型、支持向量機、決策樹、整合學習和隨機森林以及無監督學習。

使用 TensorFlow 能夠搭建：ANN – 人工神經網絡、CNN – 卷積神經網絡、RNN – 迴歸神經網絡以及自動編碼器和做強化學習相關的項目。

除了使用這兩個框架之外，一些文章，網絡應用程式，reddit 線程，最佳實踐，項目和 repo 也非常值的看：

數據科學備忘錄
真實數據科學/機器學習項目的集合
TensorFlow 中的課程和 ML 項目的集合
其他 TensorFlow 範例

更多需要收藏以及注意的文章，也可以去 這份資料中 尋找

在學習機器學習時，數學知識應該掌握到什麼程度？正如這份 github 的作者所言：

無論誰告訴你機器學習背後的數學很難…… 都沒有錯！但是你必須考慮到每次你要使用它時，機器都會為你處理它！因此，重要的是掌握主要概念並認識到這些概念的限制和應用。沒有人會要求你手工計算梯度！

註：在路徑這一塊，目前只有機器學習相關資料，商業智慧和雲端計算都是待推出狀態。

專業化：數據的處理與表達技術

這個類別中，目前存在的是數據預處理和有效陳述這兩個項目。同樣，其他的項目包括數據可視化、數據採集等都是待推出的狀態。

關於數據預處理，其實是個疊代過程的收集、組合、結構化和組織數據。目的是為以後的數據可視化，分析和機器學習打下堅實的基礎。

每一個數據科學家或者數據工程師都應該具有篩選和整理數據的能力。不同的數據類型，需要做出不同的數據處理。在做數據預處理的過程中最主要是有不要把數據當玩笑的心態。

首先在嘗試數據準備步驟時，先不要處理 GB 級別的數據。只需使用數據的小子集 ，但子集要具有代表性。

在做數據篩選工作時候，需要注意：刪除額外的空格、選擇並處理所有空白單元格、轉換值類型、刪除重複項、將文本更改為小寫 / 大寫、拼寫檢查、處理特殊字元、規範日期、驗證豐富數據、數據離散化、特徵縮放等等。數據預處理是非常複雜的，你的最終目標是做到「自動化」。

然後在數據分析中需要明確：你打算解決哪個業務問題（什麼是重要的，什麼不是）；數據是如何被收集的（有噪音，缺失值……）；你們有多少數據在那裡，我在哪裡可以找到他們？（數據維度和從儲存中搜尋）。

在學習數據預處理的過程中，你可以按順序選擇它們或選擇最適合你的那個，但建議你至少要一次把它們都看完。

總體來說有兩種類型的專業化：硬技術和軟實力。

前者是關於技術流程，是每個處理數據的人的核心工具包。使用數據是一種藝術形式，經驗法則和最佳實踐將幫助你瞭解處理它們的方式。你需要對如何處理數據產生一種「感覺」，這種「感覺」要是由情況和經驗帶動的。

後者是真正的價值促成者。如果有了軟實力，你可以成為世界上最好的開發人員或工程師，但如果你無法向受眾傳達你的建議和觀點，或者使用數據來建議企業如何做決策，那麼你對公司來說就毫無用處。

在向受眾傳達建議和發現時，需要的架構包括：設置、故事、情緒和感覺（你需要在你的受眾中重現它們）、結論的動機以及結論。

在說話時候注意使用第一個人，注意修辭問題，表達盡可能的自然，最後給出總結理由和實際建議。

實用工具大集合

在學習的過程中，要熟練的使用 Jupyter Notebooks、latex、Wolfram Alpha 等等。

LaTeX 是一種標記語言（或是如官網所述：用於高品質排版的文檔準備系統），用於創建精采的論文和演示文稿。你在職業生涯中閲讀的幾乎所有論文都是使用 LaTeX 編寫的。

LaTeX 有幾個發行版，打開 此連結 就可以看到

安裝後，你需要一個編輯器來編寫 LaTeX 文檔。可以使用你想要的任何編輯器，包括記事本，vim，nano，gedit 等，但建議你選擇免費和跨平台的 Texmaker 。

另外，推薦 這個網站 ，它允許用戶在線編寫公式，並且還有大量符號，你只需點擊，生成所需的程式碼即可。你還可以預覽公式，以便更容易確保所有內容都正確編寫。

WolframAlpha（WA）是一個計算知識引擎。其具有強大的數學能力，它可以成為一個非常強大的工具來幫助你進行計算。具體的功能包括基本計算、繪圖函數、求解方程、解不等式、矩陣代數、計算級數和、求導、計算積分、求極限等等。

GeoGebra（GG）是一個功能強大的動態數學應用程式，適用於所有級別的教育，它將幾何，代數，電子表格，圖示器，統計和無窮小計算結合到一個易於使用的單一軟體。 GeoGebra 社群正以指數級增長，數百萬用戶遍佈許多國家。 GeoGebra 已成為全球高等數學，科學支持，技術，工程和數學以及教學和學習創新軟體的領先供應商。

教程下載與使用 傳送門

然後是正則表達式，這是一種匹配一種編寫匹配字元串的模式的方法。

使用教程 傳送門

好了，到這裡，這份資料講述的學習路徑差不多全部包含了，還有一個用 DialogFlow 和 Flask 打造 ChatBot 的主題以及讀論文必用的工具—Zotero，感興趣的讀者可以自行探索。

最後，附上完整的路徑圖：

（本文經 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈 Github 标星超 7k！从零开始，最简明扼要的数据科学学习路径（附高效免费小工具）〉 。首圖來源：Pxhere CC Licensed）

更多工程師程式技能包

什麼是複雜度分析？給工程師的寶可夢演算法指南，面試前讀熟它就贏啦
R 語言可用來開發深度學習！不只是統計分析，R 還有這 10 個強大隱藏功能
GitHub 神人整理出一份 Python 開源清單：15 個領域、181 個開源項目任你用

【我們為什麼挑選這篇文章】工程師是台灣市場的稀缺，需求高但供給少。從市場面來看，企業系統走上雲端或導入 AI 做營運轉型，而工廠則啟動智慧製造找解決方案達到高效率、低成本的獲利方式。懂得程式語言早已不再是一個加分題，而是一個必需品。但是只會寫程式是不夠的，那還要懂得什麼？（責任編輯：陳伯安）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至  jobs@fusionmedium.com」

作者：AppWorks School 校長 田育欣

近來台灣的電商、數位服務產業快速崛起，AI 也持續引起各產業革新，各界都需要大量的軟體工程師投入；同時，鑑於台灣軟體人才的素質極佳，相較於其他亞洲區域，有更先進的軟體開發經驗，吸引了不少大型外商，如 Google、Amazon、Microsoft、IBM、Oath 等，或是跨國網路新創，如東南亞最大行動拍賣平台 Carousell、東南亞最大網購現金回饋平台 ShopBack、香港 FinTech 新創 EMQ 等，都紛紛來台灣設立研發中心，大舉招募軟體工程師。

台灣工程師職缺供需失衡

隨著產業轉變，近年來，台灣軟體人才持續供不應求。根據 104 人力銀行的 調查 統計，2018 年 9 月，軟體設計工程師類職群已經超過 21,000 個職缺，較 2017 年同期增加 2,400 個，成長幅度超過一成，然而求職人數卻未見增加，僅小幅成長約 200 人，顯示 台灣軟體人才供給仍遠不足市場需求 ，而且在過去一年來，缺口持續擴大中。

針對台灣軟體人才不足的長期結構性問題，AppWorks 於 2016 年中出資成立 AppWorks School，透過免費、實作導向的密集訓練，幫助非科班出身的年輕人轉職成軟體工程師。AppWorks Schook 創辦剛滿三年，共累計 106 位校友結業，其中有 91 位選擇投入軟體工作，成為數位與軟體產業的開發生力軍，如 91APP、KKBOX、Gogoro、PicCollage、Line TV (原 CHOCO Media) 、WeMo Scooter、巴哈姆特等知名網路公司，都有 AppWorks School 校友的身影， 轉職成功率超過 85%。

在這三年的經營經驗中， AppWorks School 持續在第一線觀察整體產業的人才需求與市場變化，藉此機會與各界分享經驗與培訓成果，期待拋磚引玉，吸引各界更重視培育優質軟體人才的重要性：

兩年內，新手工程師的起薪中位數漲了 27%

在各界爭相競逐之下，軟體工程師無疑是當今最炙手可熱的人才，此強勁徵才需求也反映在薪資水平上。以 2016 – 2018 各年 AppWorks School 校友結業後，第一時間（結業 90 天以內）擔任軟體工程師、並有回報起薪（含固定年終獎金，不含其他業績分紅獎金）的 65 位學員統計：

以起薪中位數來說，2016 年有回報薪資的 13 位校友，起薪中位數為新台幣 55.5 萬元，而 2018 年回報薪資的 44 位校友，起薪中位數則為新台幣 70.8 萬元，2016 至 2018 年漲幅高達 27%。

以平均數來說，若與 104 上新鮮人擔任軟體工程師的最高平均月薪 47,246（公立碩士），並以年終 2 個月來計算，年薪約為 66.1 萬元，AppWorks School 校友則為 71.2 萬元，約高出 7.7%，顯示出 AppWorks School 以實作開發導向的培訓方式，更貼近產業的最新變動，使得學員的能力以及專案經驗，能反映在薪資水準上。

實作能力是關鍵，結訓平均 26 天就找到工作

除了起薪較為優渥以外，多快找到工作？則是另一個衡量指標。從 AppWorks School 結訓第一時間選擇就業的學員，平均只需花 26 天，即可找到適合自己的理想軟體工程師工作，甚至有學員透過徵才企業夥伴，結訓當天就找到工作，相較於平均得投 108 份履歷、待業至少 6 個月的新鮮人（yes123 調查），節省了 86% 的找工作時間。

若探究 AppWorks School 學員受到青睞的原因， 實作能力、專案經驗是關鍵 。與 AppWorks School 合作的徵才企業多表示，由於每位學員均會在學程內完成個人作品，以證明個人的實作能力，並對於實務開發的困難有一定程度了解，相較於以自學程式卻缺乏專案作品的求職者，更具有說服力，而用人主管能從作品中深入了解學員的思考脈絡，也有助於篩選到合適的人選。

以 AppWorks School 第一屆 Front-end Class 的學員 YPO 為例，過去主修物理，第一份工作卻走向印刷，在加入 AppWorks School 前完全沒有程式基礎，結業前夕卻僅花五週時間，就完成一個線上電子鼓編輯器 Beating Line，使用者只要動動手指，就可以創作出想要的樂章。這個作品精緻的介面設計、流暢的使用者體驗，而功能完整性也相當高，讓 YPO 第一時間就獲得不少面試邀約與工作機會，最終選擇加入 Gogoro，成為前端工程師。

入行 21 世紀最性感職位，得先學會 Python

自 2016 年 AlphaGo 打敗李世乭，AI 領域再度興起研究熱潮。各產業開始萌發與 AI 相關的落地應用，市場上相關職缺數量也快速增加，因此吸引不少人投入學習，也使得開發 AI 應用所需的程式語言 Python，成了 2018 年最熱門的程式語言，越來越多年輕人，希望透過學習 Python，一舉成為 21 世紀最性感的 Data Scientist。

然而，AppWorks School 在走訪許多徵才企業後發現，台灣市場上對於 Data Scientist 的期待，除了數據思維、程式能力以外，還需要結合特定產業知識（Domain Know-how），例如醫療、金融、科技製造等，才能找出 AI 適用情境並解決問題。因此，雖然市場上有不少對 AI 應用領域有興趣的新鮮人，具備統計或軟體工程的學術基礎，卻因為缺乏產業知識與專案經驗，不得其門而入，學用之間仍有落差。

為此，AppWorks School 正規劃投入更多資源，將設計專案導向的實作訓練，以銜接供需兩端間的落差，目前已經在招募相關導師，並預計在今年下半年開始招生。

目前 AppWorks School 2019 夏季學期正在招生中，已經享有業界口碑的 iOS、Android、Web Class 熱烈招生中，而未來我們期待透過更多的班次與資源，幫助更多台灣的人才，進入網路軟體的舞台大顯身手，迎接更有前景的職涯。

想要成為軟體工程師？歡迎免費加入 AppWorks School

作者簡介：

Team AppWorks 原生成員，2011 年起以實習身份加入，畢業後升格為投資分析師，而後轉任 AppWorks School 之初學校校長。台大財金系畢，輔 AIESEC 與國標拉丁舞，熱愛舞蹈與所有美的事物。

（本文經投稿作者 AppWorks 授權刊登，並同意 TechOrange 編寫導讀與修訂標題，原文標題為《AppWorks School 三週年系列：軟體工程師越來越搶手！新鮮人年薪中位數破 70 萬，較 2016 年成長三成》。意投稿者可寄至：edit@fusionmedium.com，經編輯檯審核並評估合宜性後再行刊登，首圖來源：Fatos Bytyqi on Unsplash。）

AppWorks 深度好文

【2018 年度趨勢回顧】AppWorks 培養的 328 家新創，哪八家表現最出色？

衝擊區塊鏈新創血淋淋的現實！COBINHOOD 創辦人：區塊鏈應用充滿希望，但太少人使用

盾心科技創業 4 年經驗談：AI 創業選擇太多，該如何避免「走馬看花」的燒財困境？

【為什麼我們要挑選這篇新聞】台灣科技業以硬體製造為主流，軟體工程師也大多投入台積電、鴻海、大立光等公司。軟體工程師的職涯路還有哪些可能？

AppWorks School 創立已三年，提供免費的實作課程 ，培訓軟體工程師人才。近期他們追蹤其中三位校友，藉由他們的故事，讓軟體工程師們看見更多的職涯可能。（責任編輯：郭家宏）

作者：AppWorks School 校長 田育欣

隨著數位浪潮、Mobile Internet 深入每個人的生活，軟體服務產業正在快速崛起，軟體工程師可說是當今最炙手可熱的人才。但由於長期以來，在台灣以科技製造為主流的產業結構下，軟體人才大多投入硬體產業服務，各界對軟體工程師的職涯發展，較少關注與探討。

AppWorks School 過去三年來，持續提供免費、實作導向、密集培訓的課程，幫助非科班出身的年輕人，轉職成為軟體工程師。至今結訓 的 106 位校友中，已有 91 位投入軟體領域，加入如 91APP、KKBOX、Gogoro、PicCollage、WeMo Scotter 等網路公司，後續不乏被拔擢為 Team Leader 的案例，也有人走向海外工作，甚至有人走上創業這條路。

今天我們挑選三位校友的故事與外界分享，希望幫助各界對軟體程式有興趣的人，看見更多具備軟體開發能力的職涯可能：

兼備技術、商業思維與整合溝通，兩年內晉升新創 Backend 團隊負責人

從新進人員升遷為部門主管，在大企業裡，可能要花至少 3-5 年時間，才有機會展露頭角；但以快速成長的軟體企業來說，舞台很大、機會很多，軟體工程師若是能展現領導潛力，可能在 2-3 年就被拔擢為要角。

AppWorks School 第一屆校友張瑋康，就是一例，從 AppWorks School 畢業後，靠著自己持續自學與努力，以不到兩年的時間，就成為 CHOCO TV 的 Backend 團隊負責人。

張瑋康大學唸的是商管科系，卻總嚮往電腦與網路的世界，曾自己嘗試 VM/VPS 架設與運營網站、輔修資工系課程、學習電腦網路基礎知識，而為了更貼近結業界實務，他選擇在服完兵役後申請加入 AppWorks School。

在 350 個申請者、競爭相當激烈的第一屆 iOS Class 入學申請中，他是少數談到程式與網路，眼睛會閃閃發亮的人，而期盼找到軟體技術落實在商業應用上強烈動機，也相當符合許多網路新創公司的徵才條件，因此成為 AppWorks School 的學員之一。

在 AppWorks School 期間，張瑋康學習的是 iOS App 開發，並在結業後加入一個新創團隊，擔任 iOS Developer 的工作。但他仍不滿足於此，在工作之餘持續學習網路與雲端伺服器等後端開發知識，接案與知名 IG 部落客實作出一款「午餐吃神馬」的 LINE 聊天機器人，上線不到 24 小時間，就累計有約 3,000 人次使用，更也因為這個後端作品，讓他受到巧克科技新媒體的青睞，拿到後端工程師的 Offer。

加入巧克科技新媒體後，張瑋康的壓力才真正展開了，因為當時巧克科技新媒體旗下主要營運的產品為 CHOCO TV，在後端開發者人力有限的狀況下，要負擔來自 iOS、Android 與 Front-end 其他開發人員的需求，並承擔上百萬月活躍用戶的觀賞體驗，這是相當具挑戰的任務。但他並沒有把龐大的工作量視為負擔，反而視為絕佳的成長機會，因此當時除了每天工作 8-9 個小時外，下班後還會廣泛閱讀技術文件，將 Amazon 雲端服務 (AWS) 的白皮書翻得透徹，最終在產品使用者越來越多，後端伺服器一次一次突破流量乘載極限下，自己的實力也跟著不斷成長。這樣積極的投入與快速進步，很快地引起主管們的注意與肯定，而他更因為出色的溝通、協作能力，被拔擢為 Backend 團隊負責人，帶領其他技術年資更長的後端開發同事。

張瑋康的直屬主管、也是巧克科技新媒體的共同創辦人翁瑞庭形容：「Wei（張瑋康的英文名字）對於任何挑戰皆充滿熱情，亦會利用下班時間加強自身不足處，於短時間內不斷成長，這樣的人才，正是處在快速變動環境下的新創團隊所需要。從 Wei 身上，我依稀看到了自己的影子。」

接任 Backend 團隊負責人後，張瑋康很快又面臨到公司的重大轉變，LINE 投資巧克科技新媒體，並將 CHOCO TV 整併為 LINE TV。這意味著會有更龐大的用戶加入使用平台，後端架構是否能乘載又是另一個重大的挑戰，所幸有先前打下的扎實基礎，以及開發同事們全力協助，整個導入專案於去年底順利完成。

回首這段歷程，張瑋康對想踏入軟體領域的新人說：「現在缺工程師，更缺同時具有技術深度、商業創造力、溝通整合能力的人才。如果對於軟體工程師職涯有興趣的朋友，在培養技術能力之餘，也可以同時思考目前日新月異的產業與技術對於公司、商業與使用者能夠帶來什麼價值、解決什麼問題，並進而在工作的日常上發揮影響力。」

投入網路創業，兩年內成長至 14 人團隊，累積 40 家企業客戶

對於想投入創業的年輕人來說，軟體服務創業可說是最輕資本、風險最低的一條路，一台電腦就可以開始動手。即使在團隊成長過程中，個人角色要從技術開發轉向管理營運，但因為擁有技術背景，在團隊溝通與領導上，也能起到相當大的效益。

AppWorks School 第二屆 iOS Class 的校友黃紹航，就與同班同學于謹嘉一同創業，共同創辦 漸強實驗室 ，提供 LINE 廣告與訊息優化解決方案，兩年內累積 40 家企業客戶。

黃紹航大學主修工業工程與管理，是在投入產品設計領域，以 UX Product Manager 的身份，參與過 IoT 產品開發的工作後，才興起轉換跑道的念頭，想要往能夠更快速、更直接面對使用者的軟體領域發展。在猶豫自己到底要先成為軟體工程師，還是直接投入網路創業下，他選擇申請 AppWorks School 這個可以扎實學習軟體開發，又最接近網路新創產業的地方，希望在半年內快速累積網路與軟體產業的知識。

抱著明確的目標，黃紹航在課程中，非常勤於做筆記，將 AppWorks School 邀請來每一位講者的分享內容，都條理分明的記下，更善於消化資訊後提出更深的討論，正是如此認真又具有洞察力的特質，吸引了同班同學謹嘉，兩人決定在結業第一時間便一起創業。

創業說起來很容易，兩個人卻一開始就碰到發想創業題目的問題，找不到兩個人都有熱情想投入的題目。剛好在朋友薛覲的介紹下，開啟了「社區阿伯」這個 LINE Bot 專案，開發 LINE 機器人來做社區管理。無奈由於第一階段開發告一段落後，客戶無法立即投入更多資源，使得團隊看起來沒有發展的可能，于謹嘉也因為個人考量決定離開，這條創業路看起來又蒙上了一層灰，前途晦澀不明。

但黃紹航沒有因此放棄，他決定和薛覲繼續承接專案、開發其他社區管理的需求，運用半年的時間，一邊找尋願意全職加入的工程師夥伴，直到在 2017 年中，才正式成立漸強實驗室 ，由薛覲擔任商務開發，黃紹航擔任產品管理的角色，三個人的團隊，將本來的社區管理 LINE Bot 架構，化成可提供品牌商家創建推播廣告的模板服務。

在找了幾家 Pilot 客戶後，他們發現除了廣告模板外，商家更需要的是訊息所觸發的行為追蹤與成效評估，因此推出第三代產品，讓品牌主可以更有效追蹤每一則 LINE 推播的廣告成效，並自動化地推送與使用者相關的訊息，才成功簽下如中國信託銀行、淘寶網、SkyScanner 等大品牌客戶，並快速推展至 40 家企業客戶使用，公司也在短短一年間從 3 人成長到 14 人的規模。

回顧這兩年，黃紹航認為在 AppWorks School 受到的軟體開發訓練，讓漸強實驗室即使沒有 CTO，他也能勝任規劃產品藍圖、帶領開發團隊的工作，能夠與工程師有效的溝通；在 AppWorks School 與許多新創團隊建立的連結，後續也在創業路上有所幫助。

對於想加入軟體創業的年輕人，他分享：「原以為登記公司、簽下第一個客戶、拿到天使投資等事件，就是代表成功關鍵的里程碑。但其實每一天都是關鍵的一天，每個里程碑背後代表著更多的責任，將沒有停下來的一天，卻也非常充實。如果你也認同這樣的體悟，歡迎踏上軟體創業這條路。」

憑技術力走出台灣，遠赴捷克挑戰海外工作

軟體浪潮不只在台灣發生，全世界各地都需要軟體工程師來創造新的服務與改變，程式開發技能這項「可以移動的專業」，正適合想要到世界舞台歷練的人。AppWorks School 第五屆 iOS Class 的校友李宜芳（下圖左三），則選擇前往捷克挑戰。

李宜芳是位熱血的高雄人，總是滿臉笑容像南台灣的太陽。因為熱愛動物，她大學主修的是動物科學，卻在畢業後於醫院擔任研究助理期間，面對得親自操作動物實驗的工作，內心開始產生強烈的矛盾與衝突。在工作一年半後，她決定重回校園研讀生物資訊研究所，轉向資工領域的研究，她在軟體領域的起點，是從抱著一本外文課本，學習 C++ 開始。隨後在碩士論文的需求下，開始自學影像處理與機器學習，最終完成用醫學影像預測大腸癌化程度的結果。

在完成碩士論文後，她前往捷克 Brno University of Technology 擔任交換學生，並在交換期間遊歷歐洲，感受到世界廣大，希望讓自己擁有更多海外經歷，因此心生想要出國工作的念頭，所以就在當地開始嘗試投履歷、找工作。

即使有碩士論文的專題經驗，但當時的求職並不順利。她說：「可能是因為不是本科系畢業吧？或是也沒有真正的軟體經歷，像 Web 或 App 作品。」她開始找尋其他可能性，發現到 iOS App 開發其實不在資工系的必修範圍，而且又有較高的學習門檻（需自備 Mac 筆電與 iPhone），因此市場上的人才供給較少，所以她決定學習 iOS 開發，而在找尋相關學習資源下，發現了 AppWorks School 就毅然提出申請，加入當時女性限定的第五屆 iOS Class。

有著強烈想要出國工作的動機，也害怕自己會隨著年紀（當時 27 歲）增長而降低出國可能性，李宜芳非常積極利用在 AppWorks School 四個月的時間，開學一週後索性就帶了一條棉被就住在 AppWorks 附近，以便晚上可以 Coding 到很晚，省下不少交通時間。而這樣的努力，也轉換成實際的學習成果，帶著精緻的作品 Hooman Talk，她在 AppWorks School 安排的工作媒合活動下，就收到了七家合作企業的面試邀請。

最後她選擇回到南部，相繼加入 Prenetics 與 KKSTREAM 等軟體公司，但前往海外工作的心願一直沒忘。總算在 2018 年 9 月，收到來自捷克的大型專案公司 STRV 的 Offer，並於 12 月辦妥簽證後，歷經了 16 個小時的飛行抵達布拉格，才正式開始這趟海外工作之旅。

才一上工，她就明顯感受到新的工作環境比台灣更自由、更彈性，沒有上下班時間的限制，但每位同事都非常自律，即使公司無限供應啤酒，但沒有任何人會在工作時間喝，專案開發上井井有條。她說：「這裡的 Code review 很嚴格，常常寫完一段程式碼，提交後會收到 50-60 個 Comment，都是同事們建議怎麼寫會更好。」即使改變程式寫法不影響產品的畫面或功能，但這些建議背後，代表的是軟體人對程式碼品質的堅持。除此之外，還有不時和資深工程師 Pair Programming 的機會，能近距離學習他們的開發方式，讓她加速成長。公司也相當鼓勵工程師參與社群聚會，還會輔導工程師上 Conference 演講，真切關心每個人的成長。

在經歷幾個月的洗禮後，對於也嚮往海外工作的軟體開發者，李宜芳認為：「若英文有一定的基礎，技術經歷不一定要非常資深，每個人都可以勇敢挑戰看看，有機會就出發吧！」

想要成為軟體工程師？歡迎免費加入 AppWorks School

作者簡介：

田育欣：Team AppWorks 原生成員，2011 年起以實習身份加入，畢業後升格為投資分析師，而後轉任 AppWorks School 之初學校校長。台大財金系畢，輔 AIESEC 與國標拉丁舞，熱愛舞蹈與所有美的事物。

（本文訊息由 AppWorks 提供，內文與標題經 TechOrange 修訂後刊登。新聞稿 / 產品訊息提供，可寄至：pr@fusionmedium.com，經編輯檯審核並評估合宜性後再行刊登。本文提供合作夥伴轉載。）

更多 AppWorks 深度好文

【2018 年度趨勢回顧】AppWorks 培養的 328 家新創，哪八家表現最出色？
AppWorks 啟動內部晉升計畫！培育年輕接班人，31 歲合夥人史上最年輕
AppWorks 為何專注培訓 AI、區塊鏈新創？創辦人林之晨：未來的創業風口就在這！

【為什麼我們要挑選這篇文章】996 是最近中國很熱門的用語，意指從早上九點上班到晚上九點，每週六天的爆肝生活，而工程師更是 996 職業的代表。因為軟體業步調快速，加上工作壓力大，所以工程師大多做不久，但還是有些工程師可以做超過 20 年，並在工作與生活間取得平衡。他們是怎麼做的？（責任編輯：郭家宏）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

「加班 996，生病 ICU（加護病房）。」

這是一句最近攪亂了很多工程師平靜生活，也讓所有的「社畜」認真反思人生的話題。但是，讓工程師們真正感到焦慮的其實並不只是工作的壓力，更多的是對未來的迷茫：超負荷工作必然導致學習和自我提升時間的縮短，那麼熬過 30 歲，一旦拚命的資本不再，他們又能何去何從。

40% 以上的工程師資歷不到 5 年

Stack Overflow 近期剛剛發佈了 19 年的工程師普查報告，在這份近萬人參與的調查中，40% 以上的工程師碼齡不到 5 年。

報告 傳送門

是的，軟體行業非常年輕，因為工作強度大和收入比，很多公司都傾向於雇用「廉價的年輕人」。這就讓工程師們的工作壓力普遍很大。

上個月文摘菌（本文作者）也發了一篇「老程序員都去哪了？」的文章（繁體中文版可參考： 給工程師的職涯警惕），評論中能看到很多工程師的焦慮：

「工程師真的都應該 996 嗎？」
「工程師和空姐一樣，吃的都是青春飯。」
「一直寫代碼，沒有時間學習提升，難道要寫到 40 歲嗎？」

的確如此嗎？老工程師到底都去了哪裡呢？

於是，我們決定去採訪幾位「對自己目前的工作生活還算滿意」的老工程師，看看他們的職業生涯中都經歷了什麼，以及現在的生活狀態是什麼樣的。希望他們的故事，可以給年輕的工程師們一些建議和啟發。

趙先生、黃大叔和 Bryan 是最讓文摘菌印象深刻的，他們都是碼齡超過 20 年的「老」工程師。雖然學歷背景、工作地點和職業狀態千差萬別，但是他們又有一些共同點：都是因為興趣選擇了這份職業，也因為喜歡， 一直堅持！

趙先生從 16 歲開始寫下了第一行程式碼，一直堅持到現在；Bryan 雖然已轉型公司高管，但提起寫程式還是非常有熱情；從業 20 年的黃大叔已經開始了他的創業之旅。對於工作、加班、生活他們有著自己的看法。

我們一起來聽一聽。

興趣是最大的動力，最佛系的「天才」工程師

趙先生
年齡：43 歲
碼齡：25 年以上
目前職位：新創公司技術總監

作為一名 70 後，趙先生給文摘菌最深刻的印象是「天才少年」啊！

趙先生回憶，他第一次接觸到程式碼是在初中（相當於台灣的國中）的時候。當時，剛剛十多歲的他在同學家看到一個工程用的印表機，可以寫一兩行程式碼。因為特別感興趣就模仿著說明書寫了幾行程式碼，那時候用的還是 Beta 語言。

高中之後，趙先生就開始利用學校的電腦自學程式，還曾因老師阻撓低年級的自己學程式，一氣之下直接拿了自己所在城市高中電腦大賽第二名。接下來還代表學校參加省級比賽，拿了兩次省一等獎。

後來，「不務正業」的趙先生還輕鬆考上北京郵電大學，但是轉學了通信工程專業。他表示之所以沒學電腦， 是因為「寫程式太簡單了，就不需要專門去學了吧」！

之後，趙先生也就成為了當時北郵通信工程專業裡大名鼎鼎的「最會寫程式的」工程師。

職業生涯：

畢業後，趙先生去了一家國務院國資委直屬的大型高科技央企（中國國有企業的一種），主要做硬體相關的工作。

後來因為有同學創業，便辭職去開發手機遊戲。趙先生職業生涯中主要使用 Java 作為程式語言，至今還是使用 Java。不像現在的年輕人每天焦慮地思考學 GO 語言還是學 julia，趙先生很佛系的表示，也沒有想過學其他新的語言，夠用就行了！

當然，趙先生的身上也有著 70 後特有的對自己「往日時光」的懷念。整個佛系平靜的採訪過程中，趙先生的聲音也只在這個時候透露出了一點「激情澎湃」的味道。他回憶道，比較難忘的還是在那個手機硬體性能比較差勁的年代，寫一個遊戲，程式、圖片和文字加一起也不能超過 64K， 對工程師的考驗還是很大的。

目前的趙先生在一家新創公司當技術總監，管理著一支小的技術團隊，但是自己仍然會親自寫程式。最近工作比較忙， 雖然過著 955 的生活（每天從早上九點上班到下午五點，每週五天），但回家後還是會繼續工作，時間比較有彈性。趙先生也表示，自己其實也挺喜歡在家工作，還曾經專門辭職兩年在家照顧孩子和家人。

對於是否考慮轉行，他表示目前的生活狀態很好， 並不是很想轉行甚至都不想換工作，也沒有想過自己創業， 不想去管理程式以外的事情。

他說：工作嘛，都是為了生存和賺錢，任何工作做久了也都會無聊。因為自己對寫程式比較感興趣， 就這麼堅持下來了！我不喜歡規劃自己的生活，對自己要求也不高。有自己的時間做自己喜歡的項目就好了！

給年輕工程師的建議：

工程師就是一份收入稍高點的工作，如果是喜歡就一直做，如果不喜歡， 過幾年轉行做管理或者自己創業都可以。分清楚工作與私事，賣命要賣的有意義！

從沉迷遊戲的「網癮少年」到管顧公司 CEO

Bryan
年齡：43 歲
碼齡：20 年
目前職位：Technology Consulting – Managing Director

Bryan 的下屬們可能都想不到，高冷的「霸道總裁」小時候也是個「網癮少年」。

Bryan 走上程式之路和很多少年一樣，小時候和高中同學一起沉迷遊戲，家裡親戚送了一台電腦。可是電腦總是出問題，所以就開始學習如何自己修電腦。

後來高中畢業報考大學時就自然而然地報了電腦科學。就喜歡拿不同語言輪流搭建遊戲什麼的。作為週末 java 愛好者，下班後邊看電視邊寫程式就當放鬆了。

「一路走過來都是因為愛好」Bryan 說。

職業生涯：從工程師到管理高層

目前 Bryan 在倫敦一家管顧公司做技術諮詢，擔任高管。他認為做技術管理者比做純技術菁英要有趣。當工程師的時候也不覺的有很大壓力，純屬個人愛好， 每天都很有動力。

「其實我一開始也沒想過要轉管理層，但是隨著每一次的升職考核，你會發現一些技術以外的能力變得更加重要。比如是否有能力帶新人，帶領團隊，對於專案的資金與營運的理解有多深等等。」

Bryan 稱，當年也可以選擇走純技術路線， 但我不認為純做技術可以做到首席執行長。我認識一些真正聰明又勤奮的技術神人，他們在一些細項領域非常的專業。這些人無論年齡多大，都會是公司寶貴的資產。

做管理並不代表完全不做技術，平時 Bryan 也很喜歡和公司的年輕同事們一起寫程式、debug。Bryan 稱，自己還是會不斷學習、隨時擴充自己的知識庫。不然就會被年輕人電，他們工作偷起懶來也會更容易吧！偶爾他們搞不定的地方還是需要自己上手。

Bryan 表示，身為一個管理者，你需要知道如何給團隊劃分任務，如何評估成員的技術水平，出了什麼方面的問題找誰解決最有效等等。相比於純技術， 現在的職位更看重團隊領導力， 客戶關係管理和商業洞察力等等。做管理讓自己能夠對業務有更全面的瞭解、認識更多有趣的人，學到更廣泛的知識。

Bryan 也感嘆現如今女工程師越來越少，二十年前剛入行那時，很多女工程師都很厲害。雖然都是好朋友，但競爭還是很激烈，每天都想把對方比下去。但現在他們大多都去做管理或者去了學校，做到中層的女工程師幾乎沒有， 這也是值得我們思考的。

775 的工作制

雖然現在大家都在抱怨 996，但 Bryan 一直堅持 775（從早上七點上班到晚上七點，每週五天）。之所以不從 9 點開始，也是覺得那兩個小時不是打瞌睡就是在看報紙玩手機中度過，還不如早點開始抓緊把活幹完。

或者也有可能是家離公司近吧。

Bryan 說：我的週末從來都是完完全全屬於我自己的，你需要給自己劃定一個結束工作的時間點，在截止時間點前認真工作，所以我的工作效率很高。把自己份內的事情全力以赴的做好，對於別人麻煩你的事情也要懂得有底線的拒絶。

專案不忙的時候都會接送孩子們上下學，工作和生活的平衡還是自己的選擇。

給年輕工程師的建議：

雖然現在科技行業非常火熱，但我還是建議大家不要盲目擇業，要根據自己的興趣愛好來選擇。

也不要指望工作會幫助你快速成長，絶大多數工作都不會，很多知識技能都是工作之餘學習的。

跟一個好團隊，然後到成為一個好老闆

黃大叔
年齡：40 以上
碼齡：20 年
目前職位：新創公司技術顧問

文摘菌當然也認識很多年輕的工程師朋友，採訪黃大叔是因為其中一位年輕有為的工程師朋友的推薦，「他是我遇到過最棒的工程師上司了」。

能讓一位優秀的工程師心服口服，那這位黃先生一定還是很有兩把刷子。

初遇黃先生，他就很親切的跟文摘菌說，叫他「大叔」就行，而相比很多剛剛入行的小鮮肉碼農，黃大叔身上也多了一分沉澱後的從容溫和。

當然，每一個大叔身上也都有屬於自己的入行時刻。2000 年畢業時， 一次機緣巧合， 學機械專業的黃同學寫了一道 C 語言面試題， 就這麼被錄用了。他清楚的記得，他是當天最後一個面試者。

黃先生回憶說因為上大學時期對程式感興趣，雖然系上沒有相關課程，但自己一直很努力地自學，沒想到就這麼入行了！

職業生涯：從工程師轉型管理者，一步步走上創業之路

很多人都說，第一份工作很重要，跟對一個好團隊更重要。這句話作為黃先生職業生涯的開端在確切不過了。

他說：我很幸運的加入了一家還不錯的公司，跟了一個在美國工作十幾年的老闆。在 20 年前，公司購買正版的 windows 系統還是很罕見的，並且有完整的研發理念和管理系統，專業的測試員等等。自己在公司一般是獨立完成專案。第一個專案，老闆丟下「有什麼地方調不通就用 printf」，就跑去美國。自己摸索著調試所有的 BUG，重新梳理結構化程式碼，用兩個月把這個枯燥的印表機驅動程式成功交付給客戶。作為非專業的碼農，這背後的艱辛讓自己快速成長。

兩年後， 他成為這家公司最後一個離開的工程師。

在 2006、2007 年的時候因為工作去了美國。在那裡，他遇到了很多有經驗的老工程師， 不少有經驗的工程師都超過 40 歲，還能輕鬆搞定核心程式碼。

而現在國內公司不考察人，只是簡單「消滅」35 歲工程師的做法有點不可思議。大叔最近在招募時發現，6 到 7 年碼農的薪酬期望最高，也最搶手。但面試中，不一定比工作 10 到 12 年的碼農溝通好和技術紮實。

從美國回來後，逐步轉型技術和管理，團隊人數超過百人。談及最近很夯的 996 事件，大叔很不以為然。選擇一個自己喜歡的工作，這和打遊戲沒區別，從來沒在意過是否 996。加班更多的是個人選擇。人類歷史上有比 IT 發展更迅猛，變化更快的行業？

關於加班，大叔還有了一個有趣的觀察。

他說：當年很流行一句話：「我很討厭我的老闆在 6 點的時候來找我安排事情，這不是明擺著暗示我要加班？」大叔作為管理者後發現，經常會有人在 5 點到 6 點的時候，著急地找大叔解決各類棘手問題。如果這時候立即安排其他人手，這些人「勢必」加班。

黃先生給出了自己的兩種解決方案供管理者參考：
1. 搞清楚原因，如果不是非常緊急，安排第二天解決。
2. 瞭解專案人員特點和專案變化情況，做好風險評估，提前做好應對措施。讓問題無形中化解。這樣也減少低效的加班。

2010 年經朋友介紹，在第一波互聯網熱潮中，去了某知名互聯網企業做產品經理，算是一次轉行了！

從大公司出來後， 自己開始跨界創業，已經有 5 年了。

給年輕工程師的建議：

作為一個工程師， 語言不應該是問題，包括程式語言和英語。程式和英語背後隱含著西方解決問題的哲學、方法論和技巧，深刻理解掌握這些將讓自己受益終生。

例如，對於使用搜尋引擎找尋答案，只要問對問題，就一定能找到答案。當不知道確切問題關鍵字時，如何透過類似知識圖譜的系統化思路，在幾次與搜尋引擎進行交互，找到與答案匹配度最高的詞，並最終找到答案。這有賴於對程式思想、問題領域的理解程度。

他想對於想要轉型創業的工程師說，一般創業容易成功的，都是雇用（剝削）自己長期鑽研領域的獨到見解。沿著這個思路，工程師要麼就是在自己的技術專業領域有獨到之處（也許是作為類似科學家/CTO 類）；要麼就是在長期工作中，發現涉及的領域有什麼機會，與信得過的夥伴一起行動。創業要慎重，風險還是很高的。

只要過得滿意，就是最好的職業選擇

趙先生、Bryan 和黃先生是屬於比較幸運的老工程師了！無論工作如何，加班升職與否， 他們還在從事自己感興趣的工作。有的可以將工作很好的融入生活， 有的將兩者界限劃分的很清楚。

堅持研發、轉型高管還是自主創業，不管是 996 還是 775，無論哪種選擇，其實，只要自己過得滿意充實，就都是好的職業選擇。

（本文經 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈 码龄超过 20 年，依然对生活和编程充满激情，这是三位 70 后“老”程序员的故事 〉 。首圖來源：Pixabay CC Licensed）

給工程師的職涯參考

軟體工程師的職涯該如何發展？AppWorks School 校友要跟你講 3 個熱血故事
台灣正缺軟體工程師！新鮮人年薪中位數破 70 萬台幣，但他不能只會「寫程式」
給工程師的職涯警惕：矽谷工程師平均年齡只有 30 歲，老工程師去哪了？

【為什麼我們要挑選這篇文章】很多想當工程師的人都會學程式，但每個工作都有卡關的時候，怎麼寫怎麼錯，寫到破頭還是沒有解決問題，如此低成效的結果，會不會一開始就出錯了？下文提供 Google 工程師寫程式的五大習慣，學會這些，寫程式的成效可能翻不只三倍囉！（責任編輯：黃穗懷）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

Google 招聘工程師的難度眾所周知，不僅要求工程師碼力超強，還要求有良好的程式設計習慣。

那麼他們在寫 code 的過程中，有哪些非常可貴值得我們借鑒的步驟呢。

本文作者是 Google 的軟體工程師 Steve Merritt，下面他將介紹其在 Google 的日常工作及與各種 level 的工程師（培訓生、大學生、實習生）的合作中都會用到的一些小技巧。

舉個例子來說明這個流程。

假設有個問題：給定兩個字串 sourceString 和 searchString，如果 sourceString 中含有 searchString，就返回第一個字元在 sourceString 中的索引。如果 sourceString 中沒有 searchString，就返回 -1。

寫 code 前，必須先觀察與動筆釐清問題

坦率地說，立刻就去寫 code 是種荒謬且懶惰的想法。 就好比在你寫一篇文章之前，要先弄清楚你的假設及論據，從而保證文章的內容有意義。不這麼做的話，你可能會漸漸意識到你所寫內容可能會跑題，不僅浪費時間，還影響心情。寫代碼也一樣，那時你可能像眼睛裡進了洗髮水一樣難受。

通常，解決問題的方法乍一看很簡單，但其實不然。 先在紙上書寫有助於你找到解決問題的方法，並能證實該方法可用於不同情境，這些都得在寫 code 之前完成。

所以不要急於寫 code，甚至想都不要想代碼。隨後你是有足夠的時間來做加分號、逗號這些事的。

畫個圖吧，畫上箭頭，或在框裡寫上數字，反正，用盡一些可以幫你描述問題的方法。我們的目標是解決問題，所以不要局限於鍵盤，請盡情使用你的紙筆。

先設計一些簡單輸入。如果函數要處理的是一個字串，那 abc 就是個很好的例子。試想一下正確的結果是什麼，然後梳理一下你是如何解決這個問題的，以及用到了哪些步驟。

假設字串的值如下：

我的思路：我能看出 searchString 包含於 sourceString 中。但我是如何做到的呢？對 sourceString 從左讀到最右，每 3 個字元一組和「yes」進行比對看是否匹配。

如「abc」「bcd」「cde」等。當讀到索引為 4 的字元時，發現了「yes」，這樣我就確定存在這麼一個匹配，且始於索引為 4 的字元。

當我們在寫演算法時，我們需要確保我們能表達出所有內容並能應對所有可能的場景。在找到匹配的時候理應返回正確的答案，在沒找到匹配的時候也要放回正確的答案。

試想一下另一對字串的情景：

我們把 sourceString  這個單詞從左往右讀，每 3 個字元一組地比對是否和「yes」匹配。讀到索引為 4 的字元是，我們看到「yef」，這看起來像是一樣的，但並不是，因為第三個字元不同。所以，我們一直讀到最右邊，得出的結論是沒有匹配，所以返回 -1。

我們已經能確定解決該問題需要的一系列步驟（在程式設計領域，我們稱之為演算法），並且我們已經不同情境中進行都嘗試並都得到正確的結果。基於這點，我們就認為該演算法是有效的，接下來我們就該將它演算法化。

第二步，寫下文字具體化目標

認真思考上一步中確定的演算法後，我們就可以試著用文字把它寫出來。

這麼做能使得步驟變得很具體，以便我們在後續寫 code 的時候進行參考。

從字串的首位開始讀。

– 查看由 3 個字元 (或是 searchString 中的字元數) 組成的子集。
– 如果出現和 searchString 一致的，就返回其字母的索引號。
– 如果我們讀到字串末尾都沒有能匹配的，就返回 -1。

第三步，寫一些結構相仿的程式碼

偽代碼並不是真實的代碼，但是它和代碼結構相仿。下述是我上文演算法的偽代碼：

這樣寫就更像真實代碼了：

偽代碼和真實代碼的相似度取決於你，通過長期實踐你會找到最適合你的一種形式。

第四步，嘗試將程式碼全面化

提示：如果問題比較簡單，你也可以一併完成上述步驟

這下我們需要開始考慮語法、函數參數及語言規範了。你或許不能一下就把代碼寫的很全面，沒關係，先寫下你會的。

你會發現上述代碼中我留空了一部分。我是故意的，因為我不確定在 JavaScript 語言中給字串切片的語法，所以我會在下一步中查詢該語法。

第五步，杜絕來源不明的片段程式碼

我發現新手工程師常犯這樣一個錯誤，就是在網上找到一些覺得可能有用語句，不經測試便將其加到程式中。你不理解的程式碼片段越多，就越不可能找到適合的解決方案。

隨著你不確定的內容增加，你的程式出錯的方式會呈指數式增加。當你有 1 處不確定的時候，你程式確實只會因為這 1 個原因而出錯。

但是如果有 2 處不確定，出錯就有 3 種情況（A 處出錯，B 處出錯，或者 AB 都出錯）。如果有 3 處不確定，就有 7 種情況。到時你就很難找到出錯原因了。

附注：程式出錯原因的個數如梅森序列：a(n) = (2^n) — 1

先測試一下你的新代碼。 能在互聯網上找有用的內容是很好的，但是請在將其加到程式中之前，用一個獨立的環境進行測試，以確保它能以你認為的方式運行。

在上一步中，因為不確定在 JavaScript 語言裡選取字串某個部分的方式，所以就 上網搜一下 。

第一個結果就是 w3schools 網站的，雖然內容有點老，但是通常是靠譜。

在這基礎上，假設我每次用這段代碼：

來提取 sourceString 的一部分。我會先建個例子來測試。

這時，我就能確定這個函數的執行效果了。所以，當我將它插入到我的程式中後，我也能知道程式的故障是否由它導致的。

測試完成後，我就能將這最後一部分代碼添加到我的程式裡了。

最後，我想說的是，帶著我的方法回去試試之前讓你崩潰的程式設計問題，我保證會立竿見影的。

（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈谷歌程序员有哪些高效的编程习惯？〉。）

你會想知道

Google 首席工程師是這樣理解數據的！8 分鐘教會你什麼叫真正的「統計學」

Google 工程師：女性當不了科技主管不是歧視，是「生物」差距

軟體工程師的職涯該如何發展？AppWorks School 校友要跟你講 3 個熱血故事

亞馬遜和蘋果是競爭對手，但你知道蘋果其實是 AWS 雲端系統的最大客戶，且每個月要給付上億台幣給亞馬遜嗎？

每個月，蘋果要給亞馬遜 9 億台幣

亞馬遜的雲端系統 Amazon Web Services（AWS）獨步全球，它以高穩定、高速的特性，高度遍及於全球企業，舉凡 Netflix、Airbnb 都是 AWS 的忠實客戶。

每個月上億用戶在使用蘋果設備與服務，其中以 iOS App Store、AppleCare、Apple Pay 和 iCloud 最為頻繁。 據 CNBC 報導 ，蘋果在 AWS 上建構的系統，月費已達到 3,000 萬美金（約 9 億台幣），且未來幾年還有上漲的跡象。

CNBC 記者指出，蘋果已與亞馬遜簽署一個 15 億美金的線上系統合約（約  450 億台幣），合約走期為 5 年。外媒 9to5mac 也 提到 ，蘋果很有可能將 Apple News+、Apple TV+、Apple Arcade 等春季發表會中推出的新服務也一條龍的上線 AWS 雲端系統。

預計 5 年內，蘋果開始自力更生

然而，蘋果也不會坐以待斃，一輩子依賴 AWS 系統。據 了解 ，蘋果打從 2018 年年初就下手投資，用 100 億美金（約 3,000 億台幣）建構自己的雲端系統與資訊中心，目標 5 年內達成目標。蘋果隨後透露 2019 年的投資金額約 45 億美金（約 1,350 億台幣）。而蘋果也積極招募 工程師人才 ，工作內容包含「領導與架構比照 AWS 的蘋果雲端系統」（Lead and architect our growing AWS footprint）

參考資料來源：

1.《9to5mac》：〈Apple now paying Amazon over $30M each month for cloud services, likely to continue growing〉

2.《CNBC》：〈Apple spends more than $30 million on Amazon’s cloud every month, making it one of the biggest AWS customers〉

（本文提供合作夥伴轉載，首圖來源：Unsplash, CC Licensed。）

延伸閱讀

蘋果、高通吵了兩年終於和解，但怎麼刀下亡魂是英特爾？

華為態度大反轉！開放販售 5G 晶片，但只賣給「蘋果」

蘋果推出 Apple Card 信用卡！用 Apple Pay 購物還送 2% 現金回饋

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

菜鳥工程師初出茅廬時大多是帶著熱情與理想的，他們是怎麼一步步變成那個「別吵我，我只想靜靜 coding」一臉厭世的工程師？

《Habits That Harm Your Technical Team》一書的作者 Marcus Blankenship 說，大多數主管都會認為，一個工程師從充滿熱情，到偏執甚至被孤立，問題是出在他自己身上。

但 Marcus Blankenship 認為，其實菜鳥工程師會變成這樣，問題是出在「主管」身上，他出現的消極行為，其實來自上司給他的反饋，是公司環境塑造了今日的厭世碼農。

怎麼給「第一次建議」非常重要

Marcus Blankenship 認為，主管、上司第一次給菜鳥工程師的建議「非常重要」，因為這決定了他們會不會在將來分享更多的想法，或者成為一個選擇閉嘴、不再多管閒事的人。

因此，儘管他們提出的想法可能不適用於公司現況，但主管給的建議若帶有鄙視、貶低的想法，「尤其在他們剛來幾個月內做出這種舉動是最糟糕的。」

因為當他的滿腔熱情一而再、再而三地被潑冷水，他不久就會意識到「唯一的取勝方式就是不玩了、保持沉默」。

他不再提出想法、不要求與客戶見面，也不再真誠地理解業務，只會靜靜地敲 code，其他什麼都不想幹，而這是身為主管的人最不希望工程師吸取的教訓，最後成了雙輸的局面。

當菜鳥工程師給出建議時，其實也在承擔風險

Marcus Blankenship 說，當這些菜鳥工程師提出新的想法時其實是在「冒險」，且想法越大，風險就越大，因為我們的想法其實反映了我們自身的觀點與熱情，「我們不會去推動那些自己不關心、自己認為不可行的想法」，所以我們提出新的想法時，是把最好的想法給貢獻出來，希望能被接受。

「這需要有暴露脆弱的勇氣，」而如果我們認為自己的想法不會被接受，就不會再說。

主管對工程師想法的反饋塑造了他日後的行為。當上述的情況發生，那麼他就只會退回去只做能讓自己成功的事情，也就是寫代碼，不會再對自己正在建造的事物提供意見，只沉迷於它的建造方式。

不曾明說，但主管正在傳遞的「企業文化」其實是……

是什麼讓當初曾抱有創造、創新與開發熱忱的菜鳥工程師，變成了一個只會更關心自己賺了多少、頭銜是什麼，以及自己的 LinkedIn 看起來如何的厭世工程師？其實是主管不知不覺正在傳遞的企業文化。

Marcus Blankenship 說，雖然主管可能永遠不會說出這些話，但其培訓方式與文化，可能會傳遞以下訊息：

「我們的公司不喜歡小人物的大想法。」

「你做好開發的事情就夠了，我們會弄清楚客戶要的是什麼。」

「你就只是個程序猿。」（“You are just a code monkey.”）

「嗯……為什麼你有十萬個為什麼，你沒有代碼可寫了嗎？」

例如美媒 《CNBC》 就曾在今年稍早揭露 Facebook 的企業文化「不鼓勵提出反對意見」，在美國知名求職網站 Glassdoor「最理想雇主」調查中，Facebook 每況愈下，從去年的冠軍寶座一路跌到第 7 名，顯示企業文化的重要性。

Marcus Blankenship 說，所謂的企業文化不是貼在牆上的口號，也不是在面試時向面試者介紹的公司使命，而是在這間公司 ｢大家的做事之道」，文化不是命令，而是學習、榜樣與模仿。

Marcus Blankenship 建議主管，若看到你不喜歡的東西，那就去改變它，「身為主管，值得別人效仿是你的工作。」

TO 編按：如果工程師想開心工作 20 年，你可以……

雖然這是一篇給主管的建議，但相信也有正在失去熱情的菜鳥工程師正在看這篇文章。TO 在這推薦你一篇文章。

根據 Stack Overflow 近期公布的 2019 年工程師普查 報告 ，在這份近萬人參與的調查中，有 40％ 以上的工程師碼齡不到 5 年。

《大數據文摘》作者文摘菌關心了中國工程師面臨的 996 問題，並撰寫了一份給工程師的職涯警惕文，他在評論中看到工程師普遍擔心與焦慮的疑問，例如：

「工程師真的都應該 996 嗎？」
「工程師和空姐一樣，吃的都是青春飯。」
「一直寫代碼，沒有時間學習提升，難道要寫到 40 歲嗎？」

文摘菌因此決定採訪幾位老工程師，發現了他們開心工作 20 年的祕密。

綜觀這些老工程師對工作、加班、生活的想法，可以發現他們通常對工程師的工作充滿了熱情，都是選擇了自己喜愛的工作來做，如果你想要知道這個秘密的詳情，請點 【傳送門】。

參考資料來源：

1. Marcus Blankenship：Why your programmers just want to code
2.《CNBC》：〈Inside Facebook’s ‘cult-like’ workplace, where dissent is discouraged and employees pretend to be happy all the time〉

（本文提供合作夥伴轉載，首圖來源：Flickr，CC Licensed。）

延伸閱讀

工程師只能 996 嗎？三個老工程師教你如何在程式界開心存活 20 年
給工程師的職涯警惕：矽谷工程師平均年齡只有 30 歲，老工程師去哪了？
扼殺企業文化的第一步：把口號寫在牆上

【為什麼我們要挑選這篇文章】若說千禧蟲危機是全球工程師的危機，那麼改元令和發生的「類千禧蟲危機」恐怕僅有日本工程師自己能解。

作為世界唯一保留了年號和皇曆的國家，改元令和究竟給日本工程師帶來了怎樣的挑戰？又，為何在令和之後還有更恐怖的「昭和 100 年」問題等待解決？下文，讓我們來看看日本工程師是怎麼集體崩潰的。（責任編輯：藍立晴）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息   
快將你的履歷自傳寄至    jobs@fusionmedium.com」

從 5 月 1 日開始，日本就徹底告別了平成時代，步入令和元年。

而且由於天皇更替舉國歡慶，日本往年最長只有 5 天的黃金周將被加量到 10 天，也就是說，日本社畜（日本企業底層上班族的自嘲用語，意思為「公司的牲畜」）即將迎來夢幻般的十連休！

但對於已經到來的令和元年十連休，也不是每個人都歡天喜地。因為伴隨著新元號而來的，是一系列煩死人的系統年號變更問題。

作為全球唯一保留了年號和皇曆的國家，儘管日本在日常生活中也普遍使用公曆，但無論是銀行、證券、保險等金融機構還是行政機關，都仍在使用年號紀元。

改元令和，日本工程師前所未有的大挑戰

因此，從 2019 年 5 月 1 日正式改元開始，日本所有的電腦和軟件系統都必須在當天同步改用新年號。而在日的國際 IT 公司，更需要將公曆與日本皇曆切換，將日本使用的軟件版本日期更新為新年號紀元。

而且，1989 年開啟的長達 30 的年平成時代裡，網路資訊技術迅猛發展，比起上次改元時，今日的網路系統對人們生活的影響已不可同日而語。

如今電腦、手機、保險券甚至 ATM 機都已經接入了電腦系統，對於日本工程師來說，讓所有的電腦都在 5 月 1 日同步改元，這還是歷史上從未有過的大挑戰… …

以至於一位 Twitter 網友吐槽道： 在改元的祝賀氣氛裡，IT 從業者看到這幅畫面卻只想罵人 。

身為 IT 業不相關人士、隔壁看戲人員，大家可能無法理解日本工程師「隨時都會被拖出去祭天」的恐慌，然而在工程師甚至日本政府看來，改元確實是件關係國計民生的大事。

開年有點慌，令和印章洛陽「章」貴

儘管從小接受西式教育、業餘熱衷研究蝦虎魚的明仁天皇非常特立獨行，2016 年就宣布自己將打破慣例成為第一位生前退位的天皇，然而新年號還是要等到退位前一個月才能揭曉。對於需要做出「技術性調整」的各行業人員來說， 真正留給他們的時間只有短短一個月。

於是，新年號甫一公佈，全日本上下立刻緊張了起來！

一些選擇手動升級的中小企業為了繼續利用已經打印出的文件，開始搶刻令和年號橡皮章，橡皮章一時洛陽紙貴。

辦公用品製造商 Hanko21 的總經理瀧口修表示，自己從 4 月 1 日起就開始親自下場和 20 多名員工加班在工廠裡趕製令和印章，但是他的努力沒有維持多久，因為 ｢年號公佈三天後，我們囤積的橡膠原料就全部用完了。」

而為了在一個月內對旗下的八十多個行政單位電腦系統進行快速調整，名古屋市政府撥款四億八千萬日元進行加班在 5 月 1 日前完成了賦稅、社會保障等重要系統的改造，但還有更多「不緊迫」的系統會留在 1 至 7 日由工程師加班完成……

電腦系統和平成年代一樣古老

當然，最發愁的還是電腦系統老舊過時的私人小企業。因為更新系統耗資巨大，有些日本公司的電腦系統已經二三十年沒有更新過了，幾乎和平成年代一樣古老，根本無法自動升級。

面對改元，山梨縣北杜市的一家老字號點心鋪可能是少有的能淡然處之的實體之一。這家店的老闆在 30 多年前昭和時代預定帳本時，把 50 本訂成了 5000 本，整個平成時代過去了帳本還沒用完。

元號變成令和後，起碼老闆今後只用改一個字了（昭和改令和）。

中小公司改元亂成一鍋粥，而那些自稱「我好了！」的公司，也紛紛出現大漏洞。

一個月前微軟表示，將通過雲端向日本客戶推送 令和更新包 。而 5 月 1 日上午，就有還在加班的日本上班族表示 Excel 日期混亂，不僅顯示出平成 31 年 5 月 1 日這種不存在的日期，公曆年份還變成了 5 位數。

與此同時，北海道銀行、北陸銀行和橫濱銀行開始發生大規模 ATM 機混亂事故。所有的轉帳日期都變成了 1989 年 5 月 7 日，至於被轉走的錢到底去了哪裡、利息怎麼計算誰也不知道（畢竟在系統裡這已經是一筆來自 1989 年，存了 30 年的錢），不過這三家銀行表示他們有信心盡快修復錯誤。

而這場曠日持久的改元混亂，還要持續到 5 月 7 日。

在 2019 年 5 月 1 日內閣會議後的新聞發布會上，日本內閣官房長官菅義偉宣布，儘管 5 月 1 日年號就已經更替為令和，但改元工作要到 5 月 7 日才會結束。「我們不會影響公眾生活。」菅義偉說，但日本民眾對此存疑。

為什麼這麼驚慌？

也許有人不理解，「年號不過是一個名字而已，會造成這麼大的影響嗎？」

事實是，年號與日本的電腦系統和各種證件的系統息息相關，一旦出現混亂，輕則證件失效，重則金融交通系統崩潰。

比如著名的「駕照迷思」。平成 29 年發放的駕照有效期至平成 32 年（2020 年），然而在這個日期來臨前，日本就已經進入了令和時期，理論上平成 32 年是不存在的。

人工操作時還比較好加以判斷，然而對於六親不認的電腦來說，所有有效期在平成 31 年 4 月 30 日以後的契約合同證件證券，全部都是無效的。

此時，就需要工程師們上陣迅速修改系統，保證人們的正常生活了。

西元 2000 年，日本工程師忘了是個大閏年…

而在平成 12 年（即 2000 年）2 月，因為日本工程師忽略了 2000 年是個大閏年，沒有在系統裡加入 29 日，這一天在北海道札幌市拿月票卡通勤的上班族統統被堵死在路上，造成了交通癱瘓和大規模遲到。

雖然犯這種低級錯誤的真實原因已經不得而知，但總覺得換做用公元紀年的話，應該挺好發現 2000 年是閏年的。

因為年號和電腦系統實在過於煩人，維基百科專門在日語「元號」條目中加入了「元號​​與電腦」這一欄，長篇大論元號的種種弊端。

日本工程師受的苦，外人真的沒法數。

令和之後會更慌？「昭和 100 年」要來了

儘管令和的劫已經快渡完了，但日本工程師的夜明還遠遠沒有來到……

在 2019 年開年之初，有一位工程師小姐姐在 Twitter 上提醒大家：「比起新元號對應問題，還有更需要擔心的事哦～昭和 100 年就快要到了哦～」

她的言論立刻引發大量轉發，評論區一片工程師的悲鳴。

日本的昭和時代從 1926 年開始，1989 年結束，歷經 64 年，因此昭和年號最多只有 64 年。那麼讓日本工程師聽了就要跪的昭和 100 年又是什麼鬼？

這還要歸功於前代工程師綿延三十年甩來的巨鍋。

1989 年，日本經歷了昭和到平成的改元，那時的電腦還比較原始，內存只有 64-128 KB，每一個 bit 都至關重要，工程師只能想方設法從各種地方摳內存（ram）。於是，在記錄日期時，年份都只會記錄後兩位，比如 1989 年 1 月 1 日，就會被記錄為 890101。

然而一旦到了 2000 年，巨大的 bug 就出現了。由於只保留後兩位數，銀行裡面的電腦可能把 2000 年解釋為 1900 年，從而算錯利息甚至直接消除帳面記錄，而你在 1999 年 12 月 31 日 23：59 分打了三分鐘的電話，電信局的帳單卻可能出現負數計數而導致系統崩潰（-100 年+3 分鐘）。

這就是大名鼎鼎的千年蟲問題。

在全球同行都為千年蟲焦慮不已的同時，先代日本工程師們卻靈機一動……

如果繼續延用昭和年號計數的話，千年蟲問題就會被推後 25 年，即昭和 100 年（2025 年）才歸零！比別人多了 25 年，肯定足夠我們解決問題了！

所以如今日本政府和企業的系統裡表面上看起來一團和氣，實則一直在底層為昭和續命。

然而眼看令和元年都來了，清算的日期還有六年就要到了，新一代日本工程師們面對 COBOL 等上古語言開發的系統卻更加迷惑了。

「銀行和大企業的基礎系統像古董一樣脆，怎麼也不能更新……！」

「30 年 40 年前的代碼根本沒有說明文檔，剩下的部分也沒有追加變更記錄！」

「法律規定的 5 年追訴期早就過了，因為人事變動，當年的負責人全都找不到了。」

日本工程師大型崩潰，只能祈禱到 2025 年自己已經轉行了……

當然看熱鬧不嫌事大的人也是存在的。

「從平成到令和時代，昭和 100 年問題即將到來，好像被遺忘的時代的亡靈要來了，這不是很帥嗎？」

到那時面對「時代的亡靈」，日本工程師會不會想出新的甩鍋辦法，那就是另一個故事了。

至於當年甩鍋的老工程師們表示，「誰能想到 20 年後你們還在用這一套啊！！」

（本文經合作夥伴 品玩 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈为什么改元“令和”，竟然成了日本程序员的魔咒？〉。首圖來源：  品玩）

延伸閱讀

迎接「令和」放 10 天連假，但為什麼日本上班族卻「鬱鬱寡歡」？
全家打算推出「日本版 Amazon GO」，但是他們選擇「保留人類店員」
【文科生在哀號】學 AI 不只是理科生的事！日本政府：你讀文科也得要會

【為什麼我們要挑選這篇文章】本是同根生，相煎何太急。駭客、工程師都是寫 Code 的好夥伴，幹嘛想不開攻擊 GitHub，甚至進行勒索呢？（責任編輯：陳伯安）

本文經 AI 新媒體量子位（公眾號 ID：QbitAI）授權轉載，轉載請聯繫出處

作者：量子位／ 曉查 乾明

工程師的大本營被駭客攻擊了。

就在五一假期的最後一天（編按：中國五一勞動節皆為連假），一些工程師查看自己放到 GitHub  上的程式碼時發現，他們的原始碼和 Repo  都已消失不見，取而代之的是駭客留下的一封勒索信。

這封信中表示，他們已經將原始碼下載並存儲到了自己的服務器上。

受害者要在 10  天之內，往特定帳戶支付 0.1  比特幣（約 17,000 台幣），否則他們將會公開程式碼，或以其他的方式使用它們。

要找回丟失的程式碼並避免程式碼洩漏：將 0.1  比特（BTC）發送至我們的比特幣地址 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA ，並通過郵件與我們聯繫，提供您的 git 登錄信息和付款證明。地址為 admin[at]gitsbackup[dot]com。

如果你不確定我們是否有你的數據，請聯繫我們，我們會給你發送證明。你的程式碼已經被下載並備份到我們的服務器上。

如果我們在接下來的 10  天內沒有收到你的付款，我們將公開你的程式碼或以其他方式使用它們。

從這個威脅話語來看，受到攻擊的是 GitHub  上的私有資料庫。而且，不僅僅是 GitHub，其他程式碼管理網站 GitLab、Bitbucket  也受到了攻擊。

上百名用戶受害，兇手專攻「私有數據庫」

根據 GitHub  上的搜索數據顯示，一共有 373  名用戶受到了攻擊。根據 GitLab  公佈的數據，駭客至少可以訪問所有 131  個用戶和 163  個資料庫。

這些受到攻擊的資料庫的程式碼和提交信息，全都被一個名為「gitbackup」的帳號刪除。

在各大社交媒體上，一些受害者將遭到攻擊歸咎於 Atlassian  開發的 Git GUI  應用程序 SourceTree，認為駭客利用了其中的漏洞。

但攻擊波及的範圍涵蓋多個平台，The Register  報道稱，這次攻擊很可能是針對無意識的安全性較差的存儲庫，而不是特定的漏洞。

根據 ZdNet  報道，駭客可能是掃描網路上的 Git  配置，然後提取了其中的登錄憑證登錄 Git  庫，來完成的這波操作。

截止到發稿時間（5/5），還沒有人向攻擊者的比特幣帳戶支付贖金。取而代之的是，這一比特幣地址遭到了不少舉報。

根據 Bitcoin Abuse  數據庫顯示，已經有 31  人舉報了這一比特幣地址，表示對方是一個駭客，希望刪除地址。

ZdNet  記者 Catalin Cimpanu  表示，攻擊現在已經停止，並沒有新的帳戶被攻擊的情況出現。

被攻擊帳號有個共通點：密碼沒有保護好

根據 GitLab  的官方聲明，這次駭客攻擊事件最大的問題在用戶：

「我們有充分證據表明，受影響帳戶的密碼以明文形式存儲在相關程式碼數據庫的部署中。」

因此提高安全意識才是保護自己程式碼的最好方法，GitLab  建議用以下方法防止密碼被駭客盜取：

1、使用強密碼，降低被駭客破解的風險

2、用密碼管理工具存儲密碼，不要使用明文

3、開啓雙因素身份驗證，並使用 SSH  密鑰提高

如果你已經不幸中招，也不要急著交贖金，因為即使交錢也無法保證程式碼不會被駭客公開。

至於已經被刪除的程式碼，一位早期受害者在 StackExchange  論壇指出，程式碼其實還在，是可以恢復出來的，只是 HEAD  被駭客修改了而已。

他還給出了一系列補救辦法，被 GitLab  官方推薦。

專家教你如何補救

輸入以下程式碼：

git checkout origin/master
git reflog # take the SHA of the last commit of yours
git reset [SHA]

能看到駭客的提交記錄，並修復 origin/master。但是問題還沒有完全解決，如果輸入 git status，還是會顯示：

HEAD detached from origin/master

如果你在本地備份了程式碼，那就好辦了，直接把本地程式碼強制 push  上去：

git push origin HEAD:master –force

如果你沒有備份，仍然可以從遠端數據庫複製過來，用 git reflog  或者 git fsck  可以找到最後一次提交並更改 HEAD。

接下來唯一需要擔心的可能就是駭客是否會公佈你的私有程式碼了。

中、小企業頂得住程式碼公開的代價嗎？

關於程式碼被公開，中國一些公司也有切膚之痛。

比如大疆，其一名前員工，將含有公司商業機密的程式碼上傳到了 GitHub  的公有倉庫中，造成源程式碼洩露。

根據這些原始碼，攻擊者可以 SSL  證書私鑰，訪問客戶的敏感信息，比如用戶信息、飛行日誌等等。

根據評估，這次洩漏程式碼一共給大疆造成了 116.4  萬人民幣（約 582 萬台幣）的經濟損失。

前不久，關於這一程式碼洩露事件也得到了判決：

有期徒刑六個月，並處罰金 20  萬人民幣（約 100 萬台幣）。

最近，B  站（中國影音串流網站 Bilibili）的原始碼也被人公開到 GitHub，雖然很快被封禁，B  站也已經報警處理，但有不少網友早複製了資料庫，隱患已經埋下，補救起來也頗為頭疼。

如果駭客公開了這次獲取的所有程式碼，對其中一些小團隊來說可能就是滅頂的打擊了。

（本文經 AI 新媒體 量子位 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈GitHub 遭攻击！黑客给出十天限期：不交比特币赎金，就公开用户私有代码 〉，首圖來源：Pxhere, CC Licensed。）

你可能感興趣

Python 早就落伍了！AI 權威 LeCun 直言：深度學習需要更靈活的程式語言

顛覆熱力學第二定律！物理學家用 IBM 量子電腦讓「時間倒回」了

最新「數據科學」自學清單：六個月無師自通，菜鳥新手趕快存起來

【我們為什麼挑選這篇文章】Python 是目前最受歡迎的程式語言，但是該怎麼入門、怎麼學？如果說讓你用 100 天就能學會 Python ，你會心動嗎？下文，讓我們來看這個在 GitHub 上破萬顆星的百日 Python 計畫怎麼帶 Python 新手入門。（責任編輯：藍立晴）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至 jobs@fusionmedium.com」

作為目前最受歡迎也是最實用的程式語言，Python 不僅是新手入門程式語言界的首選，也逐漸成為了從大廠到小廠，招牌需求 list 的必要一條。

當然，學 Python 這件事情，你可能也和文摘菌（本文作者）一樣，已經下了一百次決心，但是最後都「從入門到放棄」。

究其原因，很可能是沒有明確的學習目標，或者學習目標太過「宏偉」，所以總是陣亡在了 introduction 影片到第一行 Python 之前。

GitHub 熱榜第一：學習 Python 只要 100 天

那麼，從小白成為大師，到底需要多長時間？真的有一個有規可循的計劃嗎？

本週 GitHub 熱榜第一的專案告訴你：Python 學習有套路！並且只需要 100 天！

自發布，這篇 GitHub 帖子的星星數量已經過萬，Fork 數也有 3566。專案詳細給出了一個 100 天的 Python 學習計劃，包括每天需要掌握的內容、學習週期、資料庫等。從怎麼安裝 Python 介紹起，到使用 Django 開發專案收尾。100 天，11 個階段，每完成一個階段都讓你成就感滿滿。

先附上 GitHub 網址傳送門：【點我】

下面文摘菌也簡單介紹一下這個專案。

第一階段 15 天，完成基本 Python 語言入門

第 1 天的任務是讓你完成 Python 的搭建並寫出第一行命令，也就是 hello word。除此之外，使用 IDLE – 交互式環境（REPL），編寫多行程式碼，使用註釋給說明程式碼的作用也是在第一天就要掌握的。

第 2 天的任務是掌握 Python 的語言元素，包括變量和類型、數字和字串、運算符等。學完這些知識點，在第二天就要能夠實現應用案例包括：華氏溫度轉換成攝氏溫度、輸入圓的半徑計算周長和面積、輸入年份判斷是否是閏年。

例如將華氏溫度轉攝氏溫度。

"""
將華氏溫度轉換成攝氏溫度
F = 1.8C + 32
Version: 0.1
Author: 骆昊  """

f = float(input('請輸入華氏溫度: ')) c = (f - 32) / 1.8 print('%.1f 華氏度 = %.1f 攝氏度' % (f, c))

第 3 天掌握分支結構，包括分支結構的應用場景，if 語句的使用。然後使用這三天的知識點完成案例用戶身份驗證、英制單位與公制單位互換、擲骰子決定做什麼、百分制成績轉等級制、分段函數求值、輸入三條邊的長度如果能構成三角形就計算周長和面積等。

第 4 天學習循環結構，包括 while 循環的基本結構：break 語句、continue 語句等。for 循環的基本結構、range 類型等等。然後完成 1~100 求和、判斷質數、猜數字遊戲、列印九九乘法表、列印三角形圖案、猴子吃桃等經典案例。

第 5 天總結前四天的知識點。

第 6 天函數和模塊（module）的使用知識點，包括：函數的作用、用函數封裝功能模塊、定義函數、調用函數、函數的參數、函數的返回值、作用域問題、用模塊管理函數。

第 7 天，介紹字符串和常用數據結構知識點，包括字串、列表、串列、集合、字典等知識點。要能用這些知識帶你完成楊輝三角、雙色球選號、井字棋等經典案例。

第 8 天，物件導向程式設計基礎，介紹類和對象的以及基礎練習：定義學生類，定義時鐘類，定義圖形類，定義汽車類。

第 9 天，物件導向程式設計進階，學習屬性、類中的方法以及運算符重載、繼承和多態等知識點，能夠完成工資結算系統、圖書自動折扣系統、自定義分數類案例。

第 10 天，圖形使用者界面和遊戲開發。使用 tkinter 開發 GUI、使用 pygame 三方庫開發遊戲應用，完成大球吃小球的遊戲。

第 11 天，文件和異常。學會讀文件，寫文件，異常處理，代碼塊等知識點，完成案例：歌詞解析

第 12 天，字串和正規運算式。重點是正規運算式相關知識點，並能使用正規運算式驗證輸入的字串。

第 13 天，程序和引線（執行緒），掌握程序和引線的概念、程序的使用方法。

第 14 天分為兩個部分，第一部分網路程式入門，第二部分網路應用開發。網路程式入門介紹電腦網路基礎、網路應用架構、Python 網路程式。第二部分介紹訪問網路 API、文件傳輸、電子郵件、簡訊服務（twilio 模塊／國內的簡訊服務）

第 15 天，圖像和文檔處理。包括用 Pillow 處理圖片，讀寫 Word 文檔，讀寫 Excel 文件，生成 PDF 文件等知識點。

經過這 15 天，我們就完成了基本的 Python 語言入門，接下來進入 Python 語言進階。

這一階段要掌握常用數據結構、函數的高級用法（例如 Lambda 函數、作用域和閉包）、物件導向設計原則、疊代器和產生器、並發和異步程式等五個部分，每兩天一個部分！

包括：用 HTML 標籤承載頁面內容、用 CSS 渲染頁面、用 JavaScript 處理交互式行為、jQuery 入門和提高、Vue.js 入門、Element 的使用、Bootstrap 的使用。

包括操作系統發展史和 Linux 概述、Linux 基礎命令、Linux 中的實用程式、Linux 的文件系統、Vim 編輯器的應用、環境變量和 Shell 程式、軟體的安裝和服務的配置、網路訪問和管理。

介紹包括關係型數據庫 MySQL、SQL 的使用以及範式理論，設計二維表的指導思想、數據完整性、數據一致性等相關知識點。最後介紹 NoSQL 入門。

從第 41 天開始，就從理論到實踐啦！Django 實戰， 5 分鐘快速上手，深入模型理解關係數據庫配置、使用 ORM 完成對模型的 CRUD 操作、Django 模型最佳實踐；學會加載靜態資源、用 Ajax 請求獲取數據。

這個階段你還將學到表單的應用、Cookie 和 Session、中介軟體的應用、 日誌和快取、 文件上傳和富文本編輯、 文件下載和報表、RESTful 架構和 DRF 入門、 RESTful 架構和 DRF 進階、 使用快取、簡訊和郵件、 異步任務和定時任務、單元測試和專案上線；最後學習專案開發流程和相關工具。

此階段掌握：Flask 入門、模板的使用、表單的處理、數據庫操作、項目實戰。

在進入正式的知識點之前，先花一天的時間掌握預備知識：並發程式、I/O 模式和事件驅動。然後開始學習 Tornado 入門、異步化、WebSocket 的應用等等。

包括網路爬蟲和相關工具、數據採集和解析、儲存數據、並發下載、解析動態內容、表單交互和驗證碼處理、 Scrapy 入門、Scrapy 高級應用、Scrapy 分佈式實現等等。

在工具知識點部分，主要介紹機器學習基礎、 Pandas 的應用、 NumPy 和 SciPy 的應用、 Matplotlib 和數據可視化。在算法部分，主要介紹最近鄰居法（KNN）分類、 決策樹、單純貝氏分類器、 支援向量機（SVM）、 K-均值聚類、 迴歸分析。其他也包括：大數據分析入門、 大數據分析進階、 Tensorflow 入門、 Tensorflow 實戰、推薦系統。

註：這一部分資料，尚未更新完整。

開始的前兩天， 你需要先組建好開發團隊和完成專案選題，數據庫設計以及 OOAD。

在之後的 6 天內，使用 Django 開發專案；最後給自己留兩天的實踐測試和部署。

學完這 100 天的知識點，認真完成專案，無論去面試哪一家公司的 Python 開發崗位，相信你都是信心滿滿。

為了讓你盡快拿到 offer，此專案還給出了其他的一些資料，包括 PEP 8 風格指南、 Python 參考書籍、Python 慣例、玩轉 PyCharm、用函數還是用複雜的表達式、知乎問題回答、那些年我們踩過的那些坑。

例如在知乎問題回答文檔中，就給出了 Python 各個面向的職缺招聘需求情況：

看到這裡有沒有很動心！最後，祝各位學習順利，100 天後見！

（本文經合作夥伴 大數據文摘 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈Github 标星过万，Python 新手 100 天学习计划，这次再学不会算我输！〉。首圖來源：大数据文摘 。）

延伸閱讀

最賺錢程式語言換人當！Clojure 擠下 2018 年最賺的 F#
【內附程式碼】工程師技能大全：如何用 Python 寫出所有的演算法？
求職市場最搶手的 5 個程式語言技能，Python、Java 居然都沒上榜！

【為什麼我們要挑選這篇文章】程式語言於未來職場越趨重要，世界多國皆著手讓國小生接觸最基礎的程式語言編寫。但要成為一位厲害的工程師，一定要經過學校體系洗鍊嗎？（責任編輯：陳伯安）

「《科技報橘》徵才中！跟我們一起定位台灣產業創新力 >> 詳細職缺訊息
快將你的履歷自傳寄至  jobs@fusionmedium.com」

工程師是近年非常熱門的職業，不少有意投身科技界的學生也希望可以透過進修得到大公司錄用。不過 Apple 總裁 Tim Cook 最近表示，要成爲優秀的工程師並不一定要大學畢業。

Apple Store 獎學金得主是個 16 歲的工程師

Apple 總裁 Tim Cook 最近在佛羅里達州的一間 Apple Store 與 Apple 獎學金得主之一，年僅 16 歲的工程師 Liam Rosenfeld 見面，他在一個訪談中，讚揚 Liam 年紀輕輕就已經有相當厲害的程式語言技巧，也印證了他認為程式相關教學應該在低年級開始進行的構思。

他表示，四年的大學教育對於程式語言而言並非必要，這只是相當老舊傳統的想法，如果可以在低年級開始相關教學，到高中畢業的時候，學生已經可以編寫出能夠在 App Store 上架的作品。

Apple 一向都注重程式編寫教學，除了鼓勵開發者社羣繼續投入 iOS 和 MacOS App 的生態系統外，也希望教育界可以更重視程式語言，為未來培養更多人才。

（本文經合作夥伴 unwire.hk 授權轉載，並同意 TechOrange 編寫導讀與修訂標題，原文標題為 〈Tim Cook：成爲優秀程式編寫員不一定要大學畢業 〉。）

你可能感興趣

蘋果是亞馬遜 AWS 的最大客戶！每月繳費金額高達 9 億台幣

蘋果被 18 歲青年告上法院！求償 300 億台幣全因「人臉辨識」抓錯人

玻璃心又碎！微信年終送蘋果頂規 iPhone XS Max，中國網友崩潰：為何不送華為？