如何讓程序代碼自我改善

A. 程序員如何提高自己的編程技巧

可讀性：函數命名隨意，實現邏輯混亂，代碼格式不統一。。。
可靠性：程序運行很難穩定，bug百出。。。
維護性：代碼邏輯沒有層次，混成一團，很難維護改進
移植性、重用性：許多人寫的代碼，只能各自使用，很少有能共享的功能性代碼
高效性：很少從演算法、資源佔用、執行效率等角度去考慮，經常導致伺服器負載過重
那麼我們改進時，就可以從以上幾點出發。
總結了一下自己以前的經驗，主要有以下幾點：
提高自己的程序語言基礎。對於許多新手程序員來說，只是簡單的學會了該語言，知道一些簡單的用法。但是實際編程的時候，許多寫法、用法不標准。舉一個很常見的例子：許多人剛剛學c++,java等面向對象編程的語言時，雖然知道了類、知道了類一般都有「多態」的特性，但是他們還是經常會用「類型判斷」去判斷某個對象是屬於哪個類的實例、然後強制轉換、再調用方法。卻完全忽略可以用多態來避免這種醜陋的實現！
熟悉語言規范。如果不知道自己所學的語言還有規范，那麼建議你現在去查找。說個簡單的規范，Java的類名要取得有意義、首字母要大寫。再比如：一個函數只實現一個功能。再比如一個復雜的：連續的if else條件判斷最好不要超過10個。
培養自己嚴謹的邏輯思維能力。我們寫程序，至少都會在腦海里走一遍程序的流程。如果流程走通最後卻出現bug，那麼就是流程的某個細節我們沒有考慮到！有的時候，我們總是自認為自己已經考慮的非常全面了，其實不然。同樣舉一個例子：對一個集合，寫個for循環按照一定的條件刪除裡面的元素。其實這裡面隱藏了一個「集合在動態變化」的陷阱。比如說，將第一個元素刪除了，如果集合的數據結構是將第二個元素移動到第一個元素上，那麼，第二個元素就遍歷不到了。所以，有時候，我們看似很簡單，覺得邏輯非常正確的代碼，可能就潛伏著陷阱。
熟悉所用語言的API。學一門語言，其實不只是學語法，學語義。更重要的是學基本的API類庫。因為你實際編程的時候，自己所寫的代碼其實很少，大部分都是用的別人的API，將許多API的功能穿起來，才是自己實現的功能。用好的API，能增加代碼質量、提高代碼可讀性、減少代碼bug、減少工作量。就比如說堆棧這個數據結構，程序員基本都知道，但是大部分人可能都不能實現一個正確的堆棧API。
熟悉了解一些數據結構、演算法。平常寫程序時，或多或少都要接觸一些常用的數據結構，比如說鏈表、map等，了解它們的原理對於那些沒學過數據結構的人來說很重要。很多時候，一個簡單的功能被實現的超級復雜的原因就是沒有使用簡單清晰的數據結構。
掌握一些編程思想、設計模式，這會讓你的代碼更加具有結構性、條理更加清晰！比如說，面向介面的編程思想，能讓你的代碼易於修改、易於擴展。如果更進一步，站在架構的角度去考慮。
多看高手代碼，讀一些優秀的開源代碼，看一些經典的書籍。比如說《Effective C++》、《Effective Java》、lucene的源碼。這些會讓你提升巨大，只有了解到高手眼中的世界，才能有成為高手的可能！
代碼重構。多回顧之前寫的代碼，進行一個系統性的整理。因為我們起初開發，不是面面都能想到，許多新東西是不可避免的，這就意味著可能會導致一些邏輯混亂。在開發完成後，多回顧回顧，尋找能改進之處，這也是一種進步。
即時缺少高屋建瓴的能力，我們也應該多從全局的角度去考慮整個工程的代碼的層次、模塊、架構等問題點。可以嘗試著進行功能點拆分、介面交互設計等工作。
為自己的代碼添加測試用例。可能因為懶惰，許多程序員基本都不會為自己的代碼添加測試用例，這其實是一個不好的習慣。即時是有測試人員的團隊，添加測試用例對你的好處也是顯而易見的。
至於從團隊的角度，可以考慮建立以下幾點：完整的規范、執行流程、review機制和輔助工具。由於本篇文章主要針對的是個人，就不展開。工具方面，可以考慮開源的ReviewBoard。
個人的代碼質量提上來，團隊的水平才能提上來，公司的效率才能提升。其實最主要的是，個人的層次、境界才能提升！

