如何提高寫代碼的水平？

01-03

去年做了一個c++工程，開始功能完成的好好的，等到後來擴展功能外加可視化的時候代碼就臃腫不堪。到後期為了趕進度不停地複製粘貼。改到後面，自己都不認識了。最近也看了一些別人的代碼，不管體量多大，都能非常清晰地弄明白脈絡。本人非科班出身，不知道下手之前到底應該做什麼樣的工作，才能節省時間？是否有相關的書籍用來學習。謝謝

你需要學習一下MVVM這種「設計模式」。不過除非你有豐富的編程經驗，否則看懂了也是執行不了的。

先推薦幾本書《重構》《代碼大全》《headfirst設計模式》

當然，光看書是不夠的，動手實踐必須的。然而，盲目動手也不行，還得看是做什麼類型項目

看書真的很重要，十幾年工作經驗的碼農寫出來的代碼照樣慘不忍睹，因為他們從來不看書

想當年我寫代碼，只會開發功能，從來不會改功能，如果有修改功能的需求，我都是把原來看功能刪掉，重新實現一遍，就算是自己寫的也一樣，因為代碼實在太爛，爛到喪心病狂。我意識到問題所在，開始尋找解決的方法，從論壇提問到網站搜索再到諮詢高人，剛開始得到的答案是學習「設計模式」。

之後我買了一堆設計模式的書，開始學習編寫代碼的藝術。設計模式的書主要看了《大話設計模式》《headfirst設計模式》和GOF寫的正宗《設計模式》。看了三本書，對設計模式還只學了個似懂非懂，而且總想往代碼中套學到的設計模式。然而，我那時間做的是網站開發。網站開發你們懂的，用的最多的就是資料庫的增刪查改，根本沒有什麼複雜的業務邏輯，資料庫用的是sql server，功能強大的一逼，有業務邏輯也用存儲過程寫了，程序的唯一作用是就獲取數據和顯示數據了，拿MVC來套就是只有視圖層和控制器層了，模型層的東西全在存儲過程裡面，所以空學了一身設計模式就是沒有用武之地，憋的慌。

後來發現前端特效的邏輯遠比較後端程序來的複雜，一些複雜的特效如編輯器、日曆控制項、相冊、小遊戲都需要組織複雜的代碼，這都是使用設計模式絕佳的場景。因此，我便著手開發這些前端特效，並在編碼的過程中使用看書學到的設計模式。然而，因為缺乏經驗，很難把控在合適的場景使用合適的設計模式。於是，代碼到處都是各種不合理的設計模式的使用，就算是用不到設計模式的場景，我也非硬套上去一個不可。這麼做的結果就是，代碼根本不能看，理解起來超費力，代碼到處是一個個類，還有javascript模似的介面、抽像類、抽相方法這些設計模式中常用的特性，而我居然還樂在其中。事實上，這些濫用設計模式的代碼和最初的那些未經任何設計技巧加工的代碼在難維護性上是半斤八兩，除了多出來很多沒有必要的中間類，還有許多類並沒有達到「高內聚」的標準，因為我無法合理的把握代碼的放置位置，換句話說就是某一段代碼倒底應該放置在哪一個類中，我搞不清楚。代碼中到處都充斥著壞味道。

我意識到我不應該一味的使用設計模式，這東西了像裝B時用處大點，實際的作用並沒有傳說中的強大。我需要簡化代碼，讓代碼的邏輯更順暢。我開始閱讀《重構》這本書，講心理話，這本書是到至今為止我讀過對我幫助最大的一本編程類書籍。從書我並沒有學到重構的手法，我覺得我沒有必要按照重構的手法一步一步的調整代碼，我只需要明白，代碼問題出在哪裡，修改後的結果是長什麼樣的就可以了，我今後寫代碼只需要直接達到重構的結果就可以了，如果無法一步到位，再利用重構手法進行調整。閱讀完《重構》後，我用之前一個問題項目進行練手，將學習到的重構技術一一應用，調整代碼結構。至此，我才找到「編寫好代碼」的入門方法。此後，我不斷練習重構中學到的技巧，練到滾瓜爛熟為止。學習重構技術的作用是巨大的，我的工作效率成倍的提升，在同事們眼中完全是不可思議，我編寫的代碼非常流暢，極易維護，修改成本極小。

之後我閱讀了《代碼大全》，這本書帶給我的作用可能並沒有《重構》巨大，但也不可小噓，它使我對於以前比較迷糊的一些軟體工程概念有了更清晰的理解，如「高內聚」「低偶合」「信息隱藏」「繼承與組合」等等。這本書覆蓋的知識範圍非常的廣，我正真理解的也就是其中的幾個章節，大部分只是用眼睛掃一下，到現在已經忘的差不多了。

總結一下

如果想在寫代碼的路上走的更遠，這三本書必看，尤其是《重構》
看書時作好筆記，不時回顧溫習，書中講述的內容太多，不可能全都記住，但需要盡量往多了記，往久了記
找項目實踐，項目結構越複雜越好，我覺得，複雜的前端效果最容易鍛煉編寫代碼的能力
設計模式好像並沒有那麼重要，但也不可忽視，學習設計模式並不一定為了使用設計模式，而是為了理解實現設計模式背後的原理
這是一個艱難的過程，至少比學習任何一門具體的語言要難

TJ 是怎麼學習編程的？ https://www.quora.com/How-did-TJ-Holowaychuk-learn-to-program

