欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

標題: 出色程序員養成指南 [打印本頁]

作者: 51黑mcu 時間: 2016-5-17 04:50
標題: 出色程序員養成指南
你適合當程序員嗎？

我是一個熱愛寫程序的家伙。我的第一臺電腦，是13歲時買的Apple II，在那之前，我已經開始到同學家用「小教授二號」學寫程序了。高中時我當電腦社社長，帶隊參加教育部辦的全國程序大賽，幸運拿到冠軍，大學、研究所念的也是相關科系。工作20年來，一直從事軟件相關領域，即使擔任主管職務，也一直對技術充滿熱情。

寫程序寫了這么多年，多少有些體會。我把自己對寫程序這份工作的心得寫下來，希望能給從事相關領域或有志于寫程序的人參考。

Photo credit: gags9999@flickr CC BY 2.0

我適合當程序員嗎？

程序員，也叫軟件工程師、程序設計師，叫軟件工程師、程序員。我覺得「程序員」三個字簡潔有力，所以就用這個詞。

如果你正從事這份工作，恭禧你！這是個熱門行業，在可預見的將來，也不會消失。不過也別高興太早，這一行的技術汰舊換新非常快，必須不斷努力學習才行。

一點天份

打開一個空白檔案，必須創造出程序。與所有創造性的工作一樣，寫程序需要某種程度的天份。程序員生產力好壞差別很大，倒不是說一天能寫多少行程序（這可能是最沒參考價值的數字了），而是品質有天壤之別。天份很高的程序員，一個抵十個，沒天份又不努力的，一天制造的問題可能多于解決的問題，生產力是負的。具體來說，邏輯推理、抽象思考、創造力、理解力，這些都是相關能力。

當程序員不一定要有多高天份，畢竟像Linus Torvalds（Linux創始者）那樣的天才很罕見，但一點天份還是必需的。如果你發現自己寫程序、看程序、解bug都很痛苦，半年一年了也不見改善，也許這份工作不太適合你。

一些熱情

如果你對寫程序充滿熱情，又有一定的天份，那再好不過。最起碼，你有時會沉浸在寫程序或解bug的情境中（英文有個詞叫“flow”，心流）、不想被中斷，這樣就夠了。如果你從未出現過這種情境，那么你可能不會熱愛這份工作。不過沒關系，世界上不熱愛自己工作的人其實不少。如果你能做好這份工作，眼前又沒有更好的選擇，繼續做下去也沒問題。

很多努力

努力是一定要的。當一名好的程序員，要學習的東西太多了，而且不努力很快就會被淘汰（雖然很多工作都是這樣），這是入這行前應該要有的體認。

程序員基本能力

什么？寫程序也有職業道德？有的，而且還很重要。我說寫程序是一門良心事業，因為通常你寫的程序只要符合規格、能正確執行，就可以交差了，而你的主管或同事很難一眼看出程序碼品質有問題，例如：在特定條件下會爆掉、濫用復制貼上、采用一些骯臟寫法、程序可讀性很差、模組之間糾結在一起，等等。

你焊接過電路板嗎？要是電路板繞線一團亂、零件歪七扭八、接腳沒焊好，你能交差嗎？但是寫程序可以。因為程序碼是一種抽象產品，沒有「外觀」可以觀察。如果你的團隊要求code review，這個問題可以得到某種程度的改善，但仍不能徹底解決。程序員的紀律和職業道德很重要。

程序語言

程序語言的學習，是程序員最最基本的能力，而且應該至少精通一兩種語言。隨著程序經驗的累積，學習不同程序語言的速度會越來越快，例如從幾個月縮短到幾周。當然精通一門程序語言，不是幾星期、甚至幾個月就能達成的，但迅速接手并維護既有程序碼，是對合格程序員的基本要求。

