可維護性程式碼，要求我們的程式碼易於理解，如果可以用更少的註釋來完成這一功能，勢必事半功倍！

1、命名

函式命名：避免函式名使用含糊的字眼，使用主動動詞表示函式主動執行。

變數命名：變數的命名一定要是一些有意義的名詞，比如userName，而不是a、b、i之類；程式碼中禁止出現“魔數”（在程式碼中出現但沒有解釋的數字常量或字串）。

PS：變數命名採用英文，千萬不要出現有創意地拼寫錯誤，比如：SetPintleOpening， SetPintalClosing。這樣估計後來維護者全域性搜尋程式碼時要崩潰。

2、函式封裝

函式封裝最大的好處就是避免程式碼重複。

舉個栗子：

下面這樣的程式碼，估計沒有註釋的話，一般人都要抓狂，很難看懂吧。

我們看看引入函式之後的例子，該函式名明確地表達了它要做什麼，這樣一來就不必寫註釋了。而且，如果有需要後面還可以直接呼叫此函式，一舉兩得，減少了重複勞動。

3、引入變數

用變數代替表示式。看下圖的例子，可能第一次接觸程式碼難以理解其真實表達的意圖。

如果引入變數，而不是函式，能否解決這個困擾呢？答案是肯定的，請看下圖：

4、程式碼分組

儘可能將變數定義在靠近使用它的地方，並且儘可能將變數分門別類，這樣更方便後來人對程式碼的維護。

看下面的例子，很顯然，左側的程式碼將foo的所有使用組合放在一起，一眼望去就能知道各種關係。如果可以的話，儘量選擇程式碼分組。

5、統一編碼規則

無規矩不成方圓，同一個專案組，必須統一編碼規範。試想一會駝峰命名法，一會兒又匈牙利命名法，這程式碼看起來得有多彆扭。

作為資深軟體開發工程師，在編碼過程中對程式碼的健壯性、可維護性、可移植性等關鍵特性都應有嚴格的要求。這也是工程師程式設計素養的體現。

提高程式碼可維護性，在程式設計過程中，我們應該注意以下幾點：

第一，命名規範

每種語言在業內都有約定俗成的命名規範，涉及到變數、函式（方法）、類（檔案）、工程、包等，這些的命名，建議都要按照業內規矩來做，切不可胡亂取名，一個好的命名可以讓閱讀這很快的瞭解到這個是幹什麼用的，有助於程式理解。如Java，一般大坨峰小駝峰命名。

第二，良好的註釋

註釋對於閱讀程式的人來說是相當重要的，可以說沒有註釋的程式碼就是耍流氓的程式碼，寫的時候很爽，一段時間後自己都不能理解自己的程式了，何況他人閱讀。建議在關鍵程式碼上都加上說明，如狀態機程式碼，建議要使用文字說明狀態機運轉過程，狀態遷移條件，狀態機設計原理等，以便讓後來者透過文字說明反推程式邏輯，以便於快速理解。

第三，函式長短

這個很好理解，一般情況下程式長度建議都不要超過一百行，如太長，會導致閱讀者對理解程式碼整體邏輯的難度增加，合理劃分函式功能，明確函式的輸入輸出，這樣做既方便做單元測試，也對閱讀者相對會友好些。上千行的函式，簡直就是在勸退閱讀者。

第四，封裝粒度和介面

面向物件的語言，封裝、繼承、多型是基本思想，我們將事物封裝成一個個類，之間透過介面互動，保持每一個物件間的不耦合，想法是很正確的，但是根據我個人經驗，封裝的粒度並不是越細越好，越細代表著互動介面越複雜，介面越多也會帶來程式碼閱讀和維護上的難度，這個建議根據專案的實際情況來合理劃分。

第五，合理的設計模式使用

設計模式是前人經驗的總結，在某種特定應用場景中歸納出的編碼思路，在真正開發過程中我們合理的使用設計模式，就是站在居然的肩膀上開發，可以達到很好的效果，但是，另一方面來說，並不是所有的場景都可以匹配上對應的設計模式，如果強上的話，會讓閱讀者很困惑，不能理解程式思路，甚至程式碼本身就是不穩定的。設計模式在使用前，一定要先理解模式的思想，在結合專案情況決定是否使用。

