很認真的聊一聊程式設計師的自我修養

   今天逛部落格園，看到了一篇推薦的文章《淺談程式設計師的英語學習》，就點進去看了一下，對於文章中的觀點我非常認同，英語是非常重要的，但文章站的高度還是太高，具體表述的學習方法我不是很認同，也認為不太實際，恰好之前有一篇一直沒有發表到首頁的文章想重新發布，今天就藉此機會和大家很認真的談一談程式設計師的自我修養問題。

    先介紹一下利益相關，我的背景：

初中開始參加資訊學與數學競賽，大學本科軟體工程專業，畢業後在銀行做大資料分析與專案管理，後自主創業，做過傳媒公司、軟體外包公司，現在中國（南京）軟體谷有個工作室，做些自己喜歡的事情。15年編碼經驗，6年創業經驗。主要技術方向是.NET、HTML5、雲服務、應用級開發等，自我整體水平評價為，資深程式設計師、初級架構師

 

首先要談的是，今天的話題所聊的程式設計師包含哪些人？

    在說之前，不得不提到一個很有名的程式設計師趙劼，他有過一個觀點：“堅決反對北大青鳥等機構”，以前我也很贊同這個觀點，但是現在，我在“贊同的基礎上”，又堅決反對甚至反感趙劼們“發表這種觀點”。因為這種觀點，能夠幫助並作用到的人群，是趙劼們最不可能遇到的基層開發人員，而這些最不可能遇到的人，卻恰恰是在中國的最普遍的程式設計師，他們也是趙劼們最不可能甚至不太願意幫助的人。如果一個高階程式設計師，自恃理科基礎好，邏輯性強，有過完整的語言學習經歷，就認為至少達到這樣才是程式設計師，甚至覺得其他的不學資料結構的人就不要做程式了，那真是非常的妄自菲薄。

在中國，寫程式，不僅僅是一種興趣，更多的時候，還是一種普通職業和謀生工具

大公司有厲害的程式設計師，優秀的架構師，但大量的小公司也有很多普通的程式設計師。在我這些年的工作經歷中，也越來越深刻的感受到普通程式設計師的影響和力量。對於高階程式設計師，所謂八仙過海各有神通，各有各的成就，各有各的修養，但程式設計師在達成較高的水平之前，有一些“自我修養”，是最基礎的，是普世的。

所以今天的話題面向的程式設計師，就是所有的正在寫程式碼或者曾經寫過程式碼的程式設計師，也包括廣義上的程式設計師，例如專案經理、架構師等等。

 

做任何事都是有明確目的，那麼

再談一談，程式設計師提高自我修養是為了什麼？

    程式寫的好有人崇拜，有妹子喜歡？還是到部落格、論壇、社群發表文章進行分享獲得成就？我想這是少數人的追求，也是更高的追求，在這之前

我認為，在中國，程式設計師提高自我修養的目的，是為了

1、更好的融入工作，減少困難，增加成就

2、穩步的提升能力，提高收入，達成財務自由

2、站在更高的層面看待自己的學習和工作，樹立更加適合的人生觀價值觀，家庭幸福，生活愉快

說的更通俗一點，就是用更加合理的方式和方法，賺取到更多的收入

 

說了這麼多廢話，進入正題

何為程式設計師的自我修養？

    正面論述很難說清楚，反向描述可能更通俗易懂一些，自我修養的對立面是“沒有修養”，先說一說在這麼多年的工作、學習、生活中，遇到的一些我認為“沒有修養”的程式設計師形態：

1、程式設計師小張遇到了一個開發問題，很著急，想到了有幾個群，於是到群裡發了他的問題，坐等回答，發現沒有人回答，就直接對話群主的QQ，群主也不回答，於是小張就搜尋，突然搜到部落格園有個帖子講解了相關話題，他看完就給博主留言，我的郵箱是：XXXXX@qq.com，麻煩博主把原始碼發給我一下，謝謝。

2、程式設計師小張進公司3個月了，老闆佈置了很多工，他覺得老闆很沒人性，工資給的不高，加班也不給錢，於是在寫程式碼的時候能省就省，客戶反饋有問題也不主動解決，敷衍為主，又過了一個月，跳槽了。

3、程式設計師小張正在寫一個功能模組，需要進行某種加密，到百度搜到了一個編碼模組，看不明白具體寫了什麼，但是放到程式裡剛好適用，於是就這麼原封不動放進去了。