通常第一種程序語言學最久，因為很多觀念也是第一次學，例如變數、回圈、陣列、遞回、I/O、網絡、多執行緒、物件導向、regular expression、functional programming……。等到學第二種、第三種程序語言，新的觀念越來越少，主要在學語言本身，速度就會變快很多。

數據結構及演算法

如果你是本科系畢業，數據結構及演算法應該是必修課。如果沒學過，建議花點時間學一下。倒不需要買一本厚厚的書折磨自己，但基本的概念一定要有，例如：

數據結構

陣列（array）、序列（list）、堆棧（stack）、隊列（queue）

樹（tree）、二叉樹（binary tree）、哈希表（hash table）

指針（pointer）：這也許不算數據結構，許多高階語言也不讓你用pointer，但是對記憶體、指標要有概念，這是程序員與非程序員的區別之一

演算法

對以上數據結構的各項操作

排序（sort）：至少搞懂3、4種基本的排序演算法，例如bubble sort、quick sort、merge sort等

搜尋（search）：depth-first-search、breadth-first-search、binary search等

其它：迭代（iteration）、遞回（recursive）、分治法（divide and conquer）、時間/空間復雜度的基本概念（big O）等

網絡上資源很多，Google一下、多寫一些程序練習，弄懂以上基本概念，應該就夠用了。

網絡協定

TCP/IP、HTTP、DNS等這些都是基本的網絡協定。不需要到專家程度，但身為一個程序員，除非你的工作與網絡完全無關（這種工作應該越來越少了），否則對這些網絡協定的運作應該要有起碼的了解。例如你能講清楚，從你在瀏覽器輸入一行網址到看到網頁內容，在網絡上發生了哪些事？以前我在Yahoo面試前端工程師的時候，喜歡問一個問題：請解釋cookie是怎么運作的，結果不少人答不出來。

當然現在的程序開發環境很方便了，各種library一大堆，我們通常不需要自己實做這些底層的東西。但不懂這些東西運作的基本原理，會讓你在debug時被卡住，因為整個網絡系統的運行，都是建立在這些基礎架構之上。這些網絡協定，再過很多年還是會繼續存在，花一點時間搞懂這些，我認為很值得。

除錯能力

講除錯能力不太準確，因為除錯不是單一能力，而是結合了經驗、對程序的了解、對系統架構的了解、抽絲剝繭的能力、直覺，以及各種hands-on能力的綜合，就像當偵探一樣。臺語有句話叫「醫生怕治咳，師傅怕抓漏」，差不多就是這個意思。

我在Yahoo工作期間，最刺激的事莫過于排全球on-call了。所謂on-call，就是全球Yahoo網站出包時，你要在最短時間內找出問題并修復，那真是超級debug。拜托，Yahoo網站那么復雜、程序碼又那么多，出問題的模組又不是我寫的，美國同事都下班了，誰知道怎么解決？對不起，那是你家的事，排了on-call你就得想辦法解決。功能上的問題還有跡可尋，最棘手的是像系統過載這類問題，爬log、寫script、trial-and-error，總之想方設法揪出元兇。

程序員應該具備良好的除錯能力，不管程序誰寫的。另外，修bug也是一門學問，是采用鋸箭法、貼狗皮膏藥，還是找到病灶、解決問題背后的問題，就看程序員功力了。

寫出可讀、易維護的代碼

這個要求聽起來很合理，不是嗎？其實這是最難的。寫程序這么多年，看過多少代碼，我跟你說，這個世界上的爛code占絕大多數，好code只占一小小部份。我自己也不斷在這條路上努力著，到現在也不敢說自己寫的code多好。

為什么這件事這么難？我想了一下，大概有以下幾個原因：

可讀性高的代碼，通常是用很好的解法，解決了真正的問題

例如牛頓的F=ma、愛因斯坦的E=mc 2，這是神人等級的功力（只是舉例說明，寫程序不需要到這樣）

你需要徹底了解問題（problem domain）

你需要考慮過至少幾種合理的解法（solution domain）