B. 作為一名普通的程序員，需要怎麼給自己找一條後路呢

作為一名程序員，在未來可能會面臨技術淘汰、公司倒閉、經濟不景氣等風險。因此，找到一條後路是非常必要的。

以下是一些可以幫助程序員找到後路的建議：

1.不斷學習新技能：隨著技術的不斷發展，新技能的學習變得非常重要。程序員應該不斷關注行業的動態，並且學習新的編程語言、開發工具和技術。

2.建立廣泛的人脈：建立廣泛的人脈可以幫助程序員在職場上更好地生存。這些人脈可以包括同事、老闆、行業專家和其他程序員。

3.做好個人品牌建設：通過博客、社交媒體和GitHub等平台，程孝祥序員可以建立自己的個人品牌，提高自己的知名度和可見祥凱度。這可以幫助程序員在找工作或者自主創業時更有優勢。

4.考慮轉行：如果程序員發現自己的技能在行業中逐漸被淘汰，或者自己的工作面臨很大風巧宴搏險，那麼可以考慮轉行到其他領域。這需要程序員具備開放的心態和勇氣，但也可能會開啟一條新的、更有前途的職業道路。

綜上所述，作為一名程序員，需要不斷學習新技能、建立廣泛的人脈，做好個人品牌建設，不行就要提前考慮轉行。

C. Java程序員如何自我提升

1.專注於一個工作，對於程序員來講，專注於某一個開發工作是非常重要的，如果同時處理幾個任務，你只會為此耗費精力，這樣只會導致工作效率降低，所以作為java開發應該專心做好一個工作，再去做下一個。
2.建立條理工作系統，對於程序員來講，工作如果沒有條理，那將是多麼可怕的一件事，會直接影響工作效率。一名優秀的程序員一旦投入工作當中，他們會變得非常專注和條理。
3.不要使用過多工具，在開發工作過程當中，編程工具肯定會用到，但如果使用過多，只會起到適得其反的效果。
4.要迅速做出判斷，作為java程序員要果斷做出抉擇，不然真的會影響到工作效率。
5.學會發現和解決問題，可以這樣說，問題是好的學習機會，只有在工作當中不斷發現、分析和解決問題，才可以成為公司真正的骨幹，同時也更快成長。從入門到高手這一過程，這一階段對個人成長是很有幫助的。
6.經常思考總結，古人雲：」學而不思則罔「，只學習不思考會導致難以把握事情的本質，這樣的學習過程可以更好地版主自己清楚地了解工作進度，減少壓力和提高工作表現。

D. java程序員如何提高自己技術能力呢

一個java程序員不思進取，那麼等待他的就只有淘汰。時代在進步，java更是在不斷地發展，一個java程序員必須不斷的提高自己各個方面的能力，才能更得上時代的進步，java的發展，保持自己的核心競爭力。那麼沙河計算機學校介紹java程序員如何提高自慧消段己技術能力呢?

1.規范java代碼編寫

一個java程序員是離不開代碼的，代碼就是他最好的夥伴。代碼前譽是有自己編寫規范的，作為java程序員你不斷要遵守，並且還得有意識的規范自己編寫代碼，一旦養成良好的習慣，這會讓你受益良多。

比如，現在好多公司會要求你在編寫代碼時嚴格按照規范來，對java代碼內注釋格式、Java代碼的變數命名等等都有嚴格的規定，這樣不僅利於程序員之間的交流協助，還方便修改跟移植java代碼。

2.練習編寫文檔

作為一個java程序員，你總是希望每次上級安排給你的任務，都配有相應的文檔，這樣你會省去很多的功夫。其實，這種想法在一定程橋氏度上限制著你的發展。

你要知道，一個高級的java程序員每天至少會花上30%的時間來寫技術文檔。這也是你不管從事多久的java行業，卻依然還是個初級java程序員的重大因素，所以，多多練習編寫文檔吧，這對你未來的發展會有莫大的好處。

3.測試常踐行

一個java程序員如果覺得把自己編寫的程序交上去，自己完全不需要測試，然後會有專職的程序測試員會進行相應的測試，然後測出問題自己再去解決。那麼這種思想也是存在誤差的。

