1.uml的重要性，推薦plantuml
2.編碼編的其實是思路：先寫注釋（思路），在寫**
3.設計之初，所有方法都是黑盒
4.設計模式要順其自然
5.介面的重要性是告訴別人我是幹什麼的
6.介面設計的伸縮性：考慮中間資料狀態，減少對應終端介面修改
7.行業內的規範還是要遵守的，比如是 mvc,保留適當的dal層，關鍵時刻可以救命
8.減少同層之間的呼叫（同乙個類內的不算哦），會增加系統的維護成本或者出事故的概率
===2016-07-24
9.複雜的場景，先做抽象，每乙個場景總有核心的，其他的功能只是拓展
10.好的系統是積累出來的，不要一開始的設計就奔著bat的規模去，一方面很累，一方面可能沒有意義
11.多關注底層和原始碼，會給你一些驚喜
12.多關注其他語言，說不定你就會轉語言的，呵呵，其實不同語言不通思想給你不同的思路
*****==2017-09
13.盡量避免業務層同級之間的直接呼叫，比如service層呼叫service層,首先service一般代表了乙個業務，上層肯定服務於某乙個對外開發的api,不同的api完成的業務也肯定不一樣，否則就不會分開來定義，乙個service呼叫另外乙個service，表示這有業務之間的緊密關係，或者單純的**復用，如果是後者的話，完全不要這樣去做，servicea 呼叫 serviceb，b 發生了變動，a儲存原業務，但是 也要跟著做修改，這個有悖於開閉原則，而且會容易忽略掉，導致bug；如果是業務之間很強的關聯關係，b變化 a也必定變化，這樣的可以呼叫，但是也要謹慎，誰知道需求會怎麼變呢？而且在在api層去分別呼叫a b，來組裝，比a 直接呼叫b 麻煩不了多少，還不用擔心這麼多
14.開發模式選擇，無論大小專案，建議盡量採用模組式的開發，定義資料模型，定義模型職責，而不是採用分層式的開發模式（所有service放在service中，所有dao 統一放在 dao層中），如果專案發展可以，分層式的最終走向肯定是模組式的，而且模組式比分層式的開發，工作量增加10%以內，10%的工作量，換取更易管理的工程，肯定是划算的，
給自己的小建議 持續更新
在生活和學習的道路上，總結的一些小經驗 1.大便不要帶手機。一來容易把手機落進廁所，二來浪費時間 2.給自己創造乙個學習的環境。雖然學習自主性很重要，但是學習環境越好，可以緩解你學習自主性的壓力。試想一想，你在遊戲聲 喊叫聲 聲交雜的寢室和安靜的教室，哪個地方讓你更有心思學習？環境對於學習不是絕對的...
寫給自己的幾點建議持續更新
1 通常在遍歷乙個iterator的時候不建議修改集合本身。2 hashtable上下文中同步是什麼意思？同步意味著在乙個時間點只能有乙個執行緒可以修改雜湊表，任何執行緒在執行hashtable的更新操作前需要獲取物件鎖，其他執行緒等待鎖的釋放。3 select from v locked obje...
網路程式設計雜項 （持續更新）
by fireworks2 foxmail.com 記錄一些小問題，陷阱 1.呼叫bind時，如果位址是0 就是inaddr any那個巨集 就繫結本地所有ip，如果埠是0，就隨機選擇乙個可用的埠 想要知道具體埠，可以呼叫getsockname檢視 2.send recv 與 read write ...