你需要對程序語言、程序庫、既有程序架構和可運用工具很嫻熟

你要能以簡馭繁，而這代表你掌握了更高的東西

你寫程序必須很有紀律，例如：

Bingo! 找到一段code了，看我的copy& paste

可以work就很好啦、這么漂亮的解法……

好累，我不行了，先commit code再說

不急著馬上寫code，先想清楚問題、解法、架構

恰到好處的注解，少了不行、過猶不及

用心想過的命名（程序界有句名言: There are only two hard things in Computer Science: cacheinvalidation and naming things .）

壓抑copy & paste及產出一堆爛code的沖動：

在commit code之前，自己再好好review一次（我個人經驗，通常這個步驟可以改進程序好幾個地方）

越容易維護、擴展的代碼，代表它的復雜度越低

當你輕易多用了一個外部組件、增加了一個external dependency，你就把它的復雜度整個帶進來了，所以要很小心

降低軟件復雜度是軟件工程的最大挑戰，軟件復雜度就像軟件的熵（我的第一篇英文blog “Software complexity is software entropy”，就是講這件事）

必須做到low coupling、high cohesion，而這兩件事都很難

低復雜度的軟件系統，代表里面各個模組的復雜度都必須更低

現實環境的因素，導致好的程序碼不易產生

專案時程的壓力

程序員經驗的限制

團隊未采用一些最佳實務

有決策權的人對軟件開發不夠了解

代碼品質的重要性，每個人都知道，連路人甲都知道。現實的難處在于：第一版的代碼，只要能work，品質好壞是很難看出來的；它們的差別，要到系統后續的運行、維護及擴展才能看出來，然而此時木已成舟，程序只能修修補補繼續用下去，最多小幅重構（refactor），直到軟件生命周期的結束。

寫出好的代碼，時間會花比較久、會導致專案時程延后嗎？其實并不會，這是能力限定，不是時間限定。寫出第一個版本，花的時間都差不多。但后續版本就差很多了，寫得越好的代碼越好改。你如果改過那種high coupling的系統，你就知道我說的意思了，那真是人仰馬翻，超high的。這種代碼要是裝在箱子里，箱子上會標示「易碎/FRAGILE」。

Photo credit: Hsing Wei@flickr CC BY 2.0

寫出好的代碼并不容易。假如我們從1分到10分給程序碼打分數，10分真的很難很難，我自己也做不到。但一般人經過努力，達到6、7分應該是沒問題的。如果你想看書，我在這里推薦一本：Code Complete 2nd Edition。教人寫程序的書中，這是我看過最好的一本了，只是內容比較多，需要時間消化。如果還有興趣多看，我個人覺得Martin Fowler也寫了不少好書。

程序員進階能力

具備以上的程序員基本能力，我想就足以勝任大部份「單兵程序員」的工作了。如果想在技術上更上一層樓，以下是幾個我認為比較重要的進階能力，提供給大家參考。

作業系統

大學修的那么多課里面，我感覺對工作最有用的就是「作業系統」這門課了。對作業系統（OS，operating system）的了解，是資深程序員應該具備的。例如：

Hardware: CPU, memory, I/O devices

Process, multi-thread, scheduling

Inter-process communication: signal,socket, pipe, named pipe, shared memory, message queue…

Synchronization, deadlock, mutex, semaphore

File system, cache, virtual memory, pagefault…

Real-time system, distributed system

作業系統本身就是一支超大型程序，有著無數前人的心血。加上作業系統的基本概念，幾十年不變，所以花點時間弄清楚這些觀念，我認為很值得。

數據庫

不是每個程序員的工作都會使用到數據庫，而且現在不少人用NoSQL存數據。盡管如此，我認為關連式數據庫（relational database）還是很重要，不管是MySQL、PostgreSQL、MS SQL或Oracle都好，資深程序員應該至少對其中一種有相當的了解。