總結

程式碼的可維護性，首要的就是讓後來閱讀者能夠快速理解程式碼邏輯，其次編碼思路要清晰合理，模組介面劃分得當好。

想要知道如何提高程式碼的可維護性，那就需要了解什麼是程式碼的可維護性，維護程式碼需要進行哪些工作？

什麼是程式碼的可維護性

所謂的維護其實就是修改bug、修改老的程式碼、新增新的程式碼這些工作，所謂的容易維護其實就是指的，在不破壞原有程式碼設計、不引入新的bug的情況，能夠快速的修改和新增程式碼，那“不易維護”就是指，修改或者新增程式碼要冒著極大的引入bug的風險，並且需要的時間也要很長的時間。

如何判斷程式碼的可維護性

評價程式碼的可維護性，其實是一個比較難以量化的操作，往往是需要進行綜合的考量再進行判斷，比如程式碼的可讀性好，也夠簡潔，擴充套件性也不錯，那這樣的程式碼就比較易於維護，相反，程式碼就不容易進行維護。還有就是，如果程式碼分層清晰、模組化好、符合高內聚低耦合的原則，遵從基於介面而非實現程式設計的設計原則等，那就意味著，這樣的程式碼是可維護的，是易於維護的。還有就是程式碼的可維護性也與程式碼量的多少、業務的複雜程度、技術的複雜程度、以及專案的設計文件、團隊人員水平等等這些因素，所以看起來判斷程式碼的可維護性，其實是比較主觀的一件事情。

如何提高程式碼的可維護性

想要提高程式碼的可維護性，寫出高質量的程式碼，那就需要掌握一些可邊落地的程式設計方法論，比如面向物件設計思想、程式碼設計的基本原則、設計模式、編碼規範、重構技巧等。比如面向物件中的繼承、多型、組合能夠幫助我們寫出可複用的程式碼，熟悉編碼規範有助於我們寫出可讀性比較好的程式碼，掌握單一職責、DRY、基於介面而非實現程式設計、裡是替換、kiss、迪米特等設計原則，可以讓程式碼更加懂得易於維護，還要掌握各種設計模式並能夠合適的使用，然後再進行持續的重構，時刻保持程式碼的可維護性。

總結

程式碼的可維護性只是程式碼的一個方面，還有易讀、易擴充套件、靈活簡潔、可複用、可測試等這些方面，如此才是優秀的程式碼。

程式碼可維護性分好幾塊。

第一，命名，千萬別寫拼音縮寫，不超過三天絕對記不住。建議搞有意義的英文，至少自己讀，一眼看上去就知道幹啥的。最差搞拼音全拼。但是我覺得還是英文好。

第二、註釋，程式碼註釋不是什麼都寫，關鍵位置，關鍵過程一定得寫，至少，一年後自己再翻程式碼也能讀懂設計思路。註釋與命名是相互相成的，如果名稱能自我解釋含義，不用寫註釋。

第三、程式碼整潔度，不要過一段時間自己都覺得噁心。

第四、消除重複，只要兩個以上地方用到一定封裝成獨立程式碼。

第五、可配置性，重點考慮，能該配置絕對不改程式。

第六、適當前瞻性，需要業務能力與編碼水平支撐，之所以說這條，鬼知道 客戶或產品什麼時候讓你改程式碼。

第七、適當應用設計原則與設計模式，會構建出很漂亮的程式碼，設計原則相當重要。設計模式適合特定場景，靈活應用不能為搞設計模式而寫設計模式。配合第六條用，直接是法寶。

第八、不斷重構程式碼，程式碼只有不斷重構才會越來越簡潔。

第九、程式碼不要一個函式或者一個方法完成一個功能。寫太長的程式碼出問題機率更多，不方便重用，更不方便除錯。閱讀也很不方便，建議演算法類的，一個方法或一個函式不要超過100行。