TJ 回答道：哈哈不錯，居然發現我最開始是一名設計師！

我當年做設計師的時候玩了玩 Flash，因此知道了腳本這回事。

後來我在維多利亞的一家公司工作，我覺得如果我想做點東西，我應該了解一個產品各方面的知識，於是我決定學習編程。

至於你問我是「怎麼學習編程」的，真的沒有什麼特別的技巧，我不讀編程方面的書，也沒有去學校學習，我只是看別人的代碼，搞清楚程序是怎麼運行起來的。

------

大神就是大神，學個編程簡直易如反掌。

我們來領會一下大神的主體思想：

你要提高的不是編程水平！而是了解「程序是怎麼運行起來的」！！！

比如前端需要了解：

瀏覽器是怎麼下載頁面的？

瀏覽器是怎麼展示頁面的？

頁面是怎麼有樣式的？

頁面是怎麼與用戶交互的？

頁面是怎麼更新的？

用戶是怎麼提交內容的？

伺服器是怎麼運行起來的？

伺服器做些什麼？

你不了解這些，寫再多代碼也沒用！！！

《重構》《代碼大全》《設計模式》應該能幫到你的忙，另外重構過程中，最好先把測試用例寫好，然後一點一點改，出問題容易找

-- 不知道下手之前到底應該做什麼樣的工作，才能節省時間?

這個要求看似簡單, 實際上卻要求具備相當多的經驗和重構知識. 因為只有具備了這些經驗和知識, 才能對代碼的布局結構, 介面和數據的設計作出比較正確的預測. 我覺得對於一般人來說, 還是不斷的在實踐中迭代重構比較現實.

代碼之所以一團糟, 相當大部分的原因是以下三條, 我覺得對於剛開始接觸這方面工作的人來說, 解決這三條, 基本能清理好大一部分:

1. 代碼之間的邏輯和聯繫過於緊密, 牽一髮動全身.

2. 代碼塊沒有封裝, 內部邏輯裸露. 在該功能的代碼外部可隨意訪問內部, 甚至必須訪問內部才能運轉起來. 舉個例子, 這樣的代碼就像一個電視機需要拆開後板, 在電路板上操作, 才能切換頻道.

3. 代碼重複, 到處複製粘貼, 增大了代碼長度, 修改難度, 以及不一致性.

說幾點簡單實用的給剛開始打算重構代碼的人:

0. 良好的命名, 無論是變數還是方法還是對象. 說重構==改名, 也算大部分正確.

1. 不要重複. 一旦複製粘貼, 腦袋中的警鈴就要響起.

2. 做好封裝, 無論是使用函數還是對象. 不要把內部裸露出來, 我們從來沒看到過需要拆開電路板來操作的電視機. 功能塊只要提供介面就好, 就像你只要提供個遙控器給用戶操作電視即可. 做好這條, 那麼功能塊之間的最起碼的隔離也就有了.

3. 功能塊代碼不要過長. 一旦過長, 則要重新審視, 進行拆分.

4. 降低局部邏輯複雜性, 比如發現if else嵌套就要考慮精簡和抽離邏輯, 比如提早返回等等具體做法.

5. 避免全局變數.

以上幾條我覺得操作難度很低, 且不針對於具體編程方法(函數, 面對對象等), 投入產出比還是較高的. 如果需要進一步的提煉代碼, 可以看以下書籍:

重構 (豆瓣)

編寫可讀代碼的藝術 (豆瓣)

代碼整潔之道 (豆瓣)

代碼大全 (豆瓣)

此外, 閱讀別人編寫良好的代碼, 可能也是你靈感的源泉.

不二法門：不停重構你的代碼。

一直看到需要看《頸椎病的康復指南》就不能再高了

少上知乎，多敲代碼(送給自己！)

菜鳥一枚談一下自己的看法

需要對自己從事的事物有一個大方向理解

不要生搬硬套各種設計模式其實很多設計模式我們一直在用只是不知道名字多看一些別人的項目考慮一下是否有更好的實現相比於模式重要的是思想多關注一些牛人的博客

寫的多了看的多了思考的多了一切模糊的事物都會變得清晰

=====補充

代碼是對於事物的一種抽象描述在寫之前嘗試用自然的對話語言去描述一下也許會好些

高質量的代碼總是遵從一些基本概念而建造起來的。

1. 是否有高質量的代碼規範，編碼過程是否遵從了這些規範。

這些統一的規範就像是一種語言，一種人和代碼間的交流的rule和共識，有了語言規則和共識，溝通才順暢有效率，我們才知道這些蝌蚪所言何意。

2. 上述規則1更多關注細節，對代碼可讀性上，會有很大的益處，但是這是不夠的，好的代碼還需要在易修改，易擴展，以及性能等上下功夫，這些就考驗人的專業領域知識和軟體建模的水平上了。

編碼規範上，建議找一些業界做的好的參考，然後依照項目需要斟酌和刪減。

領域知識上，應該題主自有思路。

軟體建模上，題主可以參照各種設計模式和建構模型，選擇有參考意義的模型，讀相關介紹入門書籍，找些優秀實現讀和修改，最後在自己代碼中用起來

再干幾年。

SICP

可能有人覺得這書太老太抽象，但這本書其實道出了編程的本質：Abstraction。

另外lisp其實是一個很有趣的語言：如果你寫的不夠優美簡潔，它就不能運行。