你要知道防微杜漸，而不是在問題出來以後你再解決，你應該在你編寫的每段代碼，每個子模塊完成後進行認真的測試，有問題及時解決，這會為後面省下好多的功夫，大大提升效益，也不會到時候有特別重大的失誤。

E. 如何提升程序員的代碼編寫能力

一、先列三個常見的開發場景：

1、拿到一個模塊詳細設計文檔，大部分程序員的通常做法就是開始搭建界面代碼，然後從第一個按鈕點擊事件或頁面Load事件開始寫第一行業務代碼。寫的差不多了，就運行一下，發現哪裡不是自己想的那樣，就改改，直到改到是自己預想的那樣。

2、做完了一個功能模塊或幾塊相關聯的功能模塊，輸入111asd，發現新建正常、保存正常，就提交給測試人員。測試員用測試用數據、測試場景用例來測試，發現有問題，就登記bug。對於嚴重的影響下一步測試的BUG，測試員就用內部IM通知這個開發人員。對於不影響繼續往下測試的BUG，測試員就登記下來，等程序員有空時處理。

3、程序員一般工作不希望大家打擾，所以開發起來就是開發。等手頭開發告一段落，就看看BUG庫。發現有與自己有關的BUG，就從第一個BUG開始看起。就開始通過IM和測試員掰扯起來（這不是個BUG啊、業務邏輯不是你想的那樣啊、我這里不能重現啊、你給的信息描述不清晰啊），於是IM幾來幾往，甚至跑過去當面交流一番，甚至會拉扯上產品經理一起討論，更甚者需要項目經理或產品經理發起一個會議來集體討論一下

這是不是很熟悉呢？這就是大部分程序員開發的三個步驟：寫代碼、自測、修復BUG。

二、說好的代碼設計、代碼測試呢？

代碼設計？那不是都有開發平台么，已經固化了啊。那不是維護舊功能做完善修改呢么，又不是寫新代碼，只能在現有代碼基礎上修改啊，你又不能大幅重構。

代碼測試？你丫需求討論期、產品設計期、設計評審期那麼長，都把研發項目時間佔光了，就留下2個星期讓我們寫代碼，我們哪裡有時間搞那麼深的測試。還想讓我們搞結對編程？還想讓我們搞測試驅動開發？

而且你看測試，什麼功能測試、集成測試、性能測試、安全測試、安裝部署測試、升級測試、遷移測試、UAT測試，一大堆測試，測試也需要很多時間。

一個項目，需求討論、產品范圍規劃與評審、產品設計與設計評審佔了一個半月，開發+自測就一個月，測試佔了一個半月，這就4個月了啊。

三、為啥程序員寫代碼總是寫寫測測？

剛才大家也都看到了，大部分程序員都是從界面代碼開始寫起，而且寫一寫，就運行一下看看。為什麼會是這種開發方式？

那是因為大部分程序員缺乏在腦子中的整體建模能力。只能做出來一點，真實的感覺一下，然後再往下。

有些是產品經理的上游就有問題，沒給出業務流程圖（因為產品經理也沒做過業務），也沒畫清楚產品功能操作流程圖。

為啥沒給出業務流程圖？因為產品經理不熟悉業務，另外，產品經理也沒有流程建模能力啊。為啥沒畫清楚產品功能操作流程圖啊？因為不會清晰表達流程啊。

很多產品經理、程序員，都缺乏分類、分層、相關、先後能力，更別說總結、洞察能力。

這是基本訓練，是一個做事頭腦清醒的人必備的技能，這不是一個程序員或產品經理或測試員的特定技能要求。

我經常看書就梳理書的脈絡，每看一本就寫一篇總結。我過去閑扯淡還梳理過水滸傳、紅樓夢的人物關系圖呢，其實就在事事上訓練自己的關聯性、層次性、洞察性。

我經常面試一個人時，我會問這樣的問題：「你把我剛才說的話復述一遍，另外你再回答一下我為什麼會這樣？」，其實，我就在看一個人的細心記憶、完整梳理、重現能力，我也在看一個人的梳理、總結、洞察能力。

我個人寫代碼就喜歡先理解業務流，然後理解數據表關系，然後理解產品功能操作流，大致對功能為何這樣設計、功能這樣操作會取什麼表、插入或更新哪些表，哪些表的狀態欄位是關鍵。

