每天最多的時間對著電腦鼓搗著程式，或因為乙個問題不能解決而絞盡腦汁苦苦思索，或因為有了點小小的成果而沾沾自喜興奮異常。 ----《瘋狂的程式設計師》
軟體開發是乙個善於思考的職業，寫程式都是要經過需求分析、設計、編碼還有測試執行的。所以我在寫程式的時候自然而然的就形成了一些壞毛病，例如：唯我獨尊，不願測試，不喜歡別人說自己程式爛等等。
而事實告訴我，我太把自己當回事了。
最近的最近給學校在做乙個關於綜合測評的bs專案，專案實現是非常容易的，但是在專案幾近結束的時候發現了乙個bug。
這個bug讓我好幾天都沒有睡好覺，每天腦子中都在想是什麼導致這個問題出現，怎樣才能解決這個問題。
不過還好，經過了幾天的痛苦折磨，在乙個夜黑風高的深夜，我終於把它給解決了。
經過這次問題，我更加深刻的認識到自己在寫程式上出現的一些問題，並且總結出來一些思想，今天把這些問題和思想分享給大家，和大家交流溝通，共同努力。
無風不起浪，你別把自己當個藝術家我設計的**是否非常糟糕，從我一敲擊鍵盤就能察覺到。把乙個方法或函式寫上成千上萬行，那最後不想承受洪水衝擊都不行；我把所有的變數都寫成i，j，k那麼過一段時間之後它認識我，我卻不認識它了；我不把注釋寫好，我還想奢望讓團隊的每個人都理解我的**？可能他們到最後連我本人都不想理解了。
無風不起浪，要想風平浪靜，就要運籌帷幄。讓自己強大起來，做好運籌帷幄的事情。
我不是什麼藝術家，我也沒有那麼高尚，我寫出來的**是非常爛的，沒有必要把自己奉為神明，唯我獨尊，東方不敗的樣zhi。自己寫出來了**，不去檢查，不去除錯，那自己做這個高尚的職業又有啥意義呢？
時刻告誡自己，我不是藝術家。
不注重前戲，後果很嚴重前戲很重要，需求分析和設計是要要求我們對整個系統的結構和邏輯都有很清楚的理解。需求要到位，這是專案的根基，如果根基沒有了，那麼大樓是無從談起的。文件和架構uml都要明確清晰明了，如果這些不明了，那麼交流是專案進行中的乙個阻礙。前戲階段思路清晰非常非常重要，否則會一亂到底，亂上加亂。後果不堪設想。
所以前戲非常重要，為了避免出現意想不到的結果，還是要好好的把前戲做好。
勿以善小而不為，勿以惡小而為之像剛才說到的無風不起浪，我們專案中會出現諸多bug，是什麼原因呢？可能有很多，有些是技術上的，有些是非技術上的。
所以在這裡要好好的說說這個**編寫。
1. **的編寫，要儘量減少拼寫的錯誤，嚴禁使用關鍵字作為變數來使用，要盡量做到**模組化，並且保證其正確性和可重複使用性
2. 函式別寫太長，功能越單一越好。函式寫那麼長幹哈，又不是寫**，想讓看程式的人累死，也想讓debug的自己愁死，有木有啊！
3. 縮排要合理，當debug的時候會感受到這條帶來的好處。
4. 要做**檢查工作，你不要寫一萬行**再進行除錯，這樣增加了排錯的難度。如果你把一萬換成四五行，你想你的排錯是不是更加容易。
5. 命名是非常有學問的事情，我一剛寫程式的時候，一寫變數除了i就是j要不就是k。當然我也遇到過這樣尷尬的情況--寫了一段**過了一段時間後，我反問我自己，這是我寫的程式嗎，丫的，那個i是表示的什麼變數呀！
6. 注釋。做好注釋不僅讓自己在debug階段更加方便而且還會讓團隊開發更加和諧，也會讓**更加具有親和力。
所以編碼的規範性是非常重要的，勿以善小而不為，勿以惡小而為之。
遞迴分支的思想求最近對問題
遞迴分支的思想求最近對問題 public class closestpair else return start 65535 當有乙個點的時候設他的距離為無限大 public static void main string args point是自定義類 string res closestpair...
找最近的素數會出現問題
問題 描述 現在給出你一些數，要求你寫出乙個程式，輸出這些整數相鄰最近的素數，並輸出其相距長度。如果左右有等距離長度素數，則輸出左側的值及相應距離。如果輸入的整數本身就是素數，則輸出該素數本身，距離輸出0 輸入第一行給出測試資料組數n 0 include using namespace std bo...
cmake專案所出現的問題
問題1 cmake專案時，出現了opencv dir not found 的錯誤 採取的是手動新增路徑d open cv opencv2 49 build的方法，之後生成成功 問題2 camke的專案，應該是將原始檔的路徑新增到cmake中，而不是複製乙份原始檔。所以，如果修改原始檔，或者cmake...