Ⅰ net程序員怎麼提升自己的技術能力
一、先列三個常見的開發場景：
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們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。
你們啊，先從做模板做代碼片段開始吧，咱們放到咱們內部代碼片段開源庫里，看誰的代碼片段被別人復制的多，說明你的代碼抽象設計能力越好了。那時候，我就大膽放心讓你撒丫子跑了。在沒有學會跑之前，給老子乖乖的復制、修改、填肉吧。
Ⅱ 開源如何提升編程技能
開源是很多程序員都會面臨的問題，很多人會相信接觸的開源源技術越多對自己的編程技術提升越快，寫出來的代碼也更好。開源可提高編程技能之間有什麼相關性或因果關系嗎？
閱讀代碼能讓你變得更優秀
我在編程生涯的早期就明白我閱讀的代碼越多，我的代碼就能變得更好。我知道，當我不得不維護其他人的代碼時，簡單和干凈的代碼幾乎總是比花哨或復雜的代碼好——即使有注釋。然而另一方面，當我花足夠的時間去理解復雜代碼的時候，我常常能夠學到新的技巧。不論怎麼樣，都能讓我有所提高。
這使得我在那些沒有代碼審查的地方一再爭取。而當沒有足夠的時間來正式執行「代碼審查」的時候，我會自己瀏覽存儲庫和閱讀代碼。當然，那時我還被受限於來自於小團隊的公司資源。
超越語法
在你不得不全力對付任意編程語言的語法時，也就是學習如何充分利用該語言最瑣碎的時刻。一門語言的語法往往是非常靜態的，並且如果你出錯了，你的編譯器會向你控訴。更深層次的課程涉及到什麼語言最適合解決什麼樣的問題（「合適的工具做合適的工作」），以及如何用那種語言編寫代碼以便於使它高效和可維護。
學習新語言有許多方法：課程，教程，導師，書籍以及等等。我通常會結合這些選項來學習一門新的語言。我注意到，當涉及到非語法元素的時候，這些方法常常非常相似。
閱讀來自於其他人的實際部署代碼會讓你收獲更多。不僅僅是常規的結構化學習，你還需要學習模式和實踐方法。語言中所謂「正確」的做事方式並不總是效果最佳的方式。你會經歷邊緣情況，一次性事務以及意想不到的集成。你也會找到這些問題的解決方案，有好有壞，但如果你認真思考的話，那麼這正是出來「推薦做法」的地方。今天的模式就是明天的反面模式。
你可能對有些事情，例如「總是注釋」，「逗號放到最後」，「縮進x個空格」有著自己的想法，當然你是對的。我對提到的這些及編碼的其他方面也有著自己的感受。
有時候當我閱讀其他人的代碼時，如果看到他們做錯了，我會生氣。但是隨著我代碼閱讀量的增加，我開始懂得，總會有一些情形常見於別人的代碼，但我在我自己的代碼中卻未曾遇到過的，並且我的方法沒有必要那樣執拗。我不僅改變了我的一些觀點，而且懂得更加靈活。
開源無處不在
隨著開源運動的發展，可供閱讀和學習的代碼數量也大幅度增長。例如Gitlab，GitHub和到BitBucket這些網站就允許我們獲取全功能的應用程序，不僅可以閱讀代碼，還可以擺弄。很少有我想要學習的東西是不能在開源代碼中獲取的。
我以前學習新的編程語言，會把重點放在諸如目錄結構和命名約定這些簡單的事情上。但是，現在，我會找一些不同的開源項目，然後可以開始拼湊常用的方法。我很少強調以前那些類型的東西了。
可用的代碼是如此之多，但質量卻良莠不齊。當我們想要學習的時候，常常搞不清楚哪個好哪個不好。那就保持閱讀代碼吧，慢慢地你會學會如何區分。閱讀「壞」的代碼可以幫助你理解為什麼它是「壞」的。關鍵是不要害怕嘗試任何你覺得看上去正確的東西，並且當你走錯路的時候能夠承認錯誤，並改正問題，然後繼續前行。
壞的代碼就壞的，是這樣的嗎？
有人會說「壞的代碼比好的代碼要更多更明顯」。sub-reddit致力於壞的代碼。
在這些年裡，我寫了很多好的代碼和壞的代碼。當我看到我以前寫的代碼時，我的第一想法就是我怎麼會寫這樣的垃圾代碼。這實際上意味著我還在學習中。如果我看到我以前的代碼，覺得它看上去非常偉大，那麼說明我並沒有提高。
那麼，我們怎麼才能從壞的代碼中學到東西呢？
你閱讀的壞代碼越多，那麼你就越擅長發現壞的代碼
當你在學習和搜索例子的時候，你會發現和使用大量不能工作的代碼。請記住，僅僅因為它不適合你的情況，並不能說明它就是壞的代碼。學習如何讓它工作能夠使得你變得更優秀。
你怎麼知道它是壞的代碼？
人們喜歡批評。閱讀評論，如果你看到很多「WTF（什麼玩意）」，那麼可能你看到的正是壞的代碼，試著指出為什麼不好的原因。不要只留下「這代碼真爛」這樣的評論。不要裝得你好像懂得壞代碼的所有需求，要知道，總有一個它之所以被這樣寫的正當理由。如果你知道它為什麼是壞代碼的原因，那麼不妨留下一個有建設性的評論。或者??
讓它變成好的代碼
放一個能讓代碼變得更好的pull請求。修正語法，使用更好的方法，添加註釋或修改縮進：這些都是改進代碼的偉大方式。加一個為什麼你推薦改變代碼的解釋。
昆明北大青鳥java培訓專家認認為，當我幫助別人學習的時候能學到更多。如果我認為我理解了一個新的主題，那麼我會找個人來試著向他解釋，這能讓我更深刻地理解和記住它，並且讓我快速發現我是否寫了壞的代碼。
回報
記住開放源代碼在你參與進去的時候效果最佳。代碼更改在大多數項目中都是受歡迎的，但是有很多出力的方法。
測試開源代碼和文件錯誤報告；幫助完成文檔集；寫教程和如何做的例子；參加對話——或者僅僅只是幫助傳播。每一件事都能帶來改變，並且越多的人參與進來越好！