然後我寫代碼的時候，就根據我所理解的業務流、功能操作流、數據輸入輸出流，定義函數，定義函數的輸入與輸出。

然後，我會給函數的輸入值，賦上一些固定值，跑下來看看能否跑通這幾個關聯函數，看看還需要怎樣的新增函數，或者看看函數的輸入輸出參數是否滿足跑通。

剩下的事，就是我填肉寫詳細邏輯代碼了。

當然，大部分人沒我這樣的邏輯建模能力。怎麼閱讀理解也想像不出來，也沒法定義函數。畢竟有邏輯建模能力的程序員都很少，100個人里有10個，已經是求爺爺告奶奶好幸運了。

那怎麼辦呢？

我建議是分離分工配合，這就是現實中沒辦法的辦法。讓有邏輯建模能力的人來設計函數框架、來設計工具來設計代碼模板，然後讓沒有邏輯建模能力的人來填肉寫詳細邏輯代碼。

我們可以先從最緊要的模塊開始這么做。不緊要的模塊，還讓它放任自流，讓熟練手程序員繼續塗抹。

我曾經還讓有頭腦的程序員做榜樣，給大家分享他是怎麼規劃函數的，怎麼做維護性代碼的代碼結構改善的。但是發現效果並不佳，其他人並沒有因此能做代碼設計。可能邏輯建模能力是個人的基本素質，是從小到大訓練成型的，不是你一個大學已經幾年的人能夠短時間內可以訓練的。

所以啊，還是讓能走的人先走，讓從最緊要的模塊開始這么做。

不必擔心這樣做後，因為過去一件事被分工（一個做代碼框架一個填肉）成兩個人做了會降低工作效率。我們很多的工作效率低就是因為半瓶子醋搞出來的，來回反復修改。

真是應了劉德華在電影里說的那句話：說你又不聽，聽又聽不懂，聽懂了又不做，做又做不好，做不好還不服氣。

四、為什麼大部分程序員不做代碼測試或白盒測試或單元測試呢？

還是因為沒有代碼設計。因為沒有函數啊。所以，一個按鈕功能有多復雜，代碼就有多長。我見過2000行的函數，我也見過1000多行的存儲過程和視圖SQL。怎麼做白盒測試啊，這些代碼都粘在一起呢，要測，就得從頭到尾都得測。

所以啊，先學會設計函數，先寫好函數，這就求爺爺告奶奶了。很多開發了5年的熟練手程序員，可能都未必會寫函數。

函數的輸入輸出值就很有講究。很多人都寫死了，隨著版本迭代，發現過去定義的函數參數不夠用了，於是就新增了一個參數。然後，相關性異常就爆發了，其他關聯的地方忘改了，到底哪些有關聯，怎麼查啊，本系統沒有，沒准其他系統就調用你了，你根本不知道哪個神經人曾經COPY過你的代碼修吧修吧就改成了他的功能呢，而且裡面的很多代碼他看不懂也不敢刪，只要他實現的功能正常了他也不管了。於是，你改了你這個函數，他的系統就莫名出錯了。

所以，我一般會定義幾個對象來做參數。另外，我也很注重函數的日誌、函數的異常保護、異常拋出、異常返回。另外，我也很注重參數輸入值的合法性校驗。

所以啊，應該開發Leader們先制定函數編寫規范最佳實踐，輸入輸出參數怎麼定義比較好，函數的返回值如何定義比較好，函數的日誌記錄應該怎麼寫比較好，函數的異常保護、異常拋出、異常返回如何寫比較好。先教會一般程序員，先從會寫函數開始啊。

當然，你光有一份規范，程序員們還是不理解、不實際應用啊。所以，還得Leader們做好典型的代碼模板，裡面是符合函數規范的代碼框架，只有這樣，一般程序員們才會照貓畫虎適應了函數設計的編程習慣。

所以啊，我專門重新定義了leader的明確職責，其中第一個重要職責就是：負責工具/框架/模板/規范的制定，並且負責推廣且普及應用落地。

你不明確定義Leader的這個重要職責，你不對這個職責做明確的KPI考核，誰尿你啊。你以為好的工具/框架/模板/規范是靠人們的熱情、自發產生的么？我們還沒有那麼自覺高尚啊。

五、為什麼大部分程序員不寫注釋啊？

我經常說一句話，千萬別多寫注釋。為啥？