第十、多看程式碼設計相關的書籍帖子，有人會教你很多實用方法。

第十一、終極大殺器，多看優秀框架或者平臺原始碼，都是執行緒例子。

第十二、學會取捨，沒有完美的東西，時間足夠就認真做，時間不夠儘量寫好，完成功能才是第一要務。

這些基本上是我保持程式碼可維護性的全部法寶。

想要提高程式碼的可維護性，需要理解程式碼維護的工作內容。一般來說程式碼維護有以下幾類工作：

系統監視和故障排除 使用者在使用應用程式時，需要隨時掌握系統的執行狀況。如發生故障，應能迅速掌握故障的位置，以及可能的原因系統升級 使用者可能出於多種原因需要對系統進行升級。比如，硬體裝置更新換代。現在的作業系統一般一年升級一次到兩次。這也使得系統升級成了剛需，甚至，佔據了系統維護的大半工作量。系統擴充套件 這大概是程式碼維護中最讓人興奮的工作了。一般系統擴充套件都需要為系統增添一些新功能，增加新的程式碼，給開發人員帶來新鮮感。

程式碼維護佔據了系統生命週期的大部分時間，所以，在開發階段多花些時間提高程式碼的可維護性是非常值得的。針對上面所說的幾項維護工作，程式碼的可維護性表現在：

可讀性 很多人認為所謂可讀性就是指程式碼要優雅要規範。但這僅僅是對程式碼的基本要求，可讀性不好的程式碼，影響最多的是開發人員自己。維護人員其實，很少看程式碼。如果系統發生故障，他們更多的是看錯誤資訊和系統日誌。因此，提高錯誤資訊和系統日誌的準確性和可讀性要比程式碼規範優雅重要得多。可適應性 為了減少因執行環境的改變，而出現需要重寫某些模組的情況開發階段，應儘量使用最新的並且比較成熟穩定的執行環境。同時，也應儘可能地減少系統對執行環境的依賴。一些程式設計師喜歡嚐鮮，什麼新用什麼，但是，有些東西未必能成為主流，很可能是曇花一現，到了使用者那裡用不了多久就要被迫升級，這就很尷尬了。可擴張性 很多程式設計師非常重視這個問題，他們很可能還要給系統做很多擴充套件功能的開發，這是關係到他們的切身利益的。因此，他們很重視降低耦合度、提高程式碼複用這些問題。但事實上，很多系統的擴張性不好卻是因為系統的功能設計上缺少擴張性，甚至是在設計階段就沒有預留可擴張的介面或是架構。這樣一來就算是程式碼寫得再漂亮，擴張的時候也難免要重寫程式碼。

上面簡單說了說，我個人對可維護性的理解。實際上，程式設計師的大部分工作都是在維護程式碼，因此，應當給予程式碼的可維護性以足夠的重視。

程式碼的可維護性，是一個優秀程式設計師不懈的追求，讓新人快速的上手專案，並且在維護過程中保證專案的持續穩定，是一個不小的挑戰。從業五年，有自己從0到1的應用實戰，也有維護交接專案的經驗，我對於程式碼的可維護的性有四個方面的認識，即可讀、好改、可測試、重保系統預留回退邏輯。這也是我維護專案時所遵循的變更邏輯和編程式碼時的基本要求。

先說可讀性，這個基本上老生常談了，但是仍不可避免，畢竟如果別人或者自己寫的程式碼都看不到，這維護起來的風險可想而知。提高可讀性的方法網上到處都是，多瞭解多嘗試，總歸有好處的，比如：避免巨複雜的布林表示式；避免超長的方法實現，超過一定的行數劃分新的方法；類設計要遵循單一職責原則，避免超大的類；避免魔幻值；精準的對變數進行命名……很多很多，建議大家使用 sonar 程式碼走查進行程式碼掃描，這個是養成可讀性程式碼的好習慣。當然，有些規則也不必苛刻，如將 true 或者 false 定義成魔數，其定義沒錯，但是改起來的價效比真的高麼？不一定。

