這是一個項目中的一個案例，在提測的過程中竟然發現主功能有嚴重的bug。這樣的bug被測試發現確實非常慚愧，我把自己罵了好幾遍。可能每個人都會爲自己辯解，誰寫代碼沒有問題。但是我在這裏說一下我自己的體會：一般來講寫代碼“一遍率（PS：整個邏輯盲寫，不做測試）”比較高的同學往往自信心比較高，因爲他對自己的代碼有信心。而經常寫出來代碼有問題的程序員可能會心虛，即使你後面不管是自測還是靠測試把問題測出來，測出的bug越多，對於自己的打擊越大。特別是一些嚴重依賴於開發質量的項目，這樣會承受比較大的心理壓力。後果是什麼？有一點小的改動就會畏首畏尾，不敢改。但是真正要做到細緻，以我個人的體會來看，確實很難。
另外一個就是千萬在寫代碼之前把整個的邏輯細細的想清楚，磨刀不誤砍柴工，真理。因爲前期沒做好的後果就是後面一直在改代碼。這樣浪費了更多的時間。其實這是一種思維的轉變，很多人也包括我也認同一種觀點：代碼是寫出來的，即使前期想的再清楚，也會有遺漏。但是在工作中這是一種不太好的實踐。要慢慢的學會在前期做更多的工作，後期少的改動。這是一種功力，真的很考驗人。對於已經習慣這種思維的人可能不太難。但是如果習慣了在寫代碼中思考的程序員來說一定要力求改變，在這裏也是在警告我自己。
這裏簡單的說一下爲什麼？道理很簡單，如果你是在寫代碼的時候進行思考說明是你喜歡發現問題解決問題的方式，這是一種被動的思維方式。這種思維方式可能做一個程序員不會犯太大的錯誤，至多自己多加一些班。但是如果是一個項目的owner，這樣極有可能犯重大錯誤，整個項目到後期發現方案不可行，這是要命的。千萬不要覺得這緊緊是一種工作方式的問題，這是思維方式的問題。要慢慢的鍛鍊自己在前期思維能力，就是主動思考，主動發現問題，這樣纔可能把項目風險掌握在自己的手中。項目實踐有一句話：“有可能發生但是沒有發生的問題叫風險，如果問題已經發生，那就是真的問題”。
改變思維方式真的很難，要打破重來很痛苦，絕不會在我這裏寫出來這麼簡單，所以爲什麼我覺得成功學看的熱血沸騰，發現自己一去做完全是兩回事。一個簡單的習慣都很難改變，何況是對於一種已經幾十年的思維習慣。這裏我舉一種思維實踐，僅供參考。腦子裏想一個問題，反覆的想，把它想的非常透徹，然後把這個問題拋出來，看看大家都對這個問題的看法，再比對自己有哪些遺漏。這一方面是思維的過程，另一方面也算是經驗積累的過程。因爲很多問題想多了考慮的面自然就會豐富起來。