4、程式設計師小張要對某個功能進行研發，專案經理對他說，這個功能應該能搜尋到，你去搜搜看，小張就在百度搜啊搜，一天過去了啥都沒找到，專案經理來到小張身邊坐下，換了個關鍵詞，1分鐘就搜到瞭解決方案。

5、程式設計師小張學.NET已經工作3年了，工資還是10000，和公司提漲工資也沒答應，想跳槽又猶豫，這時某個前輩對他說，你去看書吧，多看一些書，例如 《Visual C# 從入門到精通》，《CLR via C#》《Javascript權威指南》等等，於是小張買回來了， 隨手翻了翻發現有些東西是他已經會的，有些看不懂的好像又用不到，而且書這麼厚，要不要浪費時間去看呢？小張就這樣反覆糾結了半年，依然每天上班工作，下班LOL，偶爾還抱怨一下工資低。

6、程式設計師小張到了一家新公司，在做一個專案實現某個功能時，想起來以前做過這樣的功能，可是竟想不起怎麼實現了，於是就到自己電腦上找文件，找了好久也沒找到，只好放棄，最後又折騰了2天，終於還是把這個功能給實現了。

7、程式設計師小張某天非常不高興，因為他的專案經理和專案組的產品人員又變更需求了，新的需求又要對整個結構進行大的調整，小張很鬱悶，到一個QQ裡發洩情緒，說了這個事，於是立馬，QQ群裡面炸開鍋了，程式設計師小李說，對，產品就是狗日的！程式設計師小王說，對，他媽的專案經理整天高枕無憂，就知道壓榨開發人員！程式設計師小孫說，是的是的，我上一家公司也是這樣，壓榨程式設計師，幸好我走了。就這樣，在一片罵聲中，幾個程式設計師心情舒暢了，小張開心的去玩王者榮耀去了。

我想，有些人可能已經明白我要說什麼，有些人可能還不明白，具體的話我也說不出來，只能用一句話來概括就是：

在編寫程式碼的過程中，善於學習、掌握方法、勤加思考、勤奮努力、持之以恆，長此以往，在程式設計中，你會發現不一樣的自己。

 

以上這些還是比較抽象，那麼

提升自我修養的具體方法有哪些？

程式設計師具體如何達成“較高的修養”，每個人各有自己的辦法，我無法說到很細，就和如何提高做人修養一樣，一句兩句話是說不清楚的，但是有些說法也通俗易懂，比如一個小孩，有教育良好的父母，父母彬彬有禮，小孩從小開始接受正規教育，小學、初中、高中、大學，然後文化課程和社會實踐良好，那麼這個小孩最終的做人修養，一定比沒有經歷過這個過程的小孩更好一些。

同樣的，寫程式也是如是，下面我就講一些最基本的、最淺顯易懂的學習方法和道理，我把它叫做：

程式設計師基礎的基礎

一個好的開發人員，應該能夠全面、高效、嚴謹的去處理任何軟體程式和業務問題，成為一個好的開發，是一個很有意思的話題，不過無論這個話題如何開展，基礎兩個字必不可少，雖然程式碼量是衡量開發能力的重要指標，但僅能夠熟練的進行程式碼編寫是不夠的，更要能深刻的理解技術原理和業務邏輯，紮實的個人基礎和技術基礎往往會促進程式碼的編寫，更遊刃有餘的解決問題。

下面說的一些基礎，可能絕大部分開發人員都不會在意甚至忽略，但恰恰這些才是開發大廈的基石。

1、科學基礎

成為開發人員的過程不盡相同，有的是科班出身，有的是興趣愛好，還有的是專業機構的培訓，在這個過程中，可能全面或者零散甚至沒有學習過計算機基礎學科，但無論是哪一種，想要成為更高層次的開發人員，寫出更高質量的程式碼，計算機基礎學科的學習，是非常非常非常（重要的事情說三遍）重要的。具體的來說，基礎學科在實踐應用中，有如下幾門是一定需要的，按照學習順序排列如下

1）資料結構

資料結構課程通俗的說就是告訴你如何用最基本的語言型別、變數，關鍵詞語句等，去處理各式各樣的邏輯問題，我們稱之為演算法，而日常程式設計中的各種問題，例如排序、資料夾遍歷操作、資料庫查詢等，都可以在資料結構課程中，找到對應的數學原型。資料結構課程的理解能力，也是一個人數學能力的體現，資料結構學習的好壞，是程式設計師水平差異的一個重要分水嶺，對於這一塊內容的學習，有如下建議：使用VB、C、C++、Pascal等語言，買一本相關語言資料結構與演算法的書，或者在網上下載相關的PDF電子書，完整的學習一邊，並將書本中的所有案例親自編寫執行除錯一遍，當能夠領悟到某些日常程式設計中常見手法源於某些資料結構和演算法時，就基本達到了學習效果。

