反思： 為什麼我連普通的程式都寫不好？

        在不完美的世界裡聰明地匍匐前行， 是每一個程式員應該懂得的第一件事。           ------  引           

        從開始正式學習和使用Java語言起（不計之前學C的時間）到如今，約也有3年時間； 其間寫過簡單的增刪查改的功能，也曾深入源碼去鑽研一件事情的工作原理， 讀過不少軟體開發的好書， 《編程珠璣》，《程式設計實踐》， 《深入理解電腦系統》， 《從小工到專家》 等， 瞭解過多種程式設計語言，自認為還是有一點悟性的， 但是， 總感覺自己連普通的程式都寫不好。這裡， 普通的程式指的是使用現有的組件、架構等構造軟體，編寫商務邏輯代碼。
為什麼會這樣呢？ 

       未能知其所以然 ？

       太依靠“悟性”，沒有更深入到事物的核心和工作原理，總是停留在膚淺的認識層次上； 不求甚解，淺嘗輒止。讀了不少書，但嘗試太少， 消化比重太低。

       依靠直覺、文檔說明和抽象機制使用組件和架構，而沒有深入理解其內部實現， 在一知半解的基礎上寫程式， 雖然在初期能夠快速構建 “It works”的程式，但實際上知之甚少。 類似於“建造空中樓閣”， 缺乏堅實的基礎支撐。

     
 解決方案：  在概覽全景之後， 將開發過程中積累的所有含糊不清的地方各個擊破， 使所學及所用的關節打通，形成牢固的知識技能體系。 

       缺乏足夠的挑戰性？

       所編寫的程式大多接近於業務應用程式層， 沒有太多深入到電腦核心的東西。

       解決方案： 其實，把一件普通的事情做到非常出色，就是一件很了不起的事情。“偉大”
的程式並不是自身有什麼偉大之處，而正是組合了許多平凡普通的程式而出色完成了它應該做到的事情。業務層開發也會遇到一些很有挑戰性的問題， 不要迴避，儘力去解決。 做好該做的事情， 你將贏得榮譽。

       沒有拿得出手的程式 ？ 

       看到別人寫出了有影響力的程式或軟體，而自己至今尚沒有拿得出手的東西； 所寫程式的影響力局限在較小的範圍內，未能獲得廣泛的使用，缺乏驅動力和激勵。

       解決方案：  你只是沒有寫出有實際用途的程式。 敏於去發現不足， 努力去改進， 總會寫出令自己自豪的程式。 不一定要拿出很重量級的項目或應用。 即使一個小程式， 或許都可以做出很有益的事情。同時， 要儘可能開放給別人使用， 接納別人的建議和改進。

       想要一蹴而就 ？

       很顯然， 好的程式總是經過時間的打磨而成，而不是一次性就寫得很好。 先寫出基本可用的程式，然後逐步求精。 同時也要閱讀優秀原始碼， 擴充自己的見識。

       苛求程式品質卻又測試怠惰？

       儘管儘力遵循良好的編程規範和風格， 總覺得代碼效能不太好，潛藏BUG， 但又看不出。希望能夠寫出效能良好、可靠性、穩定性、健壯性好、可維護性佳，易用性良好的程式， 但又非一朝一夕之功。

     
 解決方案： 這是因為缺乏良好測試導致的對自己所寫代碼不自信的現象。 學習一些測試技能， 系統、嚴格地測試自己的程式， 最終獲得代碼的自信。 覺得代碼效能不太好？ 拿出實際資料和手段來， 不要憑感覺做事。 

       思維不嚴謹 ？

       不得不說，程式開發是對嚴謹邏輯思維的有力考驗。如果思維不嚴謹， 很容易寫出表面上能夠工作實際上很容易失敗的潛藏很多BUG的程式。 該如何提高思維的嚴謹性呢 ？  

       解決方案： 多多研習演算法，應該是一條不錯的途徑。此外， 訓練自己縝密、周密思考問題的能力。         

      期望過於理想的狀態？

      希望能夠儘可能借鑒現有的成熟方案， 做出一致、優雅的整體解決方案。

      解決方案： 持續改進和進步。

       程式開發的興趣不濃？

       處於那種不驚不淡的程度吧， 畢竟， “It works” 已經不足以讓人興奮了；  期望能夠寫出優質易用的程式，也許追求更高的開發目標削減了開發的興趣和樂趣。

     
 解決方案： 可能缺乏有力的外界激勵， 比如說參與到一項非常有創新性的產品開發中， 或者有重大物質獎勵。 適時尋求轉向。

      開發方法和流程不規範 ？

      有時候， 過於隨意的開發方法和流程， 以及過於鬆散的工作計劃， 會削減自己的效率、積極性和創造力； 此外， 單掌難鳴， 有影響力的產品通常是由多人協作合力完成， 濃厚開放的團隊討論氛圍有利於開發活動的順暢進行。

      解決方案： 先制訂相對合理的開發工作單位與工作計劃， 再投入工作；  逐漸建立起適合自己的有效開發流程與工作方法。 

       代碼品質實際上是一個現象和結果。背後的原因可能有很多： 思維不嚴謹， 考慮問題不周到， 壞的編程習慣， 項目進度壓力， 粗心， 缺乏足夠的測試， 缺乏足夠的驅動力和激勵，對事物的深入理解不夠， 心態問題等。要從問題的源頭處改進，而不是從現象上出現一個解決一個。  

       重溫下 《Unix/Linux 的設計思想》 ，上面有段話吸引了我：

       一個偉大的程式，如果滿足條件： （1） 它必須滿足實際需要； （2） 周圍不存在任何瞭解該如何編寫此程式的“專家”； （3） 沒有足夠時間“完美”完成任務。

       第一點是最必要的卻常常做的不充分或過猶不及； 第二三點則說明， 其實不存在很理想的狀態，沒有充足的時間用來思考一個非常優雅的解決方案， 也不一定有現成的成熟方案。

      畢竟，一個程式就只是一個程式而已。做好該做的事情，逐步變得更好。 至於是否偉大， 究竟做了什麼， 可能只是外在的表現和光環而已。踏踏實實鑽研， 踏踏實實寫好能做好事的程式，做有趣事情的程式， 精益求精但不過分苛求。 懂得享受一下生活日子， 這不挺好嗎 ？