論一個程序員的自我修養

本篇文章轉載-轉瞬之夏

 

　　在《喜劇之王》中，周星馳扮演的尹天仇，一直夢想成爲一名演員，而他無論是在扮演跑龍套，或者在街坊中開設演員訓練班，亦或成爲主角時，他對待演員的態度，始終是認真，熱愛而又投入的。而那一本他隨身攜帶的書--《演員的自我修養》，儘管不知道里面具體寫的是什麼，但我猜，他對待演員的態度和行爲，就是書中內容顯示的。

　　因而，不由問了問本身，做爲一名程序員，一個「程序員的自我修養」是什麼？

　　儘管咱們不必定要像尹天仇那麼的認真對待本身的事業，但，一些基本的修養，做爲一名新時代的碼農，總應該是要具有的吧。不過真要說修養，方面仍是挺多的，技術自我提示自沒必要說。但我並不打算從這個你們都以爲理所固然的技術方面入手，而是談談，可讀性代碼，這個容易被你們忽視的基本素養。

一、聽從所在團隊的代碼規範。

　　一個高效、成熟的團隊，一定有一個屬於本身的代碼規範，這個規範是團隊的寶貴的財富，它是整個團隊從各類坑中爬起來後積累的經驗教訓。什麼是規範，它是人們從無數經驗中總結出來的規則，標準。而代碼規範，指導團隊成員如何以最短的時間寫成最高效，可讀性強的代碼。試想，若是成員不聽從規範，你用駝峯命名，他用下劃線，這對程序的可讀，將形成多大的影響。我想，應該沒有一我的願意去閱讀一段，各類變量命名形式都能見獲得，private, public 方法隨意排序，甚至常量類都散落在各個角落的代碼吧。

　　代碼，一個做用是讓機器閱讀，另外一個重要的做用是讓人閱讀！！！

 

二、聽從行業內通用的規範

　　在團隊的代碼規範未涉及到的，那請按照行業內的規範來編寫代碼。規範的一個好處是，能夠明顯減小學習和交流成本。在java中，當咱們看到全大寫的變量名時，咱們就知道這是常量，而不須要去看註釋，不須要去看代碼邏輯。爲何這麼迅速，由於行業裏你們都習慣把常量用大寫命名。但假如你用其餘命名方式命名常量，好比team_nums命名常量，不只不能讓人迅速知道這是個常量，並且可能讓人誤會這是個變量，增長了團隊成員學習和溝通成本，甚至可能誤導他們。就見過一位仁兄，明明用的是工廠模式，恰恰按模版模式的命名方式來命名，問他，他說他知道這是工廠模式，但他以爲，更應該叫模版模式。。。個人天，，你這麼任性，之後還能作朋友麼?

　　舉個例子，咱們須要根據支付類型，來生產多個支付產品，因而，咱們寫了個工廠類，命名爲FactoryPay。當其餘人看到一個類叫FactoryPay，他們會猜想，這應該是個工廠類，負責生產各類支付產品的工廠，而後按照這個猜想去閱讀代碼，就能比較快速的理解整個類的做用。可是，假如我取名PowerPay，別人還不知道是啥，看了半天，才明白，這是個工廠的做用。這就明顯增長了他人的學習成本和維護代碼的成本。

　　無論你是新手仍是老鳥，務必瞭解施行行業規範，切勿爲了標新立異而違反規範。這麼低端的裝逼，就不必採用了，要裝也寫個高端的框架來提高逼格唄。

 

三、變量、方法命名要能表達變量做用

　　在程序員這個圈子好久了，就發現，程序員這貨，都喜歡這套，「這個接口乾嗎用的，有文檔麼」，「本身看代碼去」。不少時候都是一臉黑。

　　儘管程序員閱讀別人代碼技術都是一流，無論你是有沒有註釋，無論你是怎麼循環嵌套，也無論你是怎麼命名，他們都能耐心的，把代碼分析個因此然來。但，對於程序員這個視時間寶貴如生命，分分鐘都能創造幾百萬價值的羣體來講，您行行好，給咱們省點時間吧，把變量是幹啥用的，說清楚唄，沒準節省的這幾分鐘，多賺個幾萬，還能請你們出去嗨呢。

　　往往看到部門的某大神，用一個神通常的變量名「flag」，我就有吐血的衝動，他還這個flag一直雪藏，不用，只是傳遞到第n個方法才使用，頓時心力交瘁，個人天，這個flag都是是幹嗎用的啊，後來才明白，是isPay的意思，用來標識用戶是否支付成功了。當時一口老血吐屏幕上，內心狂吐槽，老兄，你命名個isPay會死麼，個人腦細胞這麼不值錢麼。到後來看到，去魔法數字，用int NUM_7 = 7,而不是MAX_MEMBERS來表示最大成員、用x y z來命名變量名，各類只有做者，或者做者後來都忘了的獨特命名方式，都見怪不怪了。更有甚者，一個變量命名爲passed，做用竟然是「未經過」的意思，當時就石化了，做者還真是用心良苦，這都要考我細心不細心。

