昨天
xx面試時，一道這樣的問題難住了我，就是：在這麼多年的編碼中，說說自己的最佳實踐。當時懵掉了，雖然看過很多敏捷開發、**清潔之道、**大全這些關於最佳實踐的書，但卻一條也說不出來。趁現在有時間，想想這個問題，總結一下自己的**最佳實踐。
一致的**格式。
形成自己的工具類。
開發時，為了減少**量，多使用第三方的類庫，如
apache commons
等，裡面提供了簡化操作的類。形成自己的工具類目標是簡化**開發，對一些通用功能進行封裝。
業務邏輯與技術實現相分離. 如果乙個函式或者乙個類主要用來描述業務邏輯實現，那麼最好不要在該方法有過多的技術細節實現。例如註冊讀者的功能，檢查有效性、插入到資料庫、傳送郵件等這些算是業務邏輯。而針對每乙個業務邏輯的技術實現細節最好和業務邏輯實現分開。這樣使**更加清晰。
保持類和函式的短小，盡量提取可復用元件或者函式類短小，可以控制類的單一功能和類的簡單性。越簡單越有助於重用。編寫**時，對每個**段考慮這個**段會重複出現嗎？重複出現時，哪些引數需要變化？該怎麼抽象這段**呢？
用設計模式去思考要解決的問題。而不是用流程去思考問題。
優先使用組合，而非繼承。繼承意味著會給新建類帶來新的方法，這些方法真的適用於這個新建的類嗎？
編寫類時，應考慮這個類會不會在多執行緒下使用，如果在多執行緒環境下會不會有問題，如果有問題，該怎麼解決。
慎用
stringbuffer/vector/hashtable，這些類儘管在多執行緒下沒有問題，但在單執行緒環境下可能效率不高。在單執行緒環境下，使用
stringbuilder/arraylist/hashmap.
如果是多執行緒環境，考慮使用
jcf中的同步類。
變數名、函式名、類名表意。寫出來的**要達到不用注釋就能看懂。
命名時，避免使用類似
readerinfo
，readerclass這樣的類名。
info
和class
是語義的重複，無需在命名時使用。
邊開發邊重構。寫**時，如果發現有些不妥的地方，要及時重構和修改、測試。有時會想，先做完再重構，忘掉這種想法。這種想法不可取。越往後拖，越不易重構，越懶得重構。
應考慮寫出的**可能面臨的效能問題。使用這個類合適嗎？有更簡單更有效的**改進嗎？迴圈的結構修改一下會不會會提高效率，要不要定義臨時變數或者狀態字段儲存處理結果以減少多次運算？……
常見的類名字首或者字尾：
*********
、default***, ***serviceprovider
，***utils, ***templage, ***template
, ***model
，***factory, ****adapter .
介面在宣告是多使用
***able
，表示實現類具有該能力，如
runable
，configurable，customizable
，imutable
等等。而實現類的宣告多使用
***runner,****configuration
等名詞結構。
目前暫時想到了這麼多，以後想到了再補充。
PHP編碼的幾個最佳實踐
繼續說說php的幾個編碼優化 b 1.用逗號連線echo字串 b name orange address beijing echo hi,name.welcome to address 慢 echo hi,name,welcome to address 快，建議方式 原因可以檢視兩者的opcode，...
Scala編碼規範與最佳實踐 測試
測試 測試類應該與被測試類處於同一包下。如果使用spec2或scalatest的flatspec等，則測試類的命名應該為 被測類名 spec 若使用junit等框架，則測試類的命名為 被測試類名 test 測試含有具體實現的trait時，可以讓被測試類直接繼承trait。例如 trait recor...
Spring JDBC的最佳實踐
其一 需要注意合理設定statement的fetchsize大小，即jdbctemplate暴露的fetchsize變數的取值。大量實踐證明，通常情況下，將fetchsize設定為30 50最為合理，但也存在特殊情況。fetchsize取值太大，jvm消耗的臨時記憶體會很多。其二 儲存或更新大批量的...