2）作業系統

      所有程式語言的開發以及應用的執行，都基於作業系統，桌面程式設計中的大部分場景包括記憶體、程式、檔案系統、網路通訊、使用者介面等，都源於作業系統的定義和概念，完整的瞭解作業系統的起源和組成以及執行邏輯，對多執行緒、複雜介面、檔案管理以及一些難以正常理解程式設計思路等開發中遇到的場景，有非常大的幫助，不僅幫助理解，也能掌握更多有效的程式寫法。具體可以買一本作業系統的書或者下載相關PDF電子書，完整的瀏覽一遍，做到能夠結合實際程式設計場景來看待作業系統原理，就基本達到了學習效果。

3）資料庫

      傳統的關係型資料庫，入門簡單，深入卻難，往往開發人員能夠較快的掌握增刪改查、檢視、索引、儲存過程等基本資料庫操作，卻在編寫複雜查詢、設計主外來鍵、優化欄位、去除冗餘等時，出現只會依葫蘆畫瓢卻不能自主思考擴充套件的狀況。究其原因還是沒能瞭解關聯式資料庫的根本原理，而資料庫這一門課程，系統的闡述了關係型資料庫的來龍去脈，瞭解其中的數學原理或邏輯基礎所在，對提升資料庫程式設計水平有質的影響。建議也是買一本資料庫的相關書籍或者下載PDF電子書，能夠把熟練的把第一正規化、第二正規化等資料庫課程的基本知識點與資料庫程式設計場景建立起關聯，也基本達到了學習效果。

4）編譯原理

      編譯原理是程式語言以及各類語言編譯器的科學基礎，可以說編譯原理創造了世界上的幾乎所有的IT應用，學習編譯原理的基礎是資料結構和演算法，因此編譯原理的學習要花費更多的時間和精力，由於現代高階程式語言的編譯器，在程式碼優化、資源優化方面已經做的足夠智慧，因此，編譯原理的學習對實戰的影響越來越小，但是正所謂本盛末榮，如果認為自己對資料結構和演算法的學習達到了一個較高的水平和狀態，可以在編譯原理學習上進一步深入，最終把自己和普通程式設計師拉開更大的差距。

2、英語能力

    英語的天然特性和字母長度還有學科發展的歷史因素，決定了程式語言一定是基於英語的，在程式設計過程中，從語言的關鍵詞到文件的內容又或是搜尋引擎的搜尋結果，都不可避免的會遇到英文。大部分程式設計人員，都具備英語四級左右的英文基礎，卻由於非專業以及工作環境原因，逐漸疏遠甚至完全淡忘了英語。而實際操作中，大部分程式語言資料都是英文，線上程式設計問答內容也是英文，因此，很有必要把英語能力重新恢復到一個不用太高但行之有效的水平，達到如下效果：

1）對自己所使用語言，每一個關鍵詞都知道具體的英文翻譯、邏輯含義以及讀音。

2）對於自己使用語言所涉及到的相關方法、類庫、框架、工具等，能知道其中每一個方法、過程以及引數關鍵詞等的英文翻譯、邏輯含義以及讀音。

3）對常見的程式設計邏輯和核心關鍵詞，能夠用英文組織問題的描述，最簡答的也行，只要能被搜尋引擎讀懂就可以。比如如何在C#中把整形轉換為字串型別這個問題，最簡易的英文描述就是 C# Integer Covert To String。

4）在自己技術知識範圍內的任何的英文的技術手冊、文件、文章或是問題描述，能夠讀懂8成的內容含義，能夠讀懂完整的技術含義。

3、搜尋方法

    任何一個開發人員，都應當具備搜尋能力，甚至是一定要具備搜尋能力，搜尋引擎的寶藏，是無窮無盡的，同樣具備搜尋意識的不同程式設計師，卻因為搜尋技巧的差異最終在程式開發質量、專案實施效率、甚至是工程產品質量上出現數倍的差異，因此，掌握高效、先進、靈活的搜尋方法和技巧，是非常非常非常（重要的事情說三遍）有用的。其中主要的方法介紹如下：

1）搜尋源選擇

