前言
爲啥要寫這個呢，因爲寫程序也7-8年了，有一些感悟，想寫下來，雖然這個命題有點大，但是呢，我覺得並不誇張，下面進入正題。
-
打好基礎
- 其實就是學東西不管學什麼基礎纔是重要的，比如寫程序有的人會說能用就行，可是我覺得不思考，只是堆積代碼雖然能用，但是複用性有多少，如果真的賣出去產品了，一下來了是個項目，你不得忙死嗎？
- 基礎的概念不是看書背八股文，得能知道它的底層是什麼，上層是什麼，能幹什麼，這纔是基礎打好了，不然只會讀書那不是書呆子嗎，這也是目前學校的應試教育。
- 基礎其實挺難的，因爲是一環扣一環的，比如學java你會遇到很多不理解的，你會去想底層是怎麼實現的是怎麼優化的，比如java裏邊的很多算法，如果不去學算法你是看不懂的，這樣就會促使你去學算法基礎，比如jvm的執行，編譯的class你如果不會彙編很難理解寫的是什麼，這個會促使你去學彙編基礎，這樣學下來其實基礎挺多的。
- 基礎變化小，收益比高，可是很多人都是急功近利，只學上層的api調用，導致出個框架就學一個星期，這樣很浪費時間，比如前端vue，react，angular，如果你js、html、css精通，這些東西很好就能學會，而且出問題一下就能搞懂，如果基礎不牢固，出了問題只會推給框架，這樣下個框架依舊如此，這樣會慢慢淪落爲碼農。
-
理論和實踐結合
- 學東西不能只看書看理論，也不能只實踐不看理論基礎，我舉2個例子吧，第一個例子，如果只理論不時間，那麼你將會不知道你學的東西是怎麼在生產項目上用的，比如lru算法，你只理論就只能明白，這是一種算法，如果生產上存儲數據到達上限後這種算法會保留你經常使用的數據，這就是實踐，而且不實踐很快就會忘掉理論知識，因爲腦海裏沒這個畫面，又比如raft一致性算法，如果你只是看理論估計很難看明白，看看redis等這種集羣部署數據一致性同步會讓你理解爲什麼需要這種算法作爲集羣種節點的數據同步和一致性校驗。第二個例子，如果只實踐不注重理論，你會考慮不周，因爲你不會明白還有什麼可能的情況，就那個機端例子吧，小t說我要做個壓縮算法，無限壓縮，他的意思是能無限次數壓縮，壓縮1m最後能壓縮爲1k，如果有理論依據，他就會明白有壓縮因子的概念，不能無限壓縮，理論不支持，類似的永動機概念。
-
減少複雜度
- 寫代碼還是做設計一定是減少複雜度的，如果複雜度無限膨脹，那麼這個產品也會告一段落走向滅亡，不是說不能複雜，複雜是樹狀的，一個大需要分若干個小需求，一個大功能分若干個小功能，只不過最終的實現目標要一致，這裏我想說我對設計模式的理解，設計模式不能濫用，如果你是個很簡單的事，那麼你完全不需要用設計模式，設計模式不是讓東西更簡單，反而是讓東西更復雜，只不過複雜的有序，也就是說有章法，比如很龐大的一個設計一定是得有設計模式的，不然很多東西1是不能複用，2是無章法的亂，這也就不用維護了，等重寫吧。
- 減少複雜度的另一個是少依賴外部，比如就寫個個人博客，你用上各種消息隊列、緩存、反向代理、集羣部署，這完全沒必要，直接一個數據庫搞定，除非你業務量很大了，可以一點點增加設計的複雜度，這種複雜度是無法避免的，因爲業務量大必須設計複雜一些支持這些流量。
-
每次多想一點
- 做東西前多想想，不是說做完就完事了，如果抱有這種太多，大多數會返工，因爲需求一般不會給到很明確，這樣就得你自己反覆去碰需求，想的多了，自然會挖掘出更深層次的東西，把考慮不周的地方避免掉，如果設計的設計好，在研發的時候不太明白返工只會返一點，如果測試完了到現場，那麼消耗的時間就會浪費很多改這個bug，如果設計的不好，設計返工，這個時候如果到了現場，可能就是災難，因爲沒法改，只能到下個版本重新設計。