　　一個好的變量名，能幫助閱讀者瞭解變量的做用，也輔助了對整段代碼的理解。

 

四、不要show英語，鄉下的孩子傷不起唉

　　LZ所在的團隊，英語一直都是團隊的硬傷，但老是能看到，某位仁兄，加上大把大把的英文註釋，有些變量名也取些高大上的複雜的英語單詞。敢問，你這麼高的逼格，之後咱們怎麼和你玩啊。(那位仁兄其實就是LZ，年輕時唉，罪過罪過)

　　代碼是用來溝通的，傳遞做者意圖的，都看不懂，怎麼溝通交流。建議英語好的童鞋，英語能力能夠放到閱讀英文書籍中展現，在代碼中，若是團隊英語能力很弱，避免使用英文，變量命名也儘可能按照團隊英語水平來命名

 

五、添加必要的註釋

　　正如上面LZ說的，常常遭遇「你仔細看看代碼，就知道幹嗎用的」這樣的神回覆。儘管閱讀代碼是每一個程序員的強項，但必要的註釋，好比邏輯比較複雜的地方，添加必要的註釋，對提高團隊成員閱讀熟悉代碼的效率是有很大幫助的。試想，一個類，幾百行，沒有一行註釋，對於閱讀者來講，閱讀它將是一個多麼恐怖的事。

　

六、註釋保持簡潔，避免沒有必要的註釋

　　即看過一行註釋都沒有的代碼，也看過註釋比代碼還要多的程序。一個是讓人生不如死，一個是讓人痛不欲生。(唉，有時不只感嘆，在程序員界混，真的是難)。

LZ就常常看過，一大段註釋，囉嗦了半天，要不就是沒表達清楚重點，要不就是隻爲說明它是個循環的做用！！！譬如i++這樣的代碼，有必要加個「每一個計數增長1」這樣的註釋麼，這徹底是把讀者定位爲非程序員啊，或者就是嚴重鄙視讀者的編程水平。

　　註釋是幫助閱讀的人更好的理解程序的邏輯，只是輔助，若是不重視經過命名等方式來傳遞代碼的做用，而是依賴於註釋，這就是本末倒置了。並且，冗長囉嗦的註釋，這究竟是幫助人理解，仍是阻礙人理解啊，是讀程序仍是讀小說啊。　

 

七、擁有本身的編碼規範

　　規範是爲了讓團隊更快的理解、熟悉代碼的，同理，擁有本身的一套規範，就能幫助其餘人更快的理解咱們所寫的功能，減小學習和溝通成本。　

　

八、代碼清晰簡潔的表達出做者的意思

　　在咱們每次寫完一段代碼時，必定要問問本身，代碼是否表達清楚了個人意思，是否須要添加些註釋，名字取得是否恰當了，別人在閱讀時是否吃力。。往往看到別人一團糟的費解的代碼，就時刻提醒本身，必定要把代碼寫好咯，我也確實是這麼作的，一遍又一編的檢查，看變量名、方法名是否代表了它的用途，是否有些沒必要要的、只是爲了提高逼格的代碼，別人是否能在短期內看懂。全部的這些，只是爲了寫出一段更優美的代碼。

 

九、堅持並捍衛上面的準則

　　常常能聽到，有些公司是代碼行數來定義績效的，但做爲一個有操守，並秉承基本自我修養的程序員，咱們毫不能爲了各類誘惑或者脅迫，甚至是本身的惰性、個性，而放棄寫出簡潔清晰，可讀的代碼。

　　

　　以上的幾點，並非嚴格的意見或者建議，只是提醒廣大程序員同胞們，在癡心與高端的技術時，千萬不要忘了，代碼不只機器要閱讀，人也須要閱讀。就算你寫出再複雜的代碼，但它讓人徹底沒法閱讀，這有什麼用呢。這就如同，你很牛逼很牛逼，但別人聽不懂你說的話，還不是沒用。若是你真的寫出了可讀性強的代碼，但你也不該該鳴鳴得意，我以爲，寫出一段優美，健壯，可讀性高的代碼，是一個程序員最基本的自我修養。若是這個追求都沒有，那和鹹魚有啥區別呢。雖然常被外人看來邋里邋遢，不善交流，但咱們的的代碼優美，每段代碼都清晰簡潔的表達了心中的想法，這不也很好麼。代碼做爲程序員間交流溝通的媒介，必定要保持它的高效溝通的屬性，切不要爲了本身的個性，而犧牲它的可讀性。在此，建議你們業餘時間閱讀些好比《clean code》、《how to be a better programmer》等相關書籍

每篇技術博客，應該像代碼同樣，條理清晰，易於閱讀，同時又應該簡潔，觀點鮮明，這纔是一篇合格的技術博客。（一切爲了知識的傳播）