1.編程也分腦力工作和體力工作。

而敲代碼之前的設計過程就是一個腦力工作的過程。設計的時候需要考慮類與類的關系，每個類的責任，用什么樣的命名來描述這個責任。還要考慮類提供什么樣的方法，每個方法承擔什么責任，以及怎么命名，傳什么樣的參數。還要考慮怎么實現起來方便。

設計是一個從無到有的過程。這時候需要安靜，大腦需要調用很多無關的知識，把這些無關的知識連接起來。需要把一個業務拆分成自己小功能，讓后在把這些小功能抽象成一個名詞，再看這些小功能有沒有重復的，是不是承擔了過多的責任，是不是責任劃分不清，是不是有重復的責任等等。

而實現的過程就是一個體力勞動的過程，這時候我會戴上耳機聽著愉快的音樂，敲打著鍵盤上的每一個字母。

這是我對編程的一點簡單看法，不一定對。

2.設計模式主要是用來明確分工的。以前我不理解，一個功能幾個方法就實現了，那些設計模式要把一個功能分成幾個不同類去實現。在我看來這只有那些邏輯思維能力不足，擔心自己把自己搞迷糊的人才會去使用設計模式（其實，也有這樣的功能）。

直到有一天，我給幾個同事分配任務的時候，突然明白，原來設計模式有明確分工的功能。那次是要實現一個遠程調用其他廠商接口的功能。我們需要把我們的數據轉換成他們可以識別的數據，傳給他們，然后再把他們返回的數據轉換成我們可以使用的數據。大概有三十多種不同的接口。

我們使用了策略模式。抽象類有三個抽象方法，一個是把我們的數據轉換成廠商的數據，一個是把廠商的數據轉換成我們的，另個是需要調用的接口名。實現者只需要知道當前子類對應的廠商需要的數據格式和返回的數據格式，以及對應的接口名稱，不需要知道其他的東西，這樣會減少實現者的認知負擔。而且子類與子類之間是相互獨立的，可以同時交個多個同事完成。當然我們也會提供一些通用的轉換方法。

而另一個同事拿著這個抽象類實現對廠商的接口調用，他不用管抽象類是如何實現的，只需要知道如何調用接口就行，也會減少這個同事的認知負擔。還有他跟那些子類的實現也是相互獨立的，可以讓另一個同事同時實現。

這是我對設計模式的一點簡單看法，不一定對。

3.最近在學習人工智能。有一點看法：

第一，學習人工智能跟學習一門新的編程語言一樣，入門很容易。現在有很多人工智能框架TensorFlow，Sklearn等，都提供很多算法的實現。對于我們這種數學不靈光的人來說，只要了解算法原理，了解框架都提供了那些人工智能算法的API就行，不需要知道內部如何實現，也可以在自己的項目中使用人工智能。

第二，目前人工智能很笨，只是因為計算機比人運算速度快幾百倍，才顯得它很聰明，現在根本不用擔心它會超越人類。給什么樣數據得出什么樣的結果。跟普通編程一樣，不會做出意料之外的事情，如果出現了，只能說明是自己沒有理解到位。

這是我對人工智能的一點簡單看法，不一定對。

無戒365挑戰營 第10天