sphinx php教程，什么樣的代碼叫好代碼？
送大家以下java學習資料
簡介： 我們每天都與代碼打交道，但當被問道什么是好的代碼時，很多人可能會先愣一下，然后給出的回答要么比較空泛，要么比較散，沒辦法簡單明了地概括出來。顯然，這個問題并沒有唯一的標準答案，誰都可以談論自己的理解，今天談談我對于好代碼的理解。
導讀：我們每天都與代碼打交道，但當被問道什么是好的代碼時，很多人可能會先愣一下，然后給出的回答要么比較空泛，要么比較散，沒辦法簡單明了地概括出來。顯然，這個問題并沒有唯一的標準答案，誰都可以談論自己的理解，今天談談我對于好代碼的理解。
一句話概括衡量代碼質量的唯一有效標準：WTF/min —— Robert C. Martin
Bob大叔對于好代碼的理解非常有趣，對我也有很大的啟發。我們編寫的代碼，除了用于機器執行產生我們預期的效果以外，更多的時候是給人讀的，這個讀代碼的可能是后來的維護人員，更多時候是一段時間后的作者本人。
我敢打賭每個人都遇到過這樣的情況：過幾周或者幾個月之后，再看到自己寫的代碼，感覺一團糟，不禁懷疑人生。
我們自己寫的代碼，一段時間后自己看尚且如此，更別提拿給別人看了。
任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優秀的程序員。—— Martin Fowler
所以，談到好代碼，首先跳入自己腦子里的一個詞就是：整潔。
好的代碼一定是整潔的，給閱讀的人一種如沐春風，賞心悅目的感覺。
整潔的代碼如同優美的散文。—— Grady Booch
好代碼的特性很難給好的代碼下一個定義，相信很多人跟我一樣不會認為整潔的代碼就一定是好代碼，但好代碼一定是整潔的，整潔是好代碼的必要條件。整潔的代碼一定是高內聚低耦合的，也一定是可讀性強、易維護的。
高內聚低耦合
高內聚低耦合幾乎是每個程序員員都會掛在嘴邊的，但這個詞太過于寬泛，太過于正確，所以聰明的編程人員們提出了若干面向對象設計原則來衡量代碼的優劣：
開閉原則 OCP (The Open-Close Principle)單一職責原則 SRP (Single Responsibility Principle)依賴倒置原則 DIP (Dependence Inversion Principle)最少知識原則 LKP (Least Knowledge Principle)) / 迪米特法則 (Law Of Demeter)
里氏替換原則 LSP (Liskov Substitution Principle)接口隔離原則 ISP (Interface Segregation Principle)組合/聚合復用原則 CARP (Composite/Aggregate Reuse Principle)這些原則想必大家都很熟悉了，是我們編寫代碼時的指導方針，按照這些原則開發的代碼具有高內聚低耦合的特性。換句話說，我們可以用這些原則來衡量代碼的優劣。
但這些原則并不是死板的教條，我們也經常會因為其他的權衡（例如可讀性、復雜度等）違背或者放棄一些原則。比如子類擁有特性的方法時，我們很可能打破里氏替換原則。再比如，單一職責原則跟接口隔離原則有時候是沖突的，我們通常會舍棄接口隔離原則，保持單一職責。只要打破原則的理由足夠充分，也并不見得是壞的代碼。
可讀性
代碼只要具有了高內聚和低耦合就足夠好了嗎？并不見得，我認為代碼還必須是易讀的。好的代碼無論是風格、結構還是設計上都應該是可讀性很強的。可以從以下幾個方面考慮整潔代碼，提高可讀性。
命名
大到項目名、包名、類名，小到方法名、變量名、參數名，甚至是一個臨時變量的名稱，其命名都是很嚴肅的事，好的名字需要斟酌。
? 名副其實
好的名稱一定是名副其實的，不需要注釋解釋即可明白其含義的。
/** * 創建后的天數 **/ int d; int daysSinceCreation;
后者比前者的命名要好很多，閱讀者一下子就明白了變量的意思。
? 容易區分
我們很容易就會寫下非常相近的方法名，僅從名稱無法區分兩者到底有啥區別（eg. getAccount()與getAccountInfo()），這樣在調用時也很難抉擇要用哪個，需要去看實現的代碼才能確定。
? 可讀的
名稱一定是可讀的，易讀的，最好不要用自創的縮寫，或者中英文混寫。
? 足夠短
名稱當然不是越長越好，應該在足夠表達其含義的情況下越短越好。
格式
良好的代碼格式也是提高可讀性非常重要的一環，分為垂直格式和水平格式。
? 垂直格式
通常一行只寫一個表達式或者子句。一組代碼代表一個完整的思路，不同組的代碼中間用空行間隔。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } publicResult<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
如果去掉了空行，可讀性大大降低。
public class Demo { @Resource private List<Handler> handlerList; private Map<TypeEnum, Handler> handlerMap = new ConcurrentHashMap<>(); @PostConstruct private void init() { if (!CollectionUtils.isEmpty(handlerList)) { for (Handler handler : handlerList) { handlerMap.put(handler.getType(), handler); } } } public Result<Map<String, Object>> query(Long id, TypeEnum typeEnum) { Handler handler = handlerMap.get(typeEnum); if (null == handler) { return Result.returnFailed(ErrorCode.CAN_NOT_HANDLE); } return handler.query(id); } }
類靜態變量、實體變量應定義在類的頂部。類內方法定義順序依次是：公有方法或保護方法 > 私有方法 > getter/setter 方法。
? 水平格式
要有適當的縮進和空格。
? 團隊統一
通常，同一個團隊的風格盡量保持一致。集團對于 Java 開發進行了非常詳細的規范。（可點擊下方閱讀原文，了解更多內容）
類與函數
? 類和函數應短小，更短小
類和函數都不應該過長（集團要求函數長度最多不能超過 80 行），過長的函數可讀性一定差，往往也包含了大量重復的代碼。
? 函數只做一件事（同一層次的事）
同一個函數的每條執行語句應該是統一層次的抽象。例如，我們經常會寫一個函數需要給某個 DTO 賦值，然后再調用接口，接著返回結果。那么這個函數應該包含三步：DTO 賦值，調用接口，處理結果。如果函數中還包含了 DTO 賦值的具體操作，那么說明此函數的執行語句并不是在同一層次的抽象。
? 參數越少越好
參數越多的函數，調用時越麻煩。盡量保持參數數量足夠少，最好是沒有。
注釋
? 別給糟糕的代碼加注釋，重構他
注釋不能美化糟糕的代碼。當企圖使用注釋前，先考慮是否可以通過調整結構，命名等操作，消除寫注釋的必要，往往這樣做之后注釋就多余了。
? 好的注釋提供信息、表達意圖、闡釋、警告
我們經常遇到這樣的情況：注釋寫的代碼執行邏輯與實際代碼的邏輯并不符合。大多數時候都是因為代碼變化了，而注釋并沒有跟進變化。所以，注釋最好提供一些代碼沒有的額外信息，展示自己的設計意圖，而不是寫具體如何實現。
? 刪除掉注釋的代碼
git等版本控制已經幫我們記錄了代碼的變更歷史，沒必要繼續留著過時的代碼，注釋的代碼也會對閱讀等造成干擾。
錯誤處理
? 錯誤處理很重要，但他不能搞亂代碼邏輯
錯誤處理應該集中在同一層處理，并且錯誤處理的函數最好不包含其他的業務邏輯代碼，只需要處理錯誤信息即可。
? 拋出異常時提供足夠多的環境和說明，方便排查問題
異常拋出時最好將執行的類名，關鍵數據，環境信息等均拋出，此時自定義的異常類就派上用場了，通過統一的一層處理異常，可以方便快速地定位到問題。
? 特例模型可消除異常控制或者 null 判斷
大多數的異常都是來源于NPE，有時候這個可以通過 Null Object 來消除掉。
? 盡量不要返回 null ，不要傳 null 參數
不返回 null 和不傳 null 也是為了盡量降低 NPE 的可能性。
如何判斷不是好的代碼討論了好代碼的必要條件，我們再來看看好代碼的否定條件：什么不是好的代碼。Kent Beck 使用味道來形容重構的時機，我認為當代碼有壞味道的時候，也代表了其并不是好的代碼。
代碼的壞味道
? 重復
重復可能是軟件中一切邪惡的根源。—— Robert C.Martin
Martin Fowler 也認為壞味道中首當其沖的就是重復代碼。
很多時候，當我們消除了重復代碼之后，發現代碼就已經比原來整潔多了。
? 函數過長、類過大、參數過長
過長的函數解釋能力、共享能力、選擇能力都較差，也不易維護。
過大的類代表了類做了很多事情，也常常有過多的重復代碼。
參數過長，不易理解，調用時也容易出錯。
? 發散式變化、霰彈式修改、依戀情結
如果一個類不是單一職責的，則不同的變化可能都需要修改這個類，說明存在發散式變化，應考慮將不同的變化分離開。
如果某個變化需要修改多個類的方法，則說明存在霰彈式修改，應考慮將這些需要修改的方法放入同一個類。
如果函數對于某個類的興趣高于了自己所處的類，說明存在依戀情結，應考慮將函數轉移到他應有的類中。
? 數據泥團
有時候會發現三四個相同的字段，在多個類和函數中均出現，這時候說明有必要給這一組字段建立一個類，將其封裝起來。
? 過多的 if...else 或者使用 switch
過多的 if...else 或者 switch ，都應該考慮用多態來替換掉。甚至有些人認為除個別情況外，代碼中就不應該存在 if...else 。
總結本文首先一句話概括了我認為的好代碼的必要條件：整潔，接著具體分析了整潔代碼的特點，又分析了好代碼的否定條件：什么樣的代碼不是好的代碼。僅是本人的一些見解，希望對各位以后的編程有些許的幫助。
我認為僅僅編寫出可運行的代碼是遠遠不夠的，還要時刻注意代碼的整潔度，留下一些漂亮的代碼，希望寫的代碼都能保留并運行 102 年！
后續增加一些實際的例子來說明好的和壞的代碼；分享下如何編寫整潔代碼——自己認為有用的一些編程技巧。
mysql表數據量太大？
作為一名IT行業的從業人員，主要在從事產品研發及項目管理工作，在項目過程中，經常有優化數據庫存儲、架構方面的方案，所以我來探討一下這個問題。
目前經常使用的關系型數據庫如MySQL、SQL Server等，都是以“行”為單位進行存儲，為了快速檢索，也都采用了B樹或其他索引技術。
從原理上來講，表中的數據越多，索引樹的范圍越大，磁盤讀取也越多，性能也就越低。
從實踐角度來看，一般以百萬到千萬作為一個表的存儲量級，超出該范圍之后，性能就會下降，需要采用其他技術手段解決。
首先想到的就是能否將讀和寫分離，主數據庫用于寫入，讀數據庫（多個）用于對外提供查詢，通過數據復制的方式將主數據庫的數據同步到讀庫。該架構提升了數據庫的讀寫能力，但對于主數據庫的寫入能力依然沒法擴展。
其次，垂直分表就是把一個數據量很大的表,可以按某個字段的屬性或使用頻繁程度分類,拆分為多個表。如有多種業務類型，每種業務類型建立不同的表，tb1,tb2,tb3。如果日常業務不需要使用所有數據，可以按時間分表，比如說月表。每個表只存一個月的記錄。
再次，水平分表就是根據一列或多列數據的值把數據行放到多個獨立的表里，這里不具備業務意義。如按照id分表，末尾是0-9的數據分別插入到10個表里面。
這樣做的好處就是解決了數據存儲容量的問題，但也帶來了諸多弊端，不再一一闡述。
mysql優化的方式有很多，選擇上主要還是要考慮個人的實際情況，如代碼不可控的情況下，就不適合選擇按字段屬性分表的情況，這樣可能會帶來大量的重構以及很多不可預期的風險。
而架構的優化，雖然對應用是透明的，但對sql的寫法有很多局限性，比如說不能使用聚合函數等等，同時也需要有充足的硬件資源，只有一臺服務器的情況下是沒有意義的。
相比起來，代價最低的是按時間分表或分區，這兩種辦法對應用來說都是透明的。分區只需要一次本地數據遷移的操作。而通過分表把現網數據和歷史數據分離，唯一的代價是定期的數據維護。
一般如果表里面有1億數據的情況下，索引的問題應該是常識了，這方面我就不說了。
以上就是關于sphinx php教程以及什么樣的代碼叫好代碼的相關回答，有更多疑問可以加微。