程序員想要培養寫代碼的能力

1. 目前大一，在學C++，應該怎樣提高自己的編程能力

我本人一直從事C，VC++，VS等方面的軟體開發工作。

基礎，很重要。計算機硬體結構，數據結構，資料庫，編譯原理，C，JAVA語言，軟體工程，操作系統，高數等等。怎樣就算合格？絕不是考試及格就行。我看過很多高校的考試題，即使得一百分，你最多是剛入門的水準。這些是必修。

2，結合理論，做深入的編程研究

這一部分是所謂的實踐。紙上得來終覺淺。計算機的摩爾定律，每五年更新一次。所以，你們老師講的那一套，原理大致對，但現實，已經改變了。

如：CPU，也許你學的是X86的基本，但從Pentium至I5，I7。主板中增加的GPU/VPU，多線程，南北橋等，也許你聽了就暈的各種名詞。

各種IDE軟體安裝，如VS2019，JAVA等。別小看安裝，十有八，九不會做。

軟體開發，做界面UI，各科通訊，文件操作，MFC控制項應用，Process及Thread，定時器，RTOS如何使用等等。

3，進階，學習《設計模式》，架構，演算法，做一個綜合類APP。

推薦學習《設計模式》，可你你進階。架構可學習理論。說實話，讓剛畢業的大學生搞架構，是一個大大的Joke。你很自信，用人單位絕不認腔喚鋒可你那一套，沒有實戰，何談架構？

演算法，學校也開相關課程，但僅理論。如此公共化的理論，用人單位還需要你開發么？所以，看明白就行了。

做一個集多線程多頁面UI，演算法，網路通信，基於SQL的數據遠程交換等於一體的APP，我認為你基本就可畢業了。當然，後期可跟老師做一些工程也是可以的，但千萬要與市場結合。

看你的問題，你是想提高自己，不想落在所謂大佬們的後面！我給你的建議，既然已經在學c++，那就先把它學好，基礎打牢，基礎包括編程語言基礎，編程能力基礎！編程能力基礎非常重要，在別人看來可能非常無聊，也沒有成就感，新手如何練習，最簡單的方法就是去買本演算法習題集，把裡面基本功打好，學會分析需求，需求再如何轉換成詳細設計，多思想總結，反復練習，出山就是架構師思維，今後做項目，擼起袖子就可以開干，什麼編程語言都是個把兩個星期就熟了！不需要眼紅別人做項目，我覺得你剛開始去做，也是給人打下手，反而不利於你進步，並且這些項目也不見得多有水平，況且帶你做項目的人水平也不見得高！說實話，我見過好些在大學里跟老師做項鏈游目的，無非就是多了解了些工具，多見了些平台，還留下了一堆不好的編程習慣！這些項目的含金量不一定比好大學的課程設計高，比如華科自動化的c語言課程設計，難度高，感覺好多不入流的程序員，工作幾了，也不見得能完成！

總之，在學校里，學習技術，多重基礎技術能力，輕業務應用，畢業了能幹啥，也說不準！

我現在大二，二本學校計科專業。我談一談我自己的學習吧。

大學選計算機也是出於一種莫名的吸引，我之前對計算機沒有過任何的了解（除了打 游戲 ），對於專業很大一部分同學來說基礎是比較差的，專業課學習也比較吃力。

然後自己開始零零散散學習Java，先是自己找網課看，然後多練，多練，多練。這真的是唯一的捷徑。有很多東西你可能第一遍看不懂，寫不來。不用管，你就寫三遍，五遍，十遍，二十遍，邊寫邊理解，最後一定不會太差。

我也處於成長的階段，按照這樣的方法，我相信現在的水平和我們學校同年級同專業的相比應該算排在前列的了。加油吧！

你好，一個具有八年編程經驗的工程師來回答你的提問，關於大一學習C++，一些學生在跟著做項目，你怎樣提高自己的編程能力？我將根據自己的 學習和工作經驗 ， 在程序語言學習、我自己的編程經歷和對大學生學習編程的建議 三個方面作答：

一、程序語言學習過程

根據我自身的學習經驗，我將編程語言的學習進程 分為 4步 ：

1.基礎知識學習

這部分需要根據書本或者老師的講解，理解一種程序設計語言的基 本語法和功能 ，這個階段過去一般能夠讀懂程序的片段 ；

