不經意之間已經接觸程式碼一年多了，回頭看向大一那時候的自己，什麼都不懂，但也能過得很開心。今天就寫點東西，給未來的自己一個回憶。

程式設計伊始

大一下開始接觸Java，到現在整整一年了。中間雖然不是一直在學Java，但是還是很親切。那個時候真的是無頭蒼蠅一樣，沒有方向，沒有好的學習方法，到處碰壁。

泡在圖書館，照著書上的例子一個一個的敲，到各種視訊網站上看人家的程式設計經典視訊。時間總是那麼的短，每天都不夠用似得。然而收穫卻總達不到自己的預期。付出與收穫並沒有成正比，看看那個時候的自己，真的是傻傻的堅持著。

然而現在想想，彷彿答案並不是很複雜。從一開始，“路”就錯了。在一條錯誤的路上越努力，離成功就有可能越遠。不顧一切的努力沒有錯，但是前提是適合自己，在思考中努力。

我的反思就是，“在思考中程式設計，而不是埋頭苦幹”。書本，教學視訊，無非是一些輔助。根本不是真正的重點。而且，在初期看些視訊啊，書本什麼的確實很有成效。按照別人的方法，一點點的“臨摹”，確實，當時的程式碼確實是執行成功了，得到了想要的結果。然後就以為自己可以了。然而，卻忘記了最重要的原則，脫離了外界，我能獨立的完成嗎？別人實現的思路真的弄明白了嗎？我想，當時的我壓根沒有思考過這個問題吧。不然也不可能荒廢了那麼寶貴的時間。

但是，過去了，就真的是過去了。是更改不了的事實，唯一能做的就是儘量的去彌補。

程式設計之道

這裡是說給自己的一番話，如果你恰巧看到了這些，而且也比較的適合你，那麼我很榮幸！

“需求”分析

這裡用了“需求”這個詞語，屬於斷章取義。然而意思沒有變，在我們程式設計之前，不知道有多少人真正的思考過，我們正面臨著什麼樣的問題。真的分析的透徹了嗎？

我見過很多人，包括我自己。拿到一個問題，立馬就著手coding了。但是做著做著就迷茫了。或者返工，更有甚者，就那麼放棄了。那麼我們今天不妨想一想，

• 我們真的弄明白問題了嗎？

• 我們要完成一個怎樣的功能？

• 我們要以怎樣的方式來解決這個問題？

• 我們的這個方式的可行性有多大？
  ·
  ·
  ·

  真正的弄清楚問題，不是我們認為的那麼簡單。

註釋的藝術

註釋，有多少人真正會註釋？就連我自己，我都汗顏，因為我不怎麼會註釋。而且我也相信，大多數人和我一樣，並不會註釋！作“註釋”可以算得上一個非技術性，非智力性的活動。

我們不妨先自己反思一下，註釋是幹什麼的？

難道僅僅是為了讓別人看到這個註釋完成的功能嗎？

我想說的是，是的。註釋很大的一方面就是為了讓別人瞭解程式碼的功能，這也是註釋存在的根本的意義！然而我們很多人沒有想到的是，註釋不僅僅是這樣的。

註釋的原則：程式碼邏輯是怎樣展開的，而不簡單是程式碼做了什麼

我想我們大部分人，都是停留在後者吧。是時候反思一下了。

註釋的規範：這一點我不敢說多咯，因為規範這種東西，真的說不好。我一直認為，根本沒有什麼萬能的規範，適合的才是最好的。對於團隊而言，亦是如此！

空格的魅力

空格鍵，鍵盤上面積最大的一個鍵位。我們也許都會認為，它無關緊要，很平凡，很普通！ 但是我想說的是，它很偉大。我們大部分人都沒有認識到，空格給我們帶來的美感。

可能，在一個平臺上，這一點體現的並不是很明顯。比如我用的是Windows，你用的也是Windows，所以你拷貝完我的程式碼，在你那顯示的依舊很完美。很正常。但是加入你的是Linux，我的是Windows，別人的是Unix呢？程式碼還會顯示的很一致嗎？

答案並不是。這一切的一切都是因為一個tab鍵，這個讓人又愛又恨的鍵位。不通過平臺的tab鍵處理方案的不一致性導致了這一問題的出現，較好的解決方法就是放棄使用tab鍵，而是改用空格鍵。

相信，如果你遇到過跨平臺檔案編輯時讓人痛苦的排版問題。特別當你是一個喜歡用tab鍵的Python程式設計師的時候，痛苦會加倍上升吧。

起名字的藝術

你也許聽到別人說過，關於coding的時候命名的規範。然而每次當你需要命名一些變數，方法（函式）的時候，卻又總是忘記來應用。

還記得大一的時候學習C語言，看到一串串的i,j,k,p,o,m,n···光是想想，就讓人心煩，這些變數的取名是沒問題，但是這一大串的無意義的名字，唯一帶給我們的就是繁重的記憶負擔。削弱了我們對程式碼邏輯的理解能力。

我的建議：不管是對變數，方法，函式，類···，命名的時候先思考一下，斟酌之後再敲下你的命名。這對程式碼維護會很有幫助的。

早前，看過一段話，大致如下：

設想一下，當你走過你的程式碼的被照亮的森林時，你在身後留下了麵包屑。相信我，當你需要找到回去的路時，森林將充滿可黑暗，朦朧和不詳的預感。

其意蘊，自己體會一下吧。相信有過經歷的人，會刻骨銘心吧。

重構之道

重構Refactor.一個看似晦澀難懂的詞語，但是其作用卻是何等的巨大。

重構的目標就是消除重複程式碼，降低耦合，便於維護。

但是你會重構嗎？重構不是簡單的把一段段的程式碼塊揉到一個方法裡面，有些時候。看似重複的程式碼也是不能整合成一個的。說起來很蒼白，但是真的是很有韻味。

下次，編碼的時候，儘量把你的程式碼做的規範一下，該刪的刪，該合併的合併，儘量以一種匠心來編寫你的程式碼。當然了，這種能力不是說說就會有的，關鍵在於鍛鍊。

測試之路

我自己的專業就是軟體開發與測試，貌似矛盾的二義性的專業。做程式設計師的都明白，開發部和測試部基本上屬於仇敵型別的兩個部門。仔細的想一想，關鍵就在於程式碼的測試上。

一段健壯的程式碼，經得起千錘百煉；對於目前的我們，完成一個小功能（方法，函式）的時候立刻，現在，馬上做測試。而不要拖延，否則虐心的只能是自己。

除錯的藝術

說起除錯，我就得批評一下我自己了。因為懶，所以懶得打斷點，懶得查堆疊。總是使用：

• System.out.println()
• Log.i()
• print
• printf
• console.log()
  ·
  ·
  ·
  其實這種方式並沒有我們想象的那麼好，尤其是程式碼量特別巨大的時候。除錯只能讓我們心焦氣燥。我們要學會使用Debug，這將是我今後努力的方向！

學好Debug，遇到再多Bug也不怕。

寫在最後

作為一個尚未入職的學生，寫下這段蒼白的語段，留念而已。希望將來的我，回過頭來在看到這篇文章的時候，能感到一絲絲的欣慰。

青春嘛，留下點回憶，總歸是好的。

願經年之後，此心依舊！

                                ---- 致 未來的自己。