題外話，多年程序寫下來，我對ORM（object-relational mapping）抱著存疑的態度。網絡上有篇文章：Object-RelationalMapping is the Vietnam of Computer Science，應該是反ORM的代表作之一，有興趣的人可以看看。還有一篇有名的文章：The Law of Leaky Abstractions，講的是每一層抽象化都或多或少會有漏洞。從leakyabstraction角度來看，SQL已經是一層有洞的abstraction了，而ORM洞更大！

網絡安全

網絡安全（network security）平時很容易被忽略，因為它費事費工，沒有立即效益。但是對網絡安全的輕忽，一旦出事，經常導致企業或政府重大損失。這讓我想起以前當社區管委會主委的時候，按消防法規要搞什么社區消防編組、演訓，還要指派防火管理人，真的很麻煩。安全這種事情就是這樣。

有些網絡安全議題，是屬于系統管理者的范疇，例如DoS (denial of service)、DNS spoofing、man in themiddle；有些則是程序員的責任區，例如SQL injection、cross-site scripting、cross- site request forgery等等。此外像驗證使用者身份的流程、儲存/傳送使用者敏感數據的方式，也都與安全有關。資深程序員對網絡安全議題及常見攻擊手法，應該要有足夠的認識與敏感度，并在開發過程中合理采取預防措施。

程序語言的多樣性

程序語言是程序員吃飯的家伙，除了每天工作上用到的，資深程序員也應該接觸一些不同的程序語言。例如：

函數程序語言

函數程序語言（functional programming language）是另一種風格的程序語言，可以挑一個好好學一下。我個人推薦Haskell，但F#、Scala、OCaml、LISP、R、Erlang、Clojure這些也都不錯，各有擁護者。

實際工作上，不見得有機會使用這些函數程序語言，但好好學一種，可以拓寬自己程序設計的思路。而且現在很多程序語言，包括C++（C++ 11之后）、C#、Java（Java 8之后）、JavaScript、Python、Ruby、Swift等等，都具備一定的functional programming能力，可以運用在工作上。

組合語言

除非是用C加assembly寫硬件相關或compiler/toolchain的人，組合語言在實際工作中很少用到。但我覺得應該了解一下，因為這是軟件的最底層，再往下就是硬件了。我中學時候寫過6502、8088，大學上過一堂MIPS組合語言的課，其實還蠻有趣的。寫過組合語言，會讓你對電腦如何執行程序更有「感覺」。
但是組合語言不用太認真學，因為真的很少用。學個概念、最多寫幾個小練習即可。

Shell Script

如果你工作中有用到Linux/Unix相關的OS，我建議應該要學一種shell script，例如bash。如果你是ops/service engineer或系統管理者，這應該是必備能力了，不過資深程序員最好也能懂這些。就像vi一樣，有些東西已經很古老了，但網絡世界就這么運作著。沒辦法在terminal環境工作的人，很多問題處理起來就顯得笨手笨腳。

與技術無關的

除了專業技術能力，我再補充一些非關技術的心得。

克制砍掉重練的沖動

在開發過程中，程序員很容易對既有程序碼產生一種「這誰寫的？砍掉重練比較快」的沖動，包括我自己在內。我想可能的原因有：

砍掉重練其實比較容易（拆掉舊屋蓋新屋很快，保留這面墻、那扇窗的反而更困難）

在自己的地盤當山大王很開心（人都喜歡按照自己的意思來）

在系統發展的過程中，很多需求后來才出現，使當初的架構顯得捉襟見肘，但在當時其實是很合理的設計

上線多年來，程序員處理了很多狀況、修復很多bug，因此程序顯得沒那么干凈優雅

寫程序比讀程序容易

文人相輕

（排除以上各種因素之后）當初的程序碼真的寫很爛