再來說說好改，主要有兩方面的體會，其一是功能模組的高度內聚，其二是專案依賴層級有明確的結構。高度內聚還是比較好理解的，比如透過策略模式完成元素的排序，當時的需求時固定排序、加權隨機排序、隨機排序，分別實現策略模式的定義，然後進行排序策略的組裝，後續如果要求實現新入場的元素定製化排序，維護人員只要實現策略定義，不用理我之前的策略實現，就可以完成此功能。而專案依賴層級有明確的結構，專案結構中的web、service、core、dao、utils需要滿足一定的呼叫規則，不能隨便串，要不然讀起來會相當惱火。

再來說說可測試，這個也有兩方面，其一是單元測試，其二是功能入口測試。個人感覺兩者缺一不可，單元測試讓我們審視寫的程式碼是否有邏輯上的問題，是否足夠優雅，相關的邏輯分支是否可以自測透過。而入口功能測試，是別人怎麼用你的介面，你維護變更之後得保障主流程暢通，從而進行自測，一般包含客戶端使用的http入口連結自測或者下游呼叫使用的RPC消費端的程式碼自測。

重保系統預留回退邏輯，這個內容在很多時候是額外的業務邏輯，基本上不會起到作用，但如果真的用到的，基本上是救命的手段，尤其是網際網路公司涉及到商品交易環節或者大流量有影響力的系統功能時，維護需求的上線，往往沒有那麼改，一般都是在保證系統穩定情況下，額外做的營銷手段和使用者體驗最佳化，你優化了使用者體驗，但由於維護不當，導致使用者提不了訂單，運營不找你麻煩才怪。

以上受限於個人的經歷和積累，後續如果有好的想法，再給大家分享。

很多程式設計師在寫程式碼的時候往往都不注意程式碼的可讀性，讓別人在閱讀程式碼時花費更多的時間。其實，只要程式設計師在寫程式碼的時候，注意為程式碼加註釋，並以合理的格式為程式碼加註釋，這樣就方便別人檢視程式碼，也方便自己以後查看了。下面分享十個加註釋的技巧： 　　

1. 逐層註釋　　

為每個程式碼塊添加註釋，並在每一層使用統一的註釋方法和風格。例如：　　

針對每個類：包括摘要資訊、作者資訊、以及最近修改日期等；　　

針對每個方法：包括用途、功能、引數和返回值等。　　

