參加industriallogic的軟體培訓，有很多感觸。
正像敏捷一樣，一位創始人也說敏捷其實並不神秘，乙個愛動腦筋的程式設計師做幾年軟體之後，自然會採用這些方法來改進工作效果/提高效率。確實也是這樣。
軟體培訓內容也是這樣，雖然很多問題，之前也思考過，也改進過，但在真正的工作環境中，看到很多code smell，也無能為力，只能麻木了。
參加一下這樣的培訓很有好處，對各種code smell/重構方法等進行了分門別類的系統介紹，還有精心設計的實戰演練，和一些方法的演示，都非常有裨益。
概括一些我認為比較重要的經驗：
1 **是反覆修改出來的。（我之前也有此體會，我覺得好的**就是修改修改再修改才出來的，跟寫文章是一樣的。不過，事實上，軟體公司可能並不這樣認為，它可能覺得寫完**提交之後就不應該修改，如果修改說明質量不好，有些甚至採用強制措施鎖庫等，不允許修改。）
2 小粒度重構。（把重構分為若干小步，一次只走一小步，修改一點點之後立即執行測試用例，通過之後繼續走。也成為baby step。不這樣做，很可能無法做到隨時執行用例，檢查修改是否會破壞已有功能。）
3 用工具進行重構。（用工具效率會高很多，也不容易出錯，熟練掌握這種套路之後，甚至可以放心的去對一些看不到懂**做重構。難怪tw不懂業務，也能大刀闊斧的指導重構啊。由此看來，現在更多的傾向於補充系統用例，而不是重構，也有點保守了啊，當然安全非常重要，講重構的也都強調有自動測試保障再重構。）
4 注釋是smell。（最好的**是非常簡潔，本身**就是自注釋，無須額外注釋的。）
5 長函式是smell。（長不是絕對長度，乙個做軟體的人，如果看一眼該函式，不懂它要幹什麼，那麼就是長函式。）
6 注意寫**的層次。（寫上層的東西，也就是接近使用者的[比如類的使用者]，那麼它裡面每句話都應該是面對使用者的，使用者無須弄懂內部原理也要能很容易看懂。真正的實現可能被封裝在乙個私有方法裡面。這種思想在敏捷的story中也有體現，它要求story的描述要是使用者都能懂的。這一點，我覺得也可以總結為「寫**要像寫文章一樣的寫」，估計寫文章，沒有人會把文章寫得別人看不懂吧？）
好的軟體是怎麼寫出來的？
參加industriallogic的軟體培訓，有很多感觸。正像敏捷一樣，一位創始人也說敏捷其實並不神秘，乙個愛動腦筋的程式設計師做幾年軟體之後，自然會採用這些方法來改進工作效果 提高效率。確實也是這樣。軟體培訓內容也是這樣，雖然很多問題，之前也思考過，也改進過，但在真正的工作環境中，看到很多code...
分布式是寫出來的（六）
當服務端收到get請求，服務端不會把整個物件返回給客戶端，服務端首先做seek，查詢客戶端提供的range bytes first的位元組數，從0 first的內容服務端直接丟棄，那麼服務端從first開始傳遞資料 如果客戶端想分片上傳資料，那麼客戶端和服務端，須有約定。使用post告訴服務端上傳資...
分布式是寫出來的（二）
介面服務層對外提供rest服務，資料服務層提供資料儲存功能。兩者之間通過訊息佇列進行通訊，資料服務層的所有資料服務註冊dataserver exchange，以便client給介面服務層發訊息後，介面服務收到get請求時，定位物件被儲存在哪乙個資料服務節點，通過dataserver exchange...