程序員生存定律--編程的起點與可能的失足

程序員生存定律這系列的目錄在這裏：程序員生存定律--目錄

喜歡從頭瞄的，能夠移步。

------------------------------------------------------------------------------

從大環境來看，想不寫程序直接去作管理工做是很難的。大多時候都要在開發上作出必定成績，接下來纔有選擇技術仍是管理的機會。所以即便是但願選擇管理方向，技術上的基本功仍是須要的。因此下面這節的內容和選擇作管理方向仍是技術方向關聯不大，只要是想作程序員，大體上都有必要一讀。

從那裏開始編程生涯

大學裏常常會開設軟件工程專業，在這門課程裏面大多時候會講解需求工程、開發模型、設計方法、項目管理等。但不少同窗會感受這課程讓人摸不着頭腦，認真學也學不到什麼。從這種廣泛現象能夠發掘出一些本質問題。

這裏的本質問題是指軟件開發是實踐性很是強的科目，所以不適合先從概念開始。這不意味着軟件工程、設計思想不重要，而只是說不適合從純粹的概念開始學習編程。 

在軟件這個行業裏，不少比較資深的人員對如何學習編程是有統一認識的：學一點，實踐一點，再學一點，再實踐一點。但困難的是每一個人對每次迭代的「一點」到底是多少認知不一樣，對「一點」是什麼的定義也是不一樣。

我我的的觀點是以3000代碼行爲界算第一個一點，也就是說一我的學會某個語言後小練習不算，先完成一個3000代碼行左右的，沒有UI的獨立程序。爲解釋什麼叫獨立的程序，舉一個具體的例子。

在《敏捷軟件開發：原則、模式和實踐》一書中有一個薪水支付的例子程序，正好是這個規模，很適合幫助達成這一目的。這個程序的基本規格說明是：

（下文引自《敏捷軟件開發：原則，模式與實踐》）