• 雖然英文的程式設計資料更為準確高效，但中文的程式設計資料數量上卻佔優，因此遇到問題第一搜尋選擇還是百度
• 谷歌對於專業中文詞彙的處理能力有時候甚至比百度還要強，而且谷歌能搜出大量的英文資源，因此谷歌也是首選之一，但是由於谷歌被封鎖，因此需要進行VPN、SSH等FQ操作，或者在百度搜尋“谷歌映象”關鍵詞，通過谷歌的映象網站進行訪問。
• 除了搜尋引擎，專業的技術網站、論壇、社群也是非常直接有效的搜尋源，比如國外的StackOverFlow網站，國內的Cnblogs部落格園、OSChina開源中國等，都具備搜尋功能，將問題關鍵詞輸入其中，也許也會很快的得到相關答案。
• 對於QQ群，建議不要使用，除非QQ群主或者成員是非常閒或者非常非常熱心的人，否則在QQ群詢問技術問題，是非常低效率的搜尋方式。

2）關鍵詞構造

    搜尋關鍵詞的構造，直接影響搜尋效率和正確結果的過濾，沒有什麼特別的技巧，關鍵在於搜尋積累，但是總體遵循的原則是，準確和簡潔，比如當出現一個描述，如何用C#對XML進行序列化和反序列化，非常愚蠢的關鍵詞構造就是“如何用C#對XML進行序列化和反序列化”，而正確高效的關鍵詞則是“C# XML 序列化 反序列化”,或者在谷歌裡面搜尋則是“C# XML Serialization”。在平時的程式設計中，一定要注意相關方法和經驗的積累

3）聯想搜尋

    聯想搜尋，不屬於搜尋引擎的範疇，卻是在搜尋中很有用的高階技巧，舉一個通俗的例子，比如想使用C#，利用某個.NET類處理一種HTTP通訊，但是一直搜尋不到完美的結果，不過換個思路，考慮到VB.NET也是.NET體系，和C#完全相通，那麼也可以試著用VB.NET關鍵詞進行搜尋，搜尋到完美程式碼後再臨摹成C#程式碼。這樣的聯想搜尋，不僅能夠幫助搜尋正確結果，也是對大腦思維的訓練，值得多多嘗試。

4）資源搜尋

    開源的框架、產品、工具、控制元件等開發輔助類東西越來越多，穩健性和迭代性越來越強，去尋找一款成熟的工具或者外掛，也成為了大量開發者的必備方法和技能，而如何高效的搜尋出想要的資源，也成為了一門學問，其核心方法就在於知曉資源網站的地址，常見的例如有開源中國、Github、CSDN下載、pudn等。資源類網站需要平時多積累，到用到的時候會非常關鍵。

4、思維模式

    開發人員，一定要養成業務思維的模式，所謂的業務思維，就是在做任何一個專案的時候，寫任何程式碼前，需要對專案本身的業務概念和業務邏輯甚至業務流程都要有一個全面的學習和理解，這雖然不是一個專案的強制要求，卻是一個很好的開發習慣，無論自己的覺得是開發者還是測試員又或是技術總監，掌握了業務原理，才能夠更好的設計或閱讀專案的資料結構和流程結構。程式設計師的思維往往和使用者或者客戶是不一致的，擺脫技術思維模式，習慣於用業務思維解決問題的程式設計師，不一定最優秀，但一定是一個很容易溝通的程式設計師

5、工作與程式設計習慣

    有的人說愛乾淨浪費時間，所以不修邊幅，但歸根結底這還是習慣問題，當養成清潔衛生的習慣並使之成為生活慣性時，往往就不會耗費更多的時間，反而顯得乾淨幹練。寫程式同樣如是，有一些程式設計習慣，看似不足為道，看似浪費時間，可是如果堅持下去，最終都能收到意想不到的奇效。下面列舉一些特別重要的習慣。

1）快捷鍵的使用

    無論是使用Windows、Linux作業系統，還是在IDE中，快捷鍵都是系統本身的標配，事實上，Ctrl+C、V這樣的操作，大部分人都能嚐到在節省時間上的甜頭，把這個概念進一步擴散，如果在IDE中編寫程式碼，除了程式碼本身，將其餘所有的滑鼠操作、鍵盤定位操作，都用快捷鍵來代替的話，在時間上將會有數量級的節省，然而看上去這麼好的事情，真正堅持去執行並形成習慣的人屈指可數，因此，在初期的改變習慣，記住快捷鍵，會是一個長期的過程，需要不斷的堅持。

