直到我做了底層開發，我才知道不寫業務程式碼有多爽

寫業務程式碼，可能每天大部分時間調別人的接口，接口不合適封裝個函數，需求也不斷變動。

總歸實作功能最重要，使用者體驗最重要，別人提需求，你只管實作。

你就像無情的機器，寫重複的業務程式碼，實現相似的功能，感覺沒長進，眼界也沒提升... ...

但驅動開發截然不同...

#行不行，你說了算

業務程式碼，最多的就是需求變動。

例如，這個模組再加個功能，這個程式碼再封裝一下，你這樣寫不行要這樣寫......

但是，對於一個驅動來說，它能用就是能用，不能用就是不能用，沒有太多的需求可言。

例如一個網卡驅動，它能正常連接網絡，能正常傳輸文件就是它的功能，代碼怎麼寫是根據芯片手冊來的，沒人會對你提什麼需求。

所以，沒有需求的煩惱。只要能用，你的任務就完成了，不會有什麼需求過來，最多就是改一下bug。

除了你，一般人不敢動你的程式碼

#為什麼不敢動？

驅動程式碼不像應用程式層寫的業務邏輯，業務程式碼可能更多的是一些程式設計技巧、程式碼最佳化上的東西，例如介面封裝、參數判斷、特殊狀況處理等一些偏軟體設計上的東西，如果看到某段業務邏輯寫的不好，有些經驗的人都是比較容易去改你的程式碼的。

但寫驅動程式碼有一個最大特點，就是先把晶片手冊看懂。

例如驅動程式里分配了一個64位元組對齊的記憶體、調度前又設定了一遍暫存器，為什麼要這麼做？你是不知道的。

如果別人覺得你的驅動有問題，想改你的程式碼，那他應該先把晶片手冊看懂。

沒看過晶片手冊之前，這個程式碼他沒法動，這個名詞、這個位元是什麼意思，程式碼為什麼這麼寫，只有你才知道。

即使是驅動真有問題，也一定是你自己改，因為一般人不會閒著沒事去看不屬於他工作範圍的文檔，況且把文檔看懂都要好幾天。

即使是很小的錯誤，通常也是你自己改，因為別人不知道改了這個地方，會不會影響其他地方，只有寫這個驅動的人才知道。

所以只要驅動能正常用，就不太會有人去動它了。

我告訴你我有什麼功能，

而不是你來告訴我你想要什麼功能

如果是業務代碼，通常都是需求牽著你走，一切為了使用者體驗。

但驅動程式碼相反，我只會告訴你，我有什麼功能，而不是你來告訴我，你要什麼功能。

一個驅動，它的功能就只有這些，只能少不能多，我可以告訴你這個驅動有這些功能，你想要什麼樣的接口，我可以提供ioctl介面或其他介面給你呼叫。

如果你說你要傳一個參數，把xxx回傳給你，我也有可能跟你說，做不到。如果你說你要同時傳一些參數，把xxx同時回，我只會告訴你做不到。

你問為什麼？因為這個硬體本身就做不到這樣的效果。 如果你不信，那你去把晶片手冊看一遍吧，看懂再來問我。

以上是直到我做了底層開發，我才知道不寫業務程式碼有多爽的詳細內容。更多資訊請關注PHP中文網其他相關文章！