• 有些僱員是鐘點工。會按照他們僱員記錄中每小時報酬字段的值對他們進行支付。他們天天會提交工做時間卡，其中記錄了日期及工做小時數。若是他們天天工做超過8小時，那麼超過的部分會按照正常報酬的1.5.倍進行支付。每週五對他們進行支付。
• 有些僱員徹底以月薪進行支付。每月的最後一個工做日對他們進行支付。在他們的僱員記錄中有一個月薪字段。
• 同時對於一些帶薪(Salaried）僱員，會根據銷售狀況，支付給他們必定數量的酬金。他們會提交銷售憑條其中記錄了銷售的日期和數量。在他們的僱員記錄中有一個酬金字段。每隔一週的週五對他們進行支付。
• 僱員能夠選擇支付方式。能夠選擇把支付支票郵寄到他們指定的郵政地址；也能夠把支票保存在出納人員那裏隨時支取；或者要求將薪水直接存入他們指定的銀行帳戶。
• 一些僱員會加入協會。在他們的僱員記錄中有一個每週應付款項字段。這些應付款必需要從他們的薪水中扣除。協會有時也會針對單個協會成員徵收服務費用。協會每週會提交這些服務費用。服務費用必需要從相應僱員的下個月的薪水總額中扣除。
• 薪水支付程序每一個工做日運行一次，並在當天爲相應的僱員進行支付。系統會被告知僱員的支付日期。這樣它會計算從僱員上次支付日期到規定的本次支付日期間應付的數額。

 

在學完編程語言、面向對象、UML以後能夠先參照這份規格說明，什麼例子程序都不看，本身完整的作一份實現，實現中要包含UML圖和代碼，接下來能夠去把Robert C.Martin的例子程序下載回來，同本身的實如今設計上和實現細節上作詳細的比較，找出那點本身好，那點Robert C.Martin的好。這樣對編程語言、對面向對象、對設計原則就能夠有比較踏實的一些理解。此外，這個程序的一個額外的好處是它能夠徹底獨立於平臺，只依賴於語言和標準庫便可。 

假設說一個新手已經熟練掌握了一門語言，那麼完成上述的任務估計須要2~4人周，固然有經驗的人1我的周左右已經足夠了。

在此以後，能夠精讀一個上點規模的（1~5萬行最佳）獨立性比較強的應用程序，因爲已經上了規模，作到徹底的與平臺相隔離就有點難了，無法提供統一的例子做參考。但選擇標準主要有兩個，一個是儘量和本身將來指望的方向相吻合，一個是儘量比較獨立和經典。獨立的目的是方便調試，經典的目的是確保代碼質量。好比：若是是Windows本地應用就能夠考慮Notepad++類的開源應用，Web應用就能夠考慮WordPress等。這個時間點上須要避免好高騖遠，Linux內核與Chrome固然很好，但它們並不適合初學者的。 

在精讀過程當中可能須要幾類書籍：一是平臺框架相關的（線程機制等），一類是模式相關的，一類是工具型的書（如何調試）。這個時候是要耐下心來讀幾本比較經典的書的。 

精讀以後，就要再找到一個項目來實踐。這裏的關鍵是真的項目，至少要有真的用戶，而且用戶數目越多越好。最好是可以向知名開源項目提交代碼。 

各類基礎知識中比較例外的是計算機體系結構、數據結構和算法這類理論性比較強的東西，這種學習曲線比較陡的東西須要結合大學的課程把它學會，接下來再在實踐中逐漸應用，而不能一邊作事一邊學習。緣由是學習曲線越陡的東西越須要大塊時間，畢業以後再學效率會差。 

總的來看，上述幾個步驟，應該在大學畢業後2~3年內完成，最好在大學裏完成，這樣可能會有點優點。這些完成以後，打基礎階段能夠算是基本結束。

 

 

打牢根基 VS 速成道路

 

有不少不一樣的方法能夠學會編程，好比說：一我的既能夠先打牢基礎，接下來再逐步學會如何進行各類開發工做；也能夠無論三七二十一，先借助各類IDE把程序作出來再說。上一節主要介紹的是先打根基的方法，而不是速成的方法。 

 

相對於打根基的方法，後一種學習方法更容易在短期內看到效果，因此不少人都是這麼入的行，好比：先從IDE開始，接下來再從表面往本質去學，逐步去了解控件拖放背後所隱含的東西。這不能說徹底很差，但我認爲這是一種失足，幾乎必定會催生程序員只能吃青春飯的結果。 

 

在剛開始編程的時候，若是造成對IDE的過分依賴，那就會致使根基淺薄，能作的事極可能被限制在某個有限的範圍內。當下的大多IDE功能已經很是強勁，這對提升產品的生產率無疑是很是有必要的，但在學習階段，則要儘量避免過分依賴於IDE，避免用各類控件來快速完成任務。 

 

好比說：微軟在Visual Studio 2012裏面內置了一種名爲LightSwitch的技術，基於這項技術，一我的能夠在基本不編碼的狀況下，完成信息系統的開發，並支持相對比較豐富的功能（增刪改查，搜索，排序等）。無疑的基於這樣的工具作開發速度會快上不少，但在學習階段過分使用這類工具，卻會毀了一我的的根基。 

 

想象一下，在使用LightSwitch的過程當中一我的會學到什麼？他所能學到的主要是這種工具的使用方法，既不會學到SQL語句，也不會學到數據庫表格的設計方法，也不會學到ASP.net的基本架構（雖然ASP.net已經封裝了很是多的東西）。這樣一來，這我的雖然可以快速的完成某個工做，但卻給本身埋下了很深的隱患---他很容易的被束縛於某個工具，而且沒法應對新領域。 

 

善用IDE集成好的功能進行快速開發不是學習階段應該作的事情，學習階段最根本的目的是打基礎，把一門語言學精，把一種設計思想學精，把一種算法學精等等，這種基礎可能不直接表現爲生產力，即便把算法學精了，可能仍是沒法馬上寫出來比較炫的程序，但這有助於面對不停變化的世界，這與單純的達成某個目的，完成某個程序不一樣。這能夠類比爲打地基與蓋樓，地基部分顯然不能單獨進行銷售，也不能住人，但沒有地基也就沒有其上幾十層能夠高價售出的住宅，樓越高，地基也就越深。固然，只蓋地基或者讓五層樓和五十層樓使用同樣的地基也不必，這不用多說。

 

 

 

那具體來說，那些東西能夠被認爲是編程的根基，須要在學習階段紮實的掌握？下面將經過推薦幾本書（或者說幾類書）來描述一個共通於全部程序員的最小集合。 

 

• 計算機體系結構

 

這一類別下最具表明性的書籍是《深刻理解計算機系統》，做者是Randal E.Bryant和David O’Hallaron。讀這本書的目的是瞭解計算機究竟是怎麼個東西，軟件到底運行在什麼樣的基礎之上。

 

• 算法和數據結構

 

這一類別下最具表明性的書籍是《算法導論》，做者是Thomas H.Cormen，Charles E.Leiserson，Ronald L.Rivest，Clifford Stein。讀這本書的目的是瞭解軟件到底能夠用什麼樣的手段幹些什麼事情。軟件是一種工具，能夠幫助解決人類面臨的許多問題，而主要手段則只有兩種，一種是這本書裏所介紹的算法和數據結構；另外一種則是下一類別中所涉及到的分析和設計方法。它們像小刀子同樣，能夠把各類領域中的各類問題進行分割，並映射到程序的世界裏來。　

 

• 設計原則和模式

 

這一類別中比較有表明性的書籍是《敏捷軟件開發：原則、模式與實踐》，做者是Robert C.Martin。讀這本書的目的是瞭解數據結構和算法以外另外一種對現實問題進行抽象的方法如面向對象以及進行這種抽象時所要遵照的原則。

 

這類書籍經典的還有不少好比：GoF的《設計模式》，而之因此選擇上述這本是由於這本書裏提供一些比較完整的例子，更適合初學者一些。

 

• 軟件工程

 

這一類別中最具表明性的書籍是《代碼大全》，做者是Steve McConnell。讀這本書的目的是創建對軟件開發的全局視圖。知道一個軟件從無到有所要經歷的一系列過程。

 

軟工的書還有不少，好比頗有名的《人月神話》，但《人月神話》類書其實對不少人是不適合的，對初學者就更不適合。

 

 

 

上面四本書是一個最小集合，針對不一樣場景須要進行不一樣的增長，好比可能須要進一步瞭解某種框架的機制，那就須要讀《XX技術內幕》這類書。但即便是讀這幾本書也不適合只讀書而不動手，最好是穿插在上一節中提到的實踐中來讀，不然的話對後兩本的理解會有所欠缺。

 

若是想走厚積薄發這條路的上面幾本書是必定要預先讀通的。閱讀過程當中，若是發現有些細節問題完全沒法理解，那就要在實踐過程當中進一步琢磨，找到本身的答案。讀這類書時，有一件事情必定要有心理準備：雖然這些書讀通並不容易，很花時間，但想讀了這些書後馬上寫出來一個能賣點錢的工具是不太可能的，這真和大樓的地基同樣，沒什麼立竿見影的效果。若是想盡快達成後者這樣的目的，那極可能就要走速成的道路，去讀些介紹IDE怎麼用，某個框架怎麼用的書，好比：《C#高級編程》這類。

 

爲避免誤解，有一點須要額外進行一點說明。前面強調的避免過分IDE依賴主要是指不要用封裝良好的模塊來取代對基礎知識的學習，不是說不須要創建本身的工具箱。查找工具、調試工具（進程線程查看等）、二進制數據查看工具、正則表達式工具、持續集成工具、文檔生成工具（JavaDoc)、正則表達式工具等對一個程序員的生產力是很是有幫助的，應該在學習過程當中逐個掌握。軟件開發工做發展到如今，任何一個類別下面都有至關多的比較成熟好用工具了，關鍵是選定一個把它用熟。

 

------------------------------------------------------------------------------

 

關於我本身的各類信息，在左邊欄可找到，想了解下寫這系列文章的人是否是騙子和大忽悠的能夠瞄。

 

最後但願感興趣的支持V衆投，感受上這應該是國內最靠譜的生活購物等的問答社區了吧，都是朋友給朋友作的答案，同時實行一人一號，一人一票制度，想找什麼答案關注公衆號：vzhongtou（左側有二維碼）就好了。