在工作中經常被問道：如果你的那個方法輸入空會返回什麼？我記得自己曾經使勁回憶也沒想到自己那個方法是怎麼個回事。也經常跟同事在對功能的時候在說**，那個氣泡排序，兩個迴圈就搞定了。。。。。漸漸就發現，很多時候，寫**是有規則去遵循的。然後自己結合自己工作中的一些小經驗，就出了下文，也許很糟糕，也許很好，但是現在真的很適合我，如果你在寫**之前也很迷茫過，那麼也許可以幫上你的大忙。
1. 當你開始寫乙個方法的時候，你一定要知道他要幹什麼
你要明白，這個方法的場景。
總結：一般我拿到是乙個功能，我會問自己為這個功能的意義是什麼？他給那些使用者用，那些角色用?我的時間夠嗎？ 我做到什麼程度就ok了？我先做什麼？那些功能是先出來的，那些可以後出來？
2. 找到已知條件與未知條件，你需要做的是梳理他們的關係?
我記得有乙個方法，我用了一上午的時間在梳理表之間的關係，但是我只用了半個小時就把這個方法完整的做出來了。現在有的條件是什麼，沒的條件是什麼？整個過程中那些是自己知道的，那些是自己不知道的？我必須知道什麼才可以去寫**，我的風險點在**？大概的引數的流轉是怎麼流動的？我最後會把這些疑問全部消除掉，然後又乙個很清晰的流程。
總結：這個過程我感覺是最主要的乙個過程，我花時間最多的也是這裡，基本上是問問問，有的時候只要查表結構就ok了，但是更多的時候由於文件的不完整性，基本是這樣的,乙個方法要問n個人，這時候就要發揚程式設計師的「不要臉」精神了。我基本上是拿張紙邊寫邊梳理的，梳理完之後，基本上還會去找之前做過的人自己在講述一遍，問問是不是這個邏輯（當然這只是比較不熟悉的模組了），簡單的還有一種直接方式，自問自答，來驗證自己寫的方法是否正確，反正我一直有自問自答的習慣，因為沒人給我確認了，只有自己給自己確認了，這個過程中能把自己思路梳理出來，我管這個叫說**，而不是寫**。
3. 真的開始可以寫了
如果你真的想好了，有自己的邏輯了，那麼真的可以寫**了，就按照2說的寫就好了，這是多麼有意思的乙個過程呀，把你說的用**進行表述。但是我基本上開始寫的時候寫的是一把偽**，把自己想到的寫下來，接著會去填**塊，邏輯如果超級簡單的就真不這麼幹了，太費時間了。
總結：邊寫邊思考：我也見很多高手寫**，邏輯很清楚，基本是寫方法名稱剛開始定義的很扯的，比如就x(),他說他自己也不知道他要幹什麼，所以就這麼寫了，等我知道他要幹什麼我就在重新命名了，這樣不會耽誤自己的思路函式名稱的定義基本是google上查查查，如果寫的過程中遇到自己不會的，直接會寫一行漢字標註下，等寫完之後，在看一遍，然後去找解決方法，而不是邊寫邊查，這樣會很糟糕，**的產出太少。除非是一門新語言我必須邊寫邊查。
4. 自己測試
什麼單元測試什麼的，自己基本是在專案裡面，邊寫邊測試了，有的時候會推到第二天，但是一定要測試的，自測很重要。
總結：自己寫的方法，一定要測試才給別人去用，這是做開發的最基本的事情，尤其是介面。其實在第二部去設計了解需求的時候，就已經設計好要輸入什麼引數，只要搬過來用就好了，自己測試，也就無非驗證自己寫的是否正確。
5. 自己**審查
注釋的加進去，你自己的大名，建立的時間，實現什麼功能，以前自己寫**，以前寫**基本是到4就ok了，但是我自從看到同事寫的**之後，發現人家的**簡直就是藝術呀，所以我也就在**塊加#region? #endregion 感覺很清爽。
6. **重構
讀書的時候，聽人家說，乙個方法如果超出70行基本上就該拆幾個方法了，所以最好在去重構下**了。能拆的話在時間允許的情況下，最好去拆下，去優化下。
總結：**重構很永恆的話題吧，關於**重構的看自己的線下功夫了。?
小結如果出現業務的bug，應該反覆走2，3，4這個步驟了，只要按這個步驟走，基本上業務不會出問題了。關於**測試，我不喜歡寫乙個方法就測試乙個，我喜歡全部寫出來，把大的框架搭出來，然後再去做些細節，原因是現在時間真的很緊急。但是乙個功能做完之後，自己必須全部測一下，在接著去做別的。總之，在寫方法之前，你首先的把業務了解清楚，把自己要寫的東西能用自己語言描述清楚，然後再去寫**，我感覺這個方法很適合我。然後在寫**的時候多問問自己一些問題比如：
你的那個方法，如果我輸入空，會出現什麼情況？你的那個方法能寫在伺服器端嗎？（為什麼問這個問題呢？因為我發現很多方法寫在伺服器端的方法，會節省你很多時間）你這個方法能提煉出來，放到公共模組裡面嗎？等等，我現在感覺這種方法很適合我，並且可以讓我的工作效率提高很多。
使用Github的小心得
用的是ssh 整個過程暫時沒有分支 第一次配置成功之後，可以直接轉殖 在github中，建立好倉庫，複製轉殖位址 在本地的電腦裡 git init 初始化倉庫 使用 git clone git github.com cancan519 dailyfresh24.git 這個是複製轉殖位址 進入 轉殖...
用指標形成鏈的小心得
心得 今天晚上寫指標到1點才把問題解決，還是挺高興的，並且還不感覺累，所以我抓緊寫一下今天晚上的心得 1 對某個a指標操作，通過把他賦給另外乙個b指標並且對此b指標的各種操作都對a指標沒有影響，就是不能改變a的任何屬性。3 不放棄。對自己認為自己的方法或想法可以完成的東西，要堅持實現，既可以挑戰自己...
github的一點小心得
很多朋友在github上建立了 倉庫後，急急忙忙的就在本地按照網上的說法，如下 cd dir git init git remote add git add git commit 但是這樣可能就會出現各種蛋疼的問題。最後發現有個更簡單的方法。在github上建立好 倉庫及專案之後，配置好git，然後...