2）程式碼註釋

    一個開發人員隨著年齡和經驗的增長，所參與的專案，再也不是靠一個人或者幾個人就能完成的。系統的重構、程式碼的重構、工作的交接、對新進人員的培訓等等類似的事情，會越來越多的遇到，這些事情無一例外都會把已經寫過的程式碼重新或者重複閱讀，如果在初始編寫程式碼時，就做到完整、清晰明瞭的程式碼註釋，對後續工作會有巨大的幫助。不僅提高工作效率，還能增強合作好感。事實上，就算只是自己看自己的程式碼，如果有註釋，也能加深印象，縮短程式碼查詢時間。因此，任何開發人員，都應該養成良好的程式碼註釋習慣。

優秀的程式碼註釋應該能做到：

• 每一個函式、每一個屬性甚至是變數的劃分，都可以找到對應的解釋。
• 多使用越來越被IDE支援的XML註釋方式，不僅有註釋文字，更有詳細的引數描述。
• 對程式結構、模組、組成部分劃分等也加以註釋

3）命名規則

    具備一定規模的軟體公司，在程式碼編寫上都有一套自己的命名規則，涵蓋專案、模組、函式、變數等等，標準化命名的好處不言而喻，然而被動、被迫去遵守命名規則和主動習慣於使用命名規則是完全不一樣的。一個優秀的開發人員，應當發自內心的希望各種程式碼命名都是有規則的，易讀的，而不是糾結於命名規則會增加碼字長度。

4）不將就的程式設計邏輯

    所謂不將就的程式設計邏輯，其對立面就是不講究的程式設計邏輯，不講究的程式設計，不僅是一種很壞的程式設計習慣，也體現了低下的生活品質，很多開發人員，因為個人習慣、趕工期、客戶要求不高等多種原因，在程式設計時特別隨意，體現在比如為了實現某個功能，百度出一段程式碼，直接套用，10行的程式碼只理解8行，有兩行看不懂也放到程式裡去使用，很多這樣的小細節，就好比在專案中埋下了無數的定時炸彈，不僅有很大概率形成返工，更是為專案埋下了風險。程式設計人員，應當有擔當有態度，養成不將就的程式設計邏輯，不勉強自己，也不輕視程式。

5）資料備份

    誤刪、誤操作、電腦斷電、檔案遺失等等狀況是每一個開發按人員都可能遇到的問題，如果不希望辛勤的勞作被浪費，不希望偶然的意外影響工作，那做好備份是必不可少的，在較大規模的公司，會有完整的原始碼管理以及資訊保安防護，而無論是在大公司工作，還是身處較小公司或者在實現個人程式碼價值時，都要做好程式碼和文件的資料備份，備份方式的選擇靈活多樣，有使用線上的CVS、SVN、TFS、Git原始碼管理，也可以手工拷貝檔案至雲空間或者本地硬碟，甚至可以在個人電腦上組成RAID磁碟陣列等等，養成周期性、規律性的備份習慣。

6）郵件工作方式

    溝通是進步的源泉，如果說開發小組的熱烈討論是性格和激情的體現，那郵件的工作方式也是另一種穩重和高效。無論是公司層面的工作溝通，還是開發小組的問題交流，郵件的作用包括問題正規化描述、工作留檔留痕、工作流程流轉、責任分工明確等等，習慣於將重大問題、重要事項通過郵件的方式與同事、主管等進行溝通，將會非常有助於團隊協作。

以上這些方法，是我這麼多年來的感受和體會，也給了我很大的幫助，希望也能夠幫助到大家，不能說一定可以“提升修養“，但也是”提升修養”的有效方式。

 

最後還想再說一說堅持的力量

分享一個真實的小故事，公司有兩個開發人員，1個做.NET好多年了，但是很油滑，做事能省就省，抓到可以偷懶的機會就偷懶，讓他學點新知識新方法總是自以為是覺得自己都會；還有1個毫無.NET基礎，一直做低階語言開發，從15年才開始學習.NET和Web前端，但是做事很積極，幾乎每天都自己抽空學習，遇到不懂的都琢磨清楚，遇到不會的場景就上網或者找人尋求幫助，專案結束後還反覆思考有什麼地方可以改進。從15年到現在，短短1年，這兩個人的發展已經是天壤之別，工資差距也越來越大，後者已經能夠獨自操盤中小型軟體外包專案，而前者還在混著日子，以後他們各自的發展也完全可以預見。

我想說的是，本篇裡面分享的一些道理和方法，都是通俗易懂的，就和常聽到的例如101%和99%的365次方的故事、1萬小時的道理等等一樣，但真正去認真思考並實踐的屈指可數，也許，堅持才是程式設計師最大的修養，和各位共勉！