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

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

喜歡從頭瞄的,可以移步。

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

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

從那裏開始編程生涯

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

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

在軟件這個行業裏,很多比較資深的人員對如何學習編程是有統一認識的:學一點,實踐一點,再學一點,再實踐一點。但困難的是每個人對每次迭代的“一點”究竟是多少認知不同,對“一點”是什麼的定義也是不同。

我個人的觀點是以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.BryantDavid O’Hallaron。讀這本書的目的是瞭解計算機到底是怎麼個東西,軟件到底運行在什麼樣的基礎之上。

  • 算法和數據結構

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

  • 設計原則和模式

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

這類書籍經典的還有很多比如:GoF的《設計模式》,而之所以選擇上述這本是因爲這本書裏提供一些比較完整的例子,更適合初學者一些。

  • 軟件工程

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

軟工的書還有很多,比如很有名的《人月神話》,但《人月神話》類書其實對很多人是不適合的,對初學者就更不適合。

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

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

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

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

關於我自己的各種信息,在左邊欄可找到,想了解下寫這書的人是不是騙子和大忽悠的可以瞄。

最後希望感興趣的支持V衆投,感覺上這應該是國內最靠譜的生活購物等的問答社區了吧,都是朋友給朋友做的答案,同時實行一人一號,一人一票制度,想找什麼答案關注公衆號:vzhongtou(左側有二維碼)就行了
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章