講道理，編程到底該學些什麼？

05-03

在知乎上，有一種趨勢，似乎一旦涉及到編程學習的問題，大家都似乎很喜歡本質論。當然基礎是重要，畢竟萬丈高樓平地起，但是不是學習框架就是那麼不堪？程序員是不是數學，演算法不好就一輩子搬磚的碼農？這其實是一個值得思考的問題。

計算機的技術日新月異，使用已經造好的輪子已經是實施標準了，但這並不代表著我們無需學習細節，成為API工人，但同時我們也必須承認，單純的學習計算機理論知識是枯燥的，甚至在沒有一定的實踐經驗，難以明白這些理論知識的精華所在。

首先需要肯定的一點，對API死記硬背肯定是不可取的，專門抽時間出來看api的應用也是不可取的（為了弄清背後的原理而做實驗除外），更多時候api應該是即查即用。當面對一個成熟的框架我個人的經驗是學習框架的結構和對問題的解決思路。很多時候，我們都認為深入學習一個框架就是讀懂它的源代碼，固然讀懂他的代碼也會收益良多，但試問誰有這個時間和精力，而且即使是有這個時間精力，一個成熟的框架的代碼已經非常的複雜，即使有專業的工具，也不一定能輕易解決。但框架的結構和其對問題的解決思路是相對容易獲得的，而且也是最容易在寫別的代碼時借鑒的。

遇上一個框架，首先要明白它是針對什麼問題的封裝，當然這已經是一個最基本的條件了。其次一個大問題必然有一些常見的小問題，這些小問題該框架是用常用的方式來處理的嗎？如果不是，那麼為什麼要按照這個新的方式來處理呢？是僅僅為了使用者方便嗎？還是在技術上結合整體做了取捨？這個框架的特點是否適合用上當前業務？，多一點思考，多一點對比，自然會比api工程師們有所不同。

編程難在哪裡？語言？框架？有一定工齡的工程師哪個不會幾種語言幾種框架，其實和其他工科類似，編程難的是在現實生產環境進行諸多的選擇，給出一個合適可行的一整套方案，這個方案包括生產，上線，維護等一系列操作。

僅僅是分享一些最近的學習心得，有不對的地方多多指教。