// 程序爲什麼會有bug -- 思考的不全面
最近在做UVA的題目的時候，一個問題一直困擾我無數次：WA來的太多了。
寫程序的過程是美好的，而且一般很快，一個100行以內的code應該不會超過半個小時就能寫完;但debug的過程着實痛苦：拿到WA之後，隨便就是幾個小時的debug。
爲什麼不能一次做好呢？
因爲思考地不夠全面，就開始動手寫代碼了。換句話說，對體系還沒有足夠清晰的認識和了解。
// School of Application / School of Theory
現在的還在不斷進步的Programmer可以分成兩類吧：實踐派和學院派。實踐派的，講究遇到問題，解決問題;講究的是尋找對於一個問題快速高效的解決方案——所以很多時候解決問題的過程是：google，找到了一個solutoin，(try&error) -> Works? use it: find anotehr.
加入剛好找到了一個合適的解決方案，用了就沒問題了;但有些時候，如果你遇到的問題有一點點特殊，那麼時間就要花在無盡的Google、try&error的過程中;更加嚴峻的問題是，假設之後問題出現了一個變體，你就需要重新去搜索一遍（因爲經驗性的記憶總是不如全面瞭解來得正確）。
另外一種人是講究讀書的。他們只做自己有把握的事情，所以他們對於自己做出來的產品、寫出來的code有信心——因爲他們知道內部所有的來龍去脈。之後出了問題，他們可以迅速的找到原因。
但是這需要極高的前期知識投入和知識儲備。
但這類人每解決一個新的問題，都是對於自己知識儲備的一次重新完善。
// 《The Pragmatic Programmer》 -- coding by coincidence
在《THe Pragmatic Programmer》裏面，有一章講如何coding，其中一個topic就是“Coding by Coincidence”——在自己不瞭解內部結構的前提下就開始coding，於是在出現問題的時候，自己也不能判斷是哪裏的問題——所以你只能一點點試錯。
時間長了你會發現。兩種人在解決同一個問題上花了差不多的時間;但第一種人把時間用在了找東西上面，而第二種人把東西用在了積極思考]學習新內容上面。高下立辨。
// 該有的好習慣：提前寫好code，列在一張紙上面。
我們時間有限。應該把有限的時間放在有價值的事情上面——積極的思考，而不是消極的找原因。與其花30min寫程序，2h debug，爲什麼不花50min一次就把程序寫對呢？
怎麼寫對？在對於你用的component有了解之後，拿來一張紙，一支筆，寫下算法的步驟，寫下基本的算法證明。然後實現。即使你的算法證明是錯的，你在debug的時候，也是一個“positive thinking”的過程——時間久了你自然會進步的。
人家講，Knuth在最初寫Latex的時候，是先寫在了一個本子上的;後來把代碼輸入進計算機，直接就能運行的。