不管怎樣，砍掉重練（rewrite）的代價，通常比乍看之下高許多，而且日后維護你的程序碼的人，心里可能同樣嘀咕「這誰寫的，砍掉重練比較快」。Joel Spolsky在2000年寫的一篇“Things You Should Never Do, Part I”，今日讀來依然犀利。

小幅重構（refactor）是沒問題的，而且可以經常做。

理解不同人的立場

當我們在某一方面懂得比別人多時，容易產生一種傲慢，技術人員也是。在專案開發的過程中，除了技術團隊，還有產品/專案經理、主管、客戶、使用者等不同角色的人介入。在技術方面懂得比別人多，并不妨礙我們理解他人的立場。當我們能站在別人的角度看問題，常常一下子就能了解為什么事情會這樣。例如：需求改來改去、一開始不講清楚、進度卡在別的team上面、「請你用最快方式完成」、「先支援這件緊急要求」、沒人把我講的話當一回事……
做到理解他人或是同理心（empathy），其實并不容易，因為每個人都有自己的立場，而人們傾向站在自己的立場看問題。我費了很大功夫，一直在努力修正自己技術傲慢的心態。如果你技術很厲害，又能做到理解別人，那真的很不簡單，你所在的團隊運作一定更為順暢。

參與社群，吸收新知，寫點東西

不管公司大小，資深程序員若只把觸角局限在公司內部，會越來越封閉。接觸外面的社群、吸收專業領域的新知、寫點東西累積自己的專業credit，會讓自己成長得更快。現在參與社群的管道很多了，從專業聚會研討、開源碼專案到各種社團，五花八門，不過還是得衡量一下自己能投入的時間。單身的人比較有空，有家庭有小孩就只能斟酌參與了。

吸收新知是為了讓自己保持在敏銳狀態，不要變成滅絕的恐龍，但也不用太過焦慮。軟件領域變化快速，各種語言、框架、技術不斷冒出來，要追新知永遠追不完。如果你時間充裕，可以到處追新知，那很好。若你時間有限，我的經驗是：等到很多人都在談論的時候再去了解一下，也就夠了。跟工作有關的，根據自己在團隊中的角色，適度學習即可。

另外，我建議有幾年工作經驗的程序員，都應該考慮寫點技術文章，累積自己的專業credit。這種事情沒有看起來那么可怕，一回生二回熟，包括找主題、寫文章，多試幾次就會上手。也不用給自己太大壓力，一、兩個月寫一篇都可以，長短不拘，日積月累，會有收獲的。

程序員之后

寫程序能夠寫幾年？每個人情況不同，但無論如何，大多數人不會寫一輩子。

當了單兵程序員若干時日之后，最常見的角色轉換就是先成為Tech Lead帶組員（不同公司對這個角色有不同安排方式），此時除了寫程序，還要負責帶團隊、對外溝通、掌控時程、照顧組員、處理突發狀況等等。如果公司夠大，公司可能還會提供更多資深技術職位，例如Architect角色。

技術職之外，有的人會走管理職，有的人走專案管理或產品經理，甚至業務、行銷都有；如果喜歡走技術，有的人會跳槽到條件更好、發揮空間更大的公司，其實選擇不少。如果有心創業或加入創業團隊，扎實的技術底子也會令你如虎添翼。

結語

最近學程序設計忽然變得很流行，「一小時學程序」、小學生學程序，好像程序人人都能寫似的。當然練習寫幾行小程序是沒問題，透過這些訓練邏輯能力也很好，但真實世界的程序，復雜度遠遠超出這些沙盒小練習。事實上，隨著電腦及網絡技術的發展，現在的軟件開發比起一、二十年前更復雜了，有時我都很佩服現在剛出校門的學弟妹們，要學的東西這么多，他們是怎么辦到的。
洋洋灑灑寫了一大篇，其實很多也只能點到為止。希望這篇文章，對大家有一點幫助！

歡迎光臨 (http://www.raoushi.com/bbs/)

<input id="coquo"></input>