因為我們經常遇到的問題不是沒有注釋，而是更糟的是，注釋和事實代碼邏輯是不相符的。這就出現常見問題了：殘存下來的設計文檔是一個邏輯、注釋是一個邏輯說明、真實代碼邏輯又是一個，鍾表多了，你也不知道正確時間了。

所以啊，產品文檔、注釋、真實代碼，三者總是很難一致同步。我為了幾百人研發團隊能做到這個同步花了大量心血和辦法，但我最終也沒解決了這個問題，還把Leader們、總監們、我都搞的精疲力盡。

索性回歸到一切一切的本源，代碼，就是程序員的唯一產出，是最有效的產出。那麼，讓代碼寫的不用注釋也能看懂，咱得奔著這個目的走啊。

為啥看不懂，不就是義大利面條式代碼么，又長又互相交雜。

OK，我就規定了，每個函數不能超過50行。用這一個簡單規定和靜態代碼檢查插件，來逼迫大家嘗試著寫函數。有的函數屬於流程函數，是串起其他函數的，有的函數就是詳細實現函數，實現一個且唯一一個明確作用的。

有了流程函數和功能函數，而且每個函數不超過50行，這就比過去容易看懂了。

六、為什麼大部分程序員不抽象公共函數啊？

我經常說一句話：千萬別抽象公共函數啊。為啥？

因為大部分程序員缺乏抽象洞察能力。特別是有些積極熱情有餘、愛學習愛看書、半瓶子醋晃悠的二桿子，看了幾本UML、重構、設計模式、整潔代碼之道，就躍躍欲試了，還真敢給你抽象公共函數了。

一開始，他覺得80%相似，20%不相似，於是在公共函數裡面簡單寫幾個if..else做個區隔就可以。沒想到，越隨著版本迭代，這些功能漸漸越變越不一樣了，但是這個代碼已經幾經人手了，而且這是一個公共函數，誰也不知道牽扯多少，所以誰也不敢大改，發現問題了就加一個if..else判斷。

沒想到啊沒想到，這個本來當初公共的函數，現在變成了系統最大的毒瘤，最復雜的地方，誰也不敢動，除非實在萬不得已，手起刀落。

所以，我平時告誡程序員，純技術的、純通用的，你們可以嘗試搞搞抽象公共函數，對於業務的，你們還是簡單粗暴的根據Leader們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。

你們啊，先從做模板做代碼片段開始吧，咱們放到咱們內部代碼片段開源庫里，看誰的代碼片段被別人復制的多，說明你的代碼抽象設計能力越好了。那時候，我就大膽放心讓你撒丫子跑了。在沒有學會跑之前，給老子乖乖的復制、修改、填肉吧。

F. 如何提升程序員的代碼編寫能力

在我身邊的程序員中，無論是現在的同事還是過去的同事，普遍缺乏文檔編寫能力或能力嚴重不足，甚至有些編程能力很強的程序員也不能寫出一篇可讀性較強的設計說明書、產品手冊等項目必備文檔。其實，文檔編寫能力是成為優秀程序員和項目經理必須具備的能力，想要和更多人人進行交流只能通過你的文字來傳達你的思想。該如何才能提高文檔編寫能力呢，可以採用了以下幾種方法，只要堅持不懈的做下去，相信會有提高。 1、嘗試編寫個人簡歷和經歷，用文字來認識自己是不錯的方法。要想別人認識你，首先自己要認識自己。 2、養成良好的程序注釋習慣，而且要用准確的語句描述注釋的內容，從寫注釋的一句話開始鍛煉文字表達能力。准確而簡明的注釋有助本人和他人閱讀你的程序代碼，語義不清或者錯誤的注釋反而浪費了自己和他人的時間。 3、從編寫較簡單的文檔（如：《XXX系統使用說明》）開始，鍛煉文檔編寫的組織能力和文字表達能力 4、寫博客。其實這也是我寫博客的原因之一，想通過多寫文章，用文字來准確的表達日常自己的所思所想來提高文檔能力。還可以通過他人的評論和建議來改正不足之處。 6、閱讀一些寫作技巧方面的文章提升技術文檔編寫能力也是顯而易見的。 當然，要切實提高文檔編寫能力，需要勤於學習、勤於思考、勤於實踐、長期積累，畢竟豐富知識和閱歷才是寫好文檔的基礎。