「吃自己的狗糧」 有好幾個層面的含義，
（1）本意是指，一個公司使用自己生產的產品。
（2）對於軟體公司或開發者而言，指的是，使用自己開發的軟體。
（3）此外，還可能是在介紹一種優秀的
編程技巧
。
首先，開發者親自使用自己開發的軟體，這是有好處的，
不然的話，開發者就很難真正看到解決方案的
蹩腳
之處。
功能
怎樣實作
，與已經實作的功能
如何使用
，這是兩種不同的知識。
只有真正用一下自己提供的功能，才能發現它的
難用
之處。
因此，「吃自己的狗糧」 能幫助開發者站在使用者角度考慮問題，
有利於開發者編寫
易學易用
的軟體出來。
其次，為什麽說 「吃自己的狗糧」 是一種編程技巧呢？
這是因為要做到 「能讓自己能吃到狗糧」，會改變軟體的
功能提供方式
。
我們來詳細討論一下這種編程技巧。
平台
在我看來，軟體制品有兩種截然不同的分類，
可以按產品的
終端使用者
來劃分，面向
非
開發者的，與面向
開發者
的。
面向
非
開發者的軟體系統，通常是為了解決特定業務問題的。
軟體在交付之後，所提供的功能一般就確定下來了，
使用者只會使用這個軟體，並不會為這個軟體提供
新功能
。
而面向
開發者
的軟體系統，其出發點就有所不同了，
它除了會提供一些核心的業務功能之外，還會為使用者提供 「編程介面」。
這種軟體最終提供的功能，是該系統的
編寫者
與
使用者
共同實作的。
這種軟體系統的 「編寫者」 與 「使用者」 幾乎是
平權
的，
大家都在同一個舞台上玩耍，一起提供業務功能。
所以，這樣的軟體系統，也常被稱為一個 「平台」。
平台的參與者有三種人，
（1）歸還主動權
平台開發者們，比起一般系統的開發者而言，會更懂得 「吃自己的狗糧」。
這可能是因為平台的使用者群體中，
天然的
就包括他們自己吧。
如果某個功能點，平台使用者可以自己編程解決，
那麽為何不把
主動權
還給使用者呢？
畢竟猜測使用者可能需要什麽功能，還不如讓使用者自己來決定。
所以平台的開發者需要考慮，如何讓使用者自己開發所需的功能。
願意開發，而且容易開發。
（2）尊重使用者
平台的開發者們，也更不喜歡把使用者當成
傻子
，因為他們自己就是使用者。
那種提供 「傻瓜介面」 的建議，最終會坑到他們自己。
所以，「吃自己的狗糧」 會促進開發者們更加的
尊重
使用者。
畢竟提供 「精心設計的」
看似
不用自測的操作方式，還不如把
責任
交還回給使用者，
讓他們
自己
為行為負責。
這是因為復雜邏輯的
正確性
，很難使用
通用方法
進行驗證。
讓使用者意識到任何新功能的釋出，都是需要驗證的，是一種很好的軟體素養。
核心
在第五篇文章中，我們提到了
擴充套件性
，介紹了 「適當可延伸」 的編程技巧。
要做到 「適當」 需要我們擯棄 「奇技淫巧」，回歸 「大智若愚」。
少發明新的概念，多用樸實無華的程式碼表達想法，
少在程式碼中體現還未證實的假設，想到了不代表要寫到程式碼裏面去。
「吃自己的狗糧」 也需要做到 「適當」。
軟體系統是否要做成一個 「平台」，要視
業務需要
而定。
當然系統開發者，可以有編寫一個平台的
野心
，但未必需要在程式碼中體現出來。
（1）平權
上文我們說 「平台的編寫者」 與 「平台使用者」 是 「平權」 的。
其實權力並非完全等同。
這裏所說的 「平權」 主要體現在以下兩個方面。
（1）平台使用者，比起一般系統的使用者而言，可以為系統貢獻新功能。
（2）平台的編寫者，也能以平台使用者的身份提供功能。
其中第一點，平台賦予了使用者更高的許可權，
第二點，平台在某種情況下，可以視編寫者為普通使用者。
於是這裏就出現了一個需要
權衡
的點，
狗糧有很多，哪些是自己要吃的？
盲目把所有狗糧都吃了，其實反而是有問題的。
（2）功能
要想回答上面的問題，還是得站在
使用者的角度
考慮問題，
也就是回到了 「吃自己狗糧」 的原始目的。
值得一提的是，使用者在任何時刻，需要的都是
功能
，
而不是自己編寫功能的
能力
。
實在沒有辦法的話，才接受自己動手。
因此，
功能 > 自己動手 > 自己無法動手
。
所以不論我們提供多麽優雅的 「編程介面」，都不如直接給使用者提供他想要的功能。
同時，如果實在無法提供功能，那麽最好讓使用者可以自己動手。
這才是 「吃狗糧」 的最佳姿勢。
結語
「吃自己的狗糧」 是一個很寬泛的概念，可以適用於很多行業，
就算聚焦到軟體開發來看，也並非只適用於 「平台開發」 這一狹小的領域。
本文只是借著 「平台開發者」 為引子，介紹了 「吃狗糧」 的幾個常用姿勢。
總而言之，「吃自己的狗糧」 代表了一種以使用者為中心的工作態度，
使用者到底需要什麽？我們真的理解使用者需求了嗎？
畢竟，只有使用者贏了我們才會贏，
不聽使用者的心聲，私自做主，是編程之大忌呀。