在團隊工作中，採用標準化的註釋尤為重要。當然，使用註釋規範和工具(例如C#裡的XML，Java裡的Javadoc)可以更好的推動註釋工作完成得更好。　　

2. 使用分段註釋　　

如果有多個程式碼塊，而每個程式碼塊完成一個單一任務，則在每個程式碼塊前新增一個註釋來向讀者說明這段程式碼的功能。

很多程式設計師在寫程式碼的時候往往都不注意程式碼的可讀性，讓別人在閱讀程式碼時花費更多的時間。其實，只要程式設計師在寫程式碼的時候，注意為程式碼加註釋，並以合理的格式為程式碼加註釋，這樣就方便別人檢視程式碼，也方便自己以後查看了。下面分享十個加註釋的技巧： 1. 逐層註釋為每個程式碼塊添加註釋，並在每一層使用統一的註釋方法和風格。例如：針對每個類：包括摘要資訊、作者資訊、以及最近修改日期等；針對每個方法：包括用途、功能、引數和返回值等。在團隊工作中，採用標準化的註釋尤為重要。當然，使用註釋規範和工具(例如C#裡的XML，Java裡的Javadoc)可以更好的推動註釋工作完成得更好。2. 使用分段註釋如果有多個程式碼塊，而每個程式碼塊完成一個單一任務，則在每個程式碼塊前新增一個註釋來向讀者說明這段程式碼的功能。

聽過一句話，想分享一下:有些人寫的程式碼，實習生都能看懂;有些人寫的程式碼，工作十年老司機都看不懂。(可能有點誇張)

據說低程式碼平臺比傳統開發快6到10倍，這是真的！

低程式碼軟體開發平臺，顛覆了傳統的軟體開發模式，引爆了一場科技革命。其一方面可以降低企業應用開發人力成本，另一方面可以將原有數月甚至數年的開發時間成倍縮短，從而幫助企業實現降本增效的價值。

像國外的OutSystems、Mendix、Salesforce或者國內的星城軟體等等，都可以開發OA、ERP、CRM、HR、進銷存等各種企業管理應用，並無縫整合打通其他軟體系統，實現各系統間的互聯互通。

很多人在不太瞭解低程式碼平臺的時候，可能對於低程式碼平臺存在著兩個誤解。

一、低程式碼平臺只適合於毫無技術背景的人

事實上低程式碼開發平臺也同樣適合開發人員進行開發。低程式碼開發平臺既可以提高開發人員開發資訊化系統的效率，同時也滿足了無程式碼基礎的業務人員進行資訊化開發。

對於開發人員來說，使用低程式碼開發平臺可以有效的提高開發效率。開發人員透過圖形化介面互動實現應用搭建，視覺化的操作，標準化的配置，大大縮減開發時間和所需人員。當然程式碼平臺並不是萬能的，他並不能實現所有的功能，拿星城軟體定製來說，當在平臺遇到實現不了的配置，可以自定義開發，也就是說可以根據需要自己開發出平臺沒有的功能。

二、低程式碼平臺只是變革傳統開發模式，並不是為了顛覆開發者

低程式碼平臺是為了減輕和降低開發者的“工具屬性”，讓開發者從繁重的程式碼解放出來，參與更具有價值的創作，是未來價值的必然趨勢。同時，發人員不需要多次和業務人員和實際使用人員反覆溝通，面對介面化的需求，對於開發人員，很可能是將之前的程式碼推翻重來。

低程式碼平臺有什麼優勢？

首先，提高效率！

業務人員可以自行搭建業務流程管理系統，降低了溝通成本。同時也避免了“開發人員不懂業務”的尷尬。也不用等待開發人員的實現過程中，出現系統實現了之後與需求不匹配，甚至實現了之後業務邏輯已經發生了變化的尷尬。管理者也可以透過無程式碼平臺，注入管理思維。

其次，降低成本！

優秀的開發者的高薪早已不是秘密，所以開發資源不能浪費在一些通用而且易於實現的需求，無程式碼平臺就是做這個事情，可以以非常低的成本，來代替開發人員的部分工作內容。原來需要十個人的專案，現在可能只要四個人甚至更少的人就能完成。

當然，低程式碼平臺還有很多其他的價值，這裡就只列舉了對企業最重要的兩點來闡述，降本和增效，這幾乎是所有企業永恆的主題。

東軟現如今正在開發相關專案並提供服務。

1.多寫有效的註釋。注意是有效，不然寫再多也沒用？像大家都懂的可以不用寫，關鍵的地方一定要寫。

2.持續重構。一定要不斷地重構，一有空的時候，見縫插針，最關鍵的一點是發現兩個地方程式碼相同的時候馬上重構抽取，這個習慣養好了就事半功倍了。

3.注意格式。有的人寫程式碼歪歪斜斜的，沒有分段或者格式化，層次結構很不清晰，各種跳轉程式碼。其實程式碼塊最好都是按順序下來的，按生命週期等方式，每個類的初始化，設定引數，設定監聽，銷燬等都按一定的順序寫下來，整個邏輯清晰很多。

4.獨立模組。當各種類獨立後還要考慮獨立模組，模組化開發的好處顯而易見。比如我單獨引入百度地圖模組，可以多個專案複用，自己的模組也是一樣。

5.設計模式。如果能力較強，在適當的地方使用設計模式，使程式碼解耦的更好。

為了提高程式碼的可維護性，我根據自己的實際情況總結出以下六點方式，供您進行參考。

註釋您的程式碼

/*

註釋你的程式碼至關重要，因為如果您編寫了一個程式卻未對其進行註釋，那麼缺少註釋將使您浪費時間來重新寫一遍程式碼。畢竟基本上就算是你自己寫的程式碼，幾個月不看那肯定就忘了。所以註釋程式碼又幫助了別人也幫助了你自己。當然如何註釋好程式碼又是一門學問了，這裡就不扯遠了。

*/

不要忘記錯誤檢查

每個中型程式都有很多功能和過程，這意味著每個程式都應進行錯誤檢查。良好的錯誤檢查可以防止程式BOOM了，並使除錯速度更快。當然現在優秀的IDE都自帶查錯功能，你現在基本不必花費很多時間查詢錯誤。

使用更少的程式碼

這是有道理的，你有更少的程式碼，這樣也變相的提高了可維護性（誰會想維護一個用了幾百上千的ifelse語句的神仙程式碼）。它擺脫了未經修改的功能和診斷語句將使您的程式碼看起來更簡潔。如果您有機會使用現有的庫，那就更好了！這樣會一定程度的提高可維護性，畢竟這會精簡你的程式碼。

編寫易於修改的程式碼

這也可以說成是編寫模組化的程式碼，這即方便移植也方便別人來修改你的程式碼，但是當很多人都使用了你編寫的程式碼，但是在使用過程中發現它出問題了！這時候如果只需要改幾個define的引數的話就能修正就能減少很多工作量，不然就需要每個人都重新更改他們的程式碼，增加了很多工作量。

編寫易於測試的程式碼

發現錯誤越早，修復該錯誤的成本就越低。儘管測試每種可能的情況都可能很耗時，但是你可以編寫一段簡短的專用於測試的程式碼，這雖然看上去是多餘的，但真出了問題這可就是防範於未然了。

解決問題，而不是症狀

這也是很多程式設計師偷懶導致的更多的問題

快速修復和實際修復之間的區別是，第一種情況是開發人員決定解決症狀而不是解決問題時發生的。當開發人員細緻的瞭解錯誤原因並設法查明錯誤原因時，才可能進行真正的修復。倉促完成的所有操作只會建立令人困惑的程式碼，供下一個倒黴的人清理。

有些人剛進公司，看到上一個人留下的“遺產”，那絕對是崩潰的。

通常來說，在任何一個專案組中都應該有各自的編碼規範，目的就是為了增加程式碼的可讀性和可維護性，那麼，到底該如何做呢？

1/7 分步閱讀

變數命名要有意義，最好是使用英文命名，實在不行的，使用拼音。除了迴圈中的計數變數，以及特殊場景之外，任何變數都儘量不要使用a、b、c這類完全沒有任何意義的名稱。增強可讀性

2/7

變數除了要有意義之外，還需要統一大小寫，比如第一個單詞首字母小寫，後續單詞首字母大寫的命名風格。風格統一後，看著程式碼都會心情舒暢一些，從而可讀性更好

3/7

新增必要的註釋，雖然，某些變數名可以看出意義，但是，必要的註釋可以更為直觀的讓人看懂程式碼，增強可讀性

4/7

增加程式碼段的註釋。如果是C#語言，可以使用region語法包裹一段邏輯，到時候摺疊起來，看起來整體性就很容易閱讀。其他語言可以使用比較明顯的分隔符號標明段落

5/7

將很長的函式拆分成較小的函式，這樣不僅可以增加程式碼的可讀性，還能增加程式碼的可維護性

6/7

將程式碼劃分層次，比如，訪問資料庫的程式碼單獨放在一個專案中，前臺程式碼單獨放一個專案中，到時候修改的時候就很明確，不至於四處亂找，增加可維護性

7/7

程式碼的層次之間透過介面來呼叫，減少各個層次之間的耦合度，增加可維護性

根據個人多年程式碼經驗：為提高程式碼的可維護性，首先 1.在專案工程搭建時候，包命名規範，功能模組儘量獨立結偶，劃分不同服務2.專案程式碼基本規範外掛和專案組程式碼規範要求文件（本地安裝阿里掃描外掛掃描，程式碼圈複雜度掃描，重複程式碼重複檢測，程式碼安全covert er 掃描）3.程式碼設計模式靈活運用，程式碼常量，列舉類，公共方法類定義，切記不能使用魔鬼數字 4.對於業務複雜的流程，寫好必要註釋，同時最好配合流程圖文件說明

5.專案組定期舉行程式碼走查，程式碼分享會

以上僅個人皮毛經驗，還願與您互相交流探討！

1.程式命名

a1 b1 c1 d1這樣整齊的命名人家一看就懂

2.偽裝欺詐

註釋寫到程式碼裡，程式碼寫到註釋裡，這樣人家會看到清晰的結構

3.多寫註釋

比如這樣

//這要new一個物件

A a= new A（）

這樣人家就能清晰易懂得知道你的程式碼

4.型別強轉，利用語言的優勢

java可以cast 多cast幾遍，將java語言的特性發揮的淋漓精緻

為了提高程式碼的可維護性，我根據自己的實際情況總結出以下六點方式，供您進行參考。

一、註釋您的程式碼

註釋你的程式碼至關重要，因為如果您編寫了一個程式卻未對其進行註釋，那麼缺少註釋將使您浪費時間來重新寫一遍程式碼。畢竟基本上就算是你自己寫的程式碼，幾個月不看那肯定就忘了。所以註釋程式碼又幫助了別人也幫助了你自己。當然如何註釋好程式碼又是一門學問了，這裡就不扯遠了。

二、不要忘記錯誤檢查

每個中型程式都有很多功能和過程，這意味著每個程式都應進行錯誤檢查。良好的錯誤檢查可以防止程式BOOM了，並使除錯速度更快。當然現在優秀的IDE都自帶查錯功能，你現在基本不必花費很多時間查詢錯誤。

三、使用更少的程式碼

這是有道理的，你有更少的程式碼，這樣也變相的提高了可維護性（誰會想維護一個用了幾百上千的ifelse語句的神仙程式碼）。它擺脫了未經修改的功能和診斷語句將使您的程式碼看起來更簡潔。如果您有機會使用現有的庫，那就更好了！這樣會一定程度的提高可維護性，畢竟這會精簡你的程式碼。

四、編寫易於修改的程式碼

這也可以說成是編寫模組化的程式碼，這即方便移植也方便別人來修改你的程式碼，但是當很多人都使用了你編寫的程式碼，但是在使用過程中發現它出問題了！這時候如果只需要改幾個define的引數的話就能修正就能減少很多工作量，不然就需要每個人都重新更改他們的程式碼，增加了很多工作量。

五、編寫易於測試的程式碼

發現錯誤越早，修復該錯誤的成本就越低。儘管測試每種可能的情況都可能很耗時，但是你可以編寫一段簡短的專用於測試的程式碼，這雖然看上去是多餘的，但真出了問題這可就是防範於未然了。

六、解決問題，而不是症狀

這也是很多程式設計師偷懶導致的更多的問題

快速修復和實際修復之間的區別是，第一種情況是開發人員決定解決症狀而不是解決問題時發生的。當開發人員細緻的瞭解錯誤原因並設法查明錯誤原因時，才可能進行真正的修復。倉促完成的所有操作只會建立令人困惑的程式碼，供下一個倒黴的人清理。

有些人剛進公司，看到上一個人留下的“遺產”，那絕對是崩潰的。

可讀性、可維護性和可變更性

做好程式碼規範、提高程式碼質量，能顯著增強程式碼的可讀性、可維護性和可變更性。努力提高程式碼的讀寫可維護性，是做好程式碼規範的必要非充分條件。程式碼規範和架構設計是軟體的靈魂所在，程式碼質量偏低，就像是人失去了三魂七魄中的一魄，就會喪失活力，影響正常執行，增加軟體交付後維護成本，出現推遲完成、超出預算、特性缺失等現象。

任何語言都需要強調編碼風格的一致性。只要是團隊開發，每個人都以相同的方式編寫程式碼就是至關重要的。這樣大家才能方便地互相看懂和維護對方的程式碼。

實際上，每家公司都會有一份（或多份）程式碼規範，因此提高程式碼的讀寫可維護性的關鍵在於是否能落實公司的相關文件，公司的技術總監、專案經理或相關程式碼審查機關是否具有應有的執行力。如果不能落實，那麼即便程式碼規範畫得再美，具體的程式碼也會醜到崩潰。

程式碼規範

如果不想為以後挖坑，做好程式碼規範是程式設計師和團隊負責人、專案經理的必修課。如何保證當前專案開發過程中壓力正常，而不是在後期面對過多的壓力、以至於噩夢纏身？最簡單的辦法就是照看好你的程式碼，也就是落實好公司的程式碼規範工作。每天為此付出一丁點的努力，便可以避免程式碼腐爛，並保證程式碼產品日後不至於變得難以理解（可讀性）和維護（可維護性）。

程式碼的可讀性

程式碼的可讀性是指程式碼讓人容易閱讀、跟蹤和理解的程度。提高程式碼的可讀性可以為程式碼閱讀者節約時間（避免閱讀時浪費過多無謂的時間）和精力（Debug、擴充套件功能或是效能最佳化的前提條件是你要讀懂這段程式碼）。以下是摘選的可供參考的策略：

編碼風格一致程式碼清晰表達意圖恰到好處的註釋評估取捨（不要編寫大段的程式碼）避免做沒有太大價值的最佳化工作；區分任務的輕重緩急：綜合考慮一下效能、便利性、生產力、成本和上市時間……簡單就是美，避免簡單的功能寫出複雜的程式碼；程式碼的可維護性

軟體可維護性是指理解、改正、改動、改進軟體的難易程度。通常影響軟體可維護性的因素有可理解性、可測試性和可修改性。筆者這裡將其分為兩大類：編寫時可維護性和執行時可維護性。

編寫時可維護性

編寫時可維護性是指在程式或系統上線後爆出 BUG，開發團隊能夠及時撲滅這個 BUG 且不會爆出其他 BUG。保持方法的原子性，提高程式碼內聚，能使某處修改的影響降到最低，這樣某處方法出現 BUG，也不太會影響到其他模組的正常運作。編寫時可維護性還包括了程式碼的可測試性。

執行時可維護性

執行時的可維護性是指在系統執行過程中（或無需再次編碼釋出、只需系統重啟一次）修改系統的某項配置並使其生效，且不影響現在正在進行的業務和使用者的操作。這要求軟體工程師不能把程式碼寫死。例如配置檔案、資料庫連線字串、資原始檔、日誌等。

以下是摘選的可供參考的策略：

不要把程式碼寫死；

預測可能發生的變化

透過提高程式碼的複用性提高程式碼的可維護性

程式碼的可寫性

程式碼的可寫性包括程式碼的可變更性，程式碼的可變更性是軟體理論的核心。

程式碼的可寫性是建立在程式碼的可維護性上的，而程式碼的可寫性與可維護性又都建立在程式碼的可讀性上。如果程式碼難以閱讀，那麼 BUG 的修正將變得難以入手，新功能的新增就更是無從入手了。

猛然看到這個問題，突然覺得不是很好回答，為什麼會有這樣的疑問呢？因為國內的程式碼還到不了可維護性的層次上，都是一錘子買賣。往往不需要維護產品就已經黃了。如果確實想要提高個人程式碼的維護性，不用問度娘狂看一堆的文章，隨便找個國外的流行專案的原始碼看一下照著做就可以了。比如，你如果是學Java的，那就看SpringBoot的原始碼，相信你會有很大的收穫的。千萬不要抱著一堆的規範一條一條地看，那樣沒有任何幫助，只會增加你的反感。

提高程式碼的可維護性，主要從程式設計規範、異常日誌、單元測試、安全規約、SQL規範、工程結構等方面來講，業界已經有成熟的圖書了，特別是阿里巴巴出品的《Java開發手冊》，更是經典，其他語言的也可以參考下，原理都一樣。

至此，筆者不再多述，因本書已有詳細的解答了。