date: 2019-09-29 23:58:16
title: hyperf| hyperf 編程入門小結(jié) 1
最近在帶組內(nèi)的新人基于 hyperf 項目進行開發(fā), 目標(biāo)是構(gòu)建一整套 PHP 微服務(wù)的體系. 千里之行始于足下, 這里先 mark 一下一些基礎(chǔ)的編程注意事項
hyperf 編程注意事項
禁止項
-
$path = $_SERVER['HTTP_REFERER'];不可以使用超全局變量, swoole server 是常駐進程 epoll 方式處理請求, 不是 fpm 依靠多進程一對一處理請求
配置管理 config
- 所有配置都在 config 文件中, 項目中只使用 config() 就可以獲取配置
- .env 只寫環(huán)境相關(guān)配置, 最后都需要使用 env() 配置到 config 文件中, env() 只允許在 config 文件中使用
容器 container
- 盡量使用框架提供的功能, 這樣才能發(fā)揮出 container 的效果
- 手動 new 的對象, 沒有交給 container 管理, 無法使用框架提供的注解功能, 比如
@Inject
協(xié)程 go/coroutine
- 使用協(xié)程有2個必須條件: 開協(xié)程
go() + callback 中執(zhí)行非阻塞代碼 - 常用的庫都提供了非阻塞調(diào)用: mysql(基于laravel ORM + 連接池), redis(ext-redis + 連接池), http(guzzle clientFactory)
http client
- http 請求這樣的功能很常見, 幾乎所有的項目都會自己的封裝, 但是要使用 hyperf 提供的
hyperf/guzzle, 才能實現(xiàn)非阻塞調(diào)用 - 項目自己封裝的 http 請求庫, 基本可以斷定沒有
guzzle/http好用
基于 hyperf 的封裝
基于 hyperf 的封裝 務(wù)必 要考慮 反哺 社區(qū), 有以下幾點:
- hyperf 的迭代速度, 包括功能支持上, 速度有目共睹, 所謂的封裝, 也許就在下次發(fā)版支持了
- hyperf 的代碼提交以及整個社區(qū)共建, 保證了代碼風(fēng)格和相當(dāng)高的
代碼質(zhì)量 -
反哺社區(qū)也是依賴解決的最優(yōu)解之一 - 最后再來一句靈魂拷問:
自己再封裝一層真的有必要么?
建議項:
- 大段注釋的代碼基本建議刪掉, 哪怕真的有需要, 也可以從 git log 里找回, 我認為這是
clean code的要求之一 - 不建議使用常量, hyperf 只設(shè)置了一個常量
BASE_PATH, 使用常量通常是沒想好要怎么放, 建議多看看 hyperf 的組件設(shè)計
Unix哲學(xué)（Unix編程藝術(shù)）
- Doug Mcilroy:
1.讓每個程序就做好一件事。如果有新任務(wù)，就重新開始，不要往原程序中加入新功能而搞得復(fù)雜。
2.假定每個程序的輸出都會成國另一個程序的輸入，哪怕那個程序還是未知的。輸出中不要有無關(guān)的信息干擾。避免使用嚴(yán)格的分欄格式和二進制格式輸入。不要堅持使用交互式輸入。
3.盡可能早地將設(shè)計和編譯的軟件投入試用，哪怕是操作系統(tǒng)也不例外，理想情況下，應(yīng)該是在幾星期之內(nèi)。對拙劣的代碼別猶豫，扔掉重寫。
4.優(yōu)先使用工具而不是拙劣的幫助來減輕編程的負擔(dān)。工欲善其事，必先利其器。
5.一個程序只做一件事，并做好。程序要能協(xié)作。程序要能處理文本流，因為這是最通用的接口。
- Rob Pike:
1.你無法斷定程序會在什么地方耗費運行時間。瓶頸經(jīng)常出現(xiàn)在想不到的地方，所以別急于胡找個地方改代碼，除非你已證實那兒就是瓶頸所在。
2.估量。在你沒對代碼進行估量，特別是沒找到最耗時的那部分之前，別去優(yōu)化速度。
3.花哨的算法在n很小時通常很慢，而n通常很小。花哨算法的常數(shù)復(fù)雜度很大。除非你確定n總是很大，否則不要用花哨算法（即使n很大，也優(yōu)先考慮第2條）
4.花哨的算法比簡單算法更容易出bug、更難實現(xiàn)。盡量使用簡單的算法配合簡單的數(shù)據(jù)結(jié)構(gòu)。
5.數(shù)據(jù)壓倒一切。如果已經(jīng)選擇了正確的數(shù)據(jù)結(jié)構(gòu)并具把一切都組織得井井有條，正確的算法也就不言自明。編程的核心是數(shù)據(jù)結(jié)構(gòu)，而不是算法。
給我看流程圖而不讓我看（數(shù)據(jù)）表，我仍會茫然不解；如果給我看（數(shù)據(jù)）表，通常就不需要流程圖了；數(shù)據(jù)表足夠說明問題了。
6.原則6：沒有原則6
- Ken Thompson:
模塊原則：使用間潔的接口拼合簡單的部件。
清晰原則：清晰勝于機巧。
拿不準(zhǔn)就窮舉。
組合原則：設(shè)計時考慮拼接組合。
分離原則：策略同機制分離，接口同引擎分離。
簡潔原則：設(shè)計要簡潔，復(fù)雜度能低則低。
吝嗇原則：除非確無它法，不要編寫寵大的程序。
透明性原則：設(shè)計要可見，以便審查和調(diào)試。
健壯原則：健壯源于透明與簡潔。
表示原則：把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸與健壯。
通俗原則：接口設(shè)計避免標(biāo)新立異。
緘默原則：如果一個程序沒什么好說的，就沉默。
補救原則：也現(xiàn)異常時，馬上退也并給出足夠錯誤信息。
經(jīng)濟原則：寧花機器一分鐘，不花程序員一秒鐘。
生成原則：避免手工hack，盡量編寫程序去生成程序。
優(yōu)化原則：雕琢前先要有原型，跑之前先學(xué)會走。
多樣原則：決不相信所謂“不二法門”的斷言。
擴展原則：設(shè)計著眼未來，未來部比預(yù)想來得快。
補充資源
- PHP 微服務(wù)系列大綱
- PHP 網(wǎng)絡(luò)編程基礎(chǔ) - swoole
- swoole| swoole wiki 筆記
- PHP 微服務(wù)框架
- 云平臺基礎(chǔ)設(shè)施
- php 基礎(chǔ)
