程序員怎麼提升源碼

❶ 對程序員來說，在公司里真的能提升寫代碼的水平嗎

現在的網上會流傳"程序員禿頂"這一說法，到底程序員是有多費頭發？不就是寫寫代碼，敲敲鍵盤就可以了嗎？還有，寫了這么長時間代碼，是不是真的像電視上演的那樣，各種代碼隨便敲，而且表現出來的都非常帥氣，這些到底是真的嗎？

其實，對於程序員掉頭發這一件事，只能說是因為用腦過度，導致脫發。而且經常坐在電腦面前，​臉上頭上都會多多少少出油，從而會導致脫發比較嚴重，也就出現了"油膩大叔"這類的詞，所以說現在的很多人一聽到程序員就不由地想到了這四個字！

最後要學會代碼重構。學習新東西，肯定會導致一些邏輯混亂。這個時候就需要自己在腦中進行重新構思，進行排序，相信經歷過這些，在以後的編排中肯定會更加得心應手！

❷ java程序員如何提升自己

關於java程序員如何提升自己，建議從下面幾個角度提升：
1、提高自己的邏輯思維能力。嚴謹的邏輯能力是高水平的程序員區別於低水平的程序員的一個原因。高水平的程序員可以在設計和邏輯上保證滴水不漏, 並用邏輯的准確性來減少代碼 bug。
2、堅持不斷學習並嚴格要求自己。強化自身代碼調試的能力以及勇於去研究你不懂的代碼，熟悉不同的代碼結構和設計模式。
3、此外，保持長久而主動的學習，保證技術的更新。另外，可以通過一次次的實踐去培養編程思維以實現自身的提高。

❸ 開源如何提升編程技能

開源是很多程序員都會面臨的問題，很多人會相信接觸的開源源技術越多對自己的編程技術提升越快，寫出來的代碼也更好。開源可提高編程技能之間有什麼相關性或因果關系嗎？

閱讀代碼能讓你變得更優秀

我在編程生涯的早期就明白我閱讀的代碼越多，我的代碼就能變得更好。我知道，當我不得不維護其他人的代碼時，簡單和干凈的代碼幾乎總是比花哨或復雜的代碼好——即使有注釋。然而另一方面，當我花足夠的時間去理解復雜代碼的時候，我常常能夠學到新的技巧。不論怎麼樣，都能讓我有所提高。

這使得我在那些沒有代碼審查的地方一再爭取。而當沒有足夠的時間來正式執行「代碼審查」的時候，我會自己瀏覽存儲庫和閱讀代碼。當然，那時我還被受限於來自於小團隊的公司資源。

超越語法

在你不得不全力對付任意編程語言的語法時，也就是學習如何充分利用該語言最瑣碎的時刻。一門語言的語法往往是非常靜態的，並且如果你出錯了，你的編譯器會向你控訴。更深層次的課程涉及到什麼語言最適合解決什麼樣的問題（「合適的工具做合適的工作」），以及如何用那種語言編寫代碼以便於使它高效和可維護。

學習新語言有許多方法：課程，教程，導師，書籍以及等等。我通常會結合這些選項來學習一門新的語言。我注意到，當涉及到非語法元素的時候，這些方法常常非常相似。

閱讀來自於其他人的實際部署代碼會讓你收獲更多。不僅僅是常規的結構化學習，你還需要學習模式和實踐方法。語言中所謂「正確」的做事方式並不總是效果最佳的方式。你會經歷邊緣情況，一次性事務以及意想不到的集成。你也會找到這些問題的解決方案，有好有壞，但如果你認真思考的話，那麼這正是出來「推薦做法」的地方。今天的模式就是明天的反面模式。

你可能對有些事情，例如「總是注釋」，「逗號放到最後」，「縮進x個空格」有著自己的想法，當然你是對的。我對提到的這些及編碼的其他方面也有著自己的感受。

有時候當我閱讀其他人的代碼時，如果看到他們做錯了，我會生氣。但是隨著我代碼閱讀量的增加，我開始懂得，總會有一些情形常見於別人的代碼，但我在我自己的代碼中卻未曾遇到過的，並且我的方法沒有必要那樣執拗。我不僅改變了我的一些觀點，而且懂得更加靈活。

開源無處不在

隨著開源運動的發展，可供閱讀和學習的代碼數量也大幅度增長。例如Gitlab，GitHub和到BitBucket這些網站就允許我們獲取全功能的應用程序，不僅可以閱讀代碼，還可以擺弄。很少有我想要學習的東西是不能在開源代碼中獲取的。

我以前學習新的編程語言，會把重點放在諸如目錄結構和命名約定這些簡單的事情上。但是，現在，我會找一些不同的開源項目，然後可以開始拼湊常用的方法。我很少強調以前那些類型的東西了。

可用的代碼是如此之多，但質量卻良莠不齊。當我們想要學習的時候，常常搞不清楚哪個好哪個不好。那就保持閱讀代碼吧，慢慢地你會學會如何區分。閱讀「壞」的代碼可以幫助你理解為什麼它是「壞」的。關鍵是不要害怕嘗試任何你覺得看上去正確的東西，並且當你走錯路的時候能夠承認錯誤，並改正問題，然後繼續前行。

壞的代碼就壞的，是這樣的嗎？

有人會說「壞的代碼比好的代碼要更多更明顯」。sub-reddit致力於壞的代碼。

在這些年裡，我寫了很多好的代碼和壞的代碼。當我看到我以前寫的代碼時，我的第一想法就是我怎麼會寫這樣的垃圾代碼。這實際上意味著我還在學習中。如果我看到我以前的代碼，覺得它看上去非常偉大，那麼說明我並沒有提高。

那麼，我們怎麼才能從壞的代碼中學到東西呢？

你閱讀的壞代碼越多，那麼你就越擅長發現壞的代碼

當你在學習和搜索例子的時候，你會發現和使用大量不能工作的代碼。請記住，僅僅因為它不適合你的情況，並不能說明它就是壞的代碼。學習如何讓它工作能夠使得你變得更優秀。

你怎麼知道它是壞的代碼？

人們喜歡批評。閱讀評論，如果你看到很多「WTF（什麼玩意）」，那麼可能你看到的正是壞的代碼，試著指出為什麼不好的原因。不要只留下「這代碼真爛」這樣的評論。不要裝得你好像懂得壞代碼的所有需求，要知道，總有一個它之所以被這樣寫的正當理由。如果你知道它為什麼是壞代碼的原因，那麼不妨留下一個有建設性的評論。或者??

讓它變成好的代碼

放一個能讓代碼變得更好的pull請求。修正語法，使用更好的方法，添加註釋或修改縮進：這些都是改進代碼的偉大方式。加一個為什麼你推薦改變代碼的解釋。

昆明北大青鳥java培訓專家認認為，當我幫助別人學習的時候能學到更多。如果我認為我理解了一個新的主題，那麼我會找個人來試著向他解釋，這能讓我更深刻地理解和記住它，並且讓我快速發現我是否寫了壞的代碼。

回報

記住開放源代碼在你參與進去的時候效果最佳。代碼更改在大多數項目中都是受歡迎的，但是有很多出力的方法。

測試開源代碼和文件錯誤報告；幫助完成文檔集；寫教程和如何做的例子；參加對話——或者僅僅只是幫助傳播。每一件事都能帶來改變，並且越多的人參與進來越好！

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

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