這段時間的開發總是在自己給自己挖坑，進入了乙個創造bug登峰造極的階段，前兩天看了一篇類似雞湯的東西並不是任何解決bug的過程都能成長，解決自己給自己埋下的邏輯性bug，除了能讓你意識到自己有多二之外麼有任何效應。為什麼你有10年經驗，但成不了專家
上面提到了刻意練習度的問題，很有道理，前提是你要進入「自動狀態」，簡而言之就是下意識的去做出反應，但是就像有人說的，你的努力程度還到不了跟別人拼天賦的地步，還沒有到「自動狀態」的程度，所以特此在這裡反思一下，如何避免挖坑跳低階情況發生。
如果這樣計算，做乙個功能需要2個小時，然後在這兩小時裡面你埋下了3個坑，然後花費3個小時或者更長時間來解決這些並不容易發覺的問題（通常這些坑不是你故意造成的，所以你會覺得，對呀~就是這樣啊~沒毛病啊~怎麼回事呀~我靠？~）那麼乙個功能花費的時間就是5個小時，基本一天什麼也幹不了了。知道了他的危害，就要想辦法繞開它。
當乙個功能涉及到其他邊邊角角太多的時候，千萬別貿然就按照自己的想法去做，同樣，當這個功能出現bug的時候，也千萬別貿然就去改正，也別貿然相信自己的記憶力和別人的記憶力。把能影響到的功能都寫到紙上吧，但是還不夠，還要把你做的每一步的操作影響到了誰，會產生怎樣的結果預判出來，而解決這種情況的最終方法還是要有乙個好的架構。
我想這種問題應該可以把自己當做乙個使用者，乙個學前班就留級，小學上到一半就跟不上輟學在家的使用者。然後像想一萬種操作情況，甚至你都要考慮到使用者沒有四肢，而是用舌頭舔螢幕操作的，最後找到一條相對相容所有情況的方案。
在這裡我想向一位同事學習，如果他說完一句話，有人笑了，他會問為什麼，如果你覺得沒有什麼可說的，就是乙個自娛自樂，沒有必要告訴他，ok，那麼這件早上發生的事，他會早中午吃飯的時候繼續追問。起初我覺得這簡直不可理喻，但是時間長了我發現，這種心態太難的了……他會想出各種刁鑽刻薄的情況，以至於他寫的東西一直都比較完善。總而言之，就是要有打破砂鍋問到底的感覺。
這個就不多說了，瞪眼兒抓瞎，干巴兒著急，倆人兒掐架，技不如人，死於馬下，不服不行。只能學了。但是栽到這種地方是對你有幫助的。
暴風雨來臨的前夜總是平靜的，bug亦然，一段程式只有兩種情況會出現bug，一種是簡單到一眼看不出來bug，一種是複雜到根本看不出bug。
但這兩種情況有乙個共同點，就是設計初期就錯了，而後者更嚴重的是，在**結構上也有問題，這就意味著隨著功能不斷增加，他會變成一灘你再也不想靠近的爛泥。
首先這體現了**設計初期是多麼重要，這個前面說過了，其次就是良好的編碼習慣了，這個說著簡單，做起來也不難，其實就是一些標準規範和平常培養習慣的問題了。
在有就是，不要總想著差不多，要想著沒問題。在思考問題不夠全面的那一小段的開頭，我用到了，「我想應該可以」這樣不確定到死的字首，這就注定了我製造bug的命運……
未完待續，豆芽再高還是個菜，繼續完善，繼續學習吧……
Linux程式設計中如何避免出現殭屍程序
比如程序採用exit 退出的時候，作業系統會進行一些列的處理工作，包括關閉開啟的檔案描述符 占用的記憶體等等，但是，作業系統也會為該程序保留少量的資訊，以供父程序使用。例如程序的id號 程序的退出狀態 程序執行的cpu時間等，因而占用了系統的資源。在一種極端的情況下，檔殭屍程序過多的時候，占用了大量...
程式設計中遇到的小bug
1.1空棧不能取頂。if stack.top stack.size 0 如果棧本身為空，這裡if中首先取棧頂，就會導致段錯誤 sigse segment fault 2.1字串定義的時候要申請空間，在沒申請空間 初始化 的情況下直接用下標訪問某處字元並不會儲存到字串中，其實那個地方仍舊是字串結束符 ...
如何避免TreeView中Checked事件死迴圈
在treeview的aftercheck事件中新增處理 設定其它相關treenode的checked屬性。問題 通過 改變treenode.checked屬性同樣會觸發treeview.aftercheck事件。若節點a的狀態改變時需要自動改變節點b的選中狀態，且節點b的狀態改變時也需要自動改變節點...