2.看以及修改別人的代碼

經過第一階段後你可以讀懂基本的語法，想要進步快就直接看別人寫的程序，雖然這一步很枯燥，但是 成長必須經歷 的，在理解別人的代碼基礎上進行修改，查看修改後的運行狀態，這一步能夠讓你從會讀代碼片段到會 思考程序的設計 ；

3.獨立進行程序設計

找一些功能需求，哪怕是一個小項目或者課程實驗，盡量獨立完成！遇到不會的要自己思考，實在解決不了再去查資料解決，這一步能夠讓 你真正會編程序；

4.自己主動設計架構和需求

到了這一步你能真正的理解，程序語言只是一個工具，真正難的在於項目，而非語言的限制，去學習 軟體架構的設計 吧，尋求如何更好的把軟體做的更漂亮。

二、自身的學習經驗

我自己在大一的時候只是學習了C語言，甚至計算機二級都是考了兩次才過，當時最大的問題在於 語言的學習只在課本之中 ，沒有現實的需求，到了大二以後，逐漸做了各種比賽和課程實驗，慢慢對語言有了更深刻的認識，到了大四後就可以脫離課本獨自設計軟體程序了，但這離工作後公司的項目需求還差的很遠，我們經常說的一句話叫做， 軟體寫出來很容易，寫好卻是很難的一件事 。

三、對大學生編程的建議

1.興趣是一切學習的推動力，要培養自己編程的興趣，真正的是 為了喜歡而做事對一輩子都是受益的 ；

2.書本知識一定要學好， 打好基礎 ，是一切的前提；

3.不局限於書本，打好基礎後一定要 多練習 ，既然語言是工具，那麼用的越多你就越熟悉它；

4.養成 歸納和總結思考的習慣 ，定期歸納總結自己的知識和技能，我相信這個習慣可以堅持一輩子。

最後，針對你的問題，大一剛開始，先不要著急做項目， 一定先打好基礎 ，記住 多看、多學、多問、多練習 ，但這不是安逸的理由，基礎打好以後，立即爭取機會，向其他同學那樣加 入項目團隊，多參加比賽 ，爭取所有能夠鍛煉你的機會！在現實的世界裡大展你的所學，祝你學有所成！

以上是我的個人經歷和經驗總結，希望對你有幫助！

作為一個大一的學生，其實不用過於著急，只要你規劃好你大學四年的一個學習提高計劃，未來你也就是大佬。

我們不管是看過再多的書，分析了再多的源代碼，你不去自己寫一下代碼，很難知道其中實現的一些原理，為什麼這樣實現？相比其他實現方式有什麼好處？

所以，「實踐是檢驗真理的唯一標准」這句話到哪裡都很適用。

雖然我們說需要實踐，但是怎麼實踐？可能對於大一的同學來說，這個也是一個搞不清答案的問題。所以，我們需要整理一個粗略的學習計劃，按照這個計劃，我們一步一步來豐滿自己的學習內容。

學習計劃的話，我只能簡單分享一下我的一些想法。

首先，我們大學的課程還是要學好的。可能有人會覺得，大學學的東西在未來的工作中不一定會用得到，還不如多學一些實際應用的知識。

我可以很負責任的告訴你，這種想法是錯誤的。大學學習的所有東西都是基礎，而基礎一定是很枯燥的。但是，在經濟學中我們學到過：經濟基礎決定上層建築，計算機的基礎也是一樣的。你未來成就的高低，很多就在於你的基礎是否扎實。所以，珍惜大學這段能否全心全意且無憂無慮學習的時光吧。

在大一的時候， 除了基礎的學習以外，自然我們還是要更多的豐富自己，畢竟單靠基礎什麼也做不了。所以，大一的時候，我們就在編程的基礎知識上也下點功夫，學習一下語法、資料庫、簡單的架構和演算法。

邊學習的過程中，可以邊通過實踐來練習自己的能力。我曾經在大學的時候做過兩個練習，也可以分享給同學們（不知道會不會過時）。

一個是計算器，別看計算器的功能很簡單，但是裡面能夠玩出很多的花樣，可能最開始你需要幾百行的代碼才能夠做出來，隨著你知識的積累，可能最後幾十行代碼就實現了。標準的計算器實現以後，就可以考慮提升難度，做做支持科學計數法的計算器。當然，如果你想挑戰自己，還可以將科學計數法中的演算法自己來實現。

第二個就是音樂播放器了，這個就不多說了，當然，做播放器的話，可以去找一些開源的插件，不必什麼都從頭開始，最終只是實現播放功能而已（我大學時候也做過一個）。

「力扣」也是一個不錯的網站，這裡面有很多練習題，可以在這里鍛煉自己的代碼能力。

到了大二， 自然就不能只是單純的謝謝代碼了，我們要從設計模式、架構、通訊協議等各個方面來優化自己，其中就還需要學習使用各種類型的中間件。而這些方面的知識點其實是非常多的，很多東西沒有放到實際的環境中，其實很難能夠體會到原理。所以，我們還是先學習理論，啃書的同時，可以自己假設一些環境，來做做練習。

雖然自己假設的內容可能和實際差距非常遠，這個沒有關系，錯了再改正，其實印象會更加深刻。

這個時間，可以多看看別人的代碼，開源社區裡面有很多可以學習的內容。例如：你看到了領域驅動設計，光看書的話，估計真的是雲里霧里的。這時候就去找別人寫的代碼來看看，一句一句的Debug理解，再回來看書的時候，你就50%以上都能夠懂了。

當然，學到合適的時候，就可以考慮學以致用了，找找兼職，不求賺錢（但也別白做，雖然你是學生，但付出勞動得到回報不可恥），但求練習自己的能力。

到了大三， 其實大二的那些內容可能很多你並沒有完成，沒有關系，很多的知識直到你工作多少年以後，可能都還在繼續學習。我們沒有完成，但是依舊可以進行下一步了，就是定目標。經過大一大二的這些練習，在開源社區的活躍，你未來想從事哪個方向的編程就需要定一下了，因為各個領域所需要的知識點是不同的。

如果你要做電商，那就了解一下電商領域的各種知識，什麼是電子商務，什麼是供應鏈。如果你對行業內的應用程序感興趣，那可以了解一下財務相關知識，管理相關知識。

然後就是，大三可以說是你全心學習的最後一個階段，可以考慮為未來做些打算，參加軟考拿點證書等等。

大四了 ，就沒有什麼好再說的了，路都在自己的腳下，怎麼走出輝煌也就看自己了。

大一主要是提高語言編程能力，除此之外，還需要學習數據結構與演算法，資料庫，計算機網路，操作系統。所以現在也不要急於求成，你需要學習的還有很多。現在大一能做項目的，要不就是實力確實很強，要不就是寫寫項目中的一些基礎代碼。提高自己的編程能力的方法就是coding coding coding!

編程學習沒有捷徑可走，唯一有效的方法就是不停的寫代碼，編譯器寫代碼，記事本寫代碼，手機寫代碼，草稿紙寫代碼，只要有想法就寫出來，然後等有編譯器環境了不停的調試，只要經過反復IDE調試練習，才能提高自己的編程能力。語法只有不斷的使用才能更加熟練。

這些比賽是高校等計算機組織和機構舉辦的比賽。計算機類競賽有著非常多的優勢，比如有機會進國家隊或者取得不錯的加分和保送資格。而且對於理工科學生大都需要極端就編程能力，信息類學科的競賽更是離不開編程能力。學習編程對培養邏輯思維很有效，對其它學科也很有幫助。

別管自己能力有多菜，只要有機會就一定要抓住。因為作為計算機專業學生，以後無論保研復試，還是找工作都離不開編程能力的考察，所以有一些項目，不僅可以豐富自己的簡歷，更重要的是能夠提升自己的編程能力。

只有參加比賽才知道自己水多深，如何提高自己的代碼能力才是王道。互聯網公司的實戰比賽跟上面的大學生計算機能力比賽有些區別，這里更貼合實際問題，用一些互聯網項目的實際問題，考察學生的代碼編程能力。

實驗室一同學，參加了阿里的天池比賽，並取得了不錯的成績，其實這個同學跟大牛組隊，算是抱住了大腿。後來在找工作的時候，公司因為這個同學簡歷上的這個比賽獎項，給了這個同學SP offer,比正常價多出快10萬的年薪。你說他香不香？

總結：作為計算機專業的學生，一定要練好總結的拿手絕活-編程能力。無論找工作還是保研，只有出色的代碼能力才能贏得別人的肯定，而提高編程能力的方法就是不停的動手寫代碼。

既然你是計算機專業，目光就要放遠點，不要著急別人在做什麼。編程是最基本的工具，本身是不難的，職業學校也有軟體編程專業。對於計算機專業學生，未來職業願景，一是核心演算法設計師，二是軟體架構設計師，這兩個職位如果沒有良好的專業背景是不能很好勝任的。所以本科階段要努力打好專業基礎和專業核心課程。專業基礎包括離散數學、數據結構、人工智慧基礎等。專業核心包括計算機組成原理、操作系統、編譯原理、機器學習等。編程實踐在這些課里都有機會，甚至對自己編程能力的提升不亞於去做一個具體的項目，當然有機會去做項目更好，沒有也沒關系。還有軟體工程課程也很重要，要做軟體架構師，這門課程也很重要。另外，高層次軟體從業者必須具備較強的邏輯思維能力和數學功底，比如現在最熱的機器學習演算法設計，必須具有良好的線性代數、概率與數理統計、高等數學等數學基礎。大學四年最重要的是打牢基礎！

作為一名計算機專業的科研教育工作者，我來回答一下這個問題。

對於大一的同學來說，要想提升自身的編程能力應該首先從夯實基礎開始，編程能力的提升需要一個系統的過程，這個過程要系統學習包括數據結構、演算法設計、操作系統、資料庫、計算機網路等相關知識，而這些課程作為計算機專業的核心課程，後續都會陸續接觸到。

大一期間學習編程要重視三件事，其一是重視編程語法的學習，理解編程語法當中的抽象概念，比如C++語言就是一個典型的面向對象編程語言，自身的抽象程度還是非常高的，所以理解這些抽象概念是第一步。要想理解這些抽象概念一定要有大量的輸入，也就是要閱讀大量的學習資料和開發案例代碼，同時完成自己的總結歸納，從而形成自己的編程思想。

其二是重視實驗，學習編程語言一定要邊用邊學，實驗對於學習編程語言的促進作用是非常明顯的，通過實驗也能夠為眾多抽象概念建立起畫面感。在進行實驗的過程中，既要重視實驗的數量，同時也要重視實驗的質量，實驗要有層次，要重視綜合性實驗，這對提升編程能力還是比較重要的。

其三是重視交流和實踐，對於大一的同學來說，除了課堂學習時間之外，要想為自己營造更多的交流和實踐機會，可以通常積極參加專業比賽，或者是參加老師的課題組來實現。按照 歷史 經驗來看，參加專業比賽對於提升編程能力的幫助作用還是比較明顯的，也能夠開闊自身的視野。

如果有互聯網、大數據、人工智慧等方面的問題，或者是考研方面的問題，都可以私信我！

對於編程的能力提升，需要有扎實的基礎，編程語言的理論知識和編程的熟練度是否已經非常的熟悉，如果說編程語言還不是太熟悉，那麼建議把理論知識再去學習一下，多動手做一些編程的實驗，寫一些小功能的代碼來提高自己的代碼水平熟練度

如果說對代碼的理論知識非常了解，對於寫代碼的熟練度也很高，那麼快速提升編程能力的方法，就是在項目的實戰中提升自己，在一個項目中可以了解到構建一個項目的完整流程，包括最初的架構設計，功能的代碼實現，代碼的優化調試，單元測試，性能測試，覆蓋測試等等。可以在互聯網公司實習一段時間看看開發的流程，編寫一些系統功能優化的代碼，或者直接去github上面尋找優秀的開源代碼，可以做一些優化的修改，功能的添加等等，這些都可以提高自己的編程能力

你好，我是一名軟體工程師，也是編程的培訓講師，這里給你分享一些經驗，希望可以幫助到你。

首先，看到別人做項目了，自己不要急，最好還是把理論理解清楚。

其次，理論基本理解的基礎上，可以在網上尋找幾個相關的案例代碼進行分析，閱讀別人的代碼。

最後，通過外包也好，老師介紹也好，積極參與實踐，前面不要想著賺多少錢，學點經驗才是王道。記得，幾年前在西華師范大學職教的時候，一位領導說找幾個學生把繫上的網站重新修改一下，給學生拿點補貼，居然有學生嫌補貼太少不願意做。

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

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

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們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。

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