參加industriallogic的軟件培訓，有很多感觸。
正像敏捷一樣，一位創始人也說敏捷其實並不神秘，一個愛動腦筋的程序員做幾年軟件之後，自然會采用這些方法來改進工作效果/提高效率。確實也是這樣。
軟件培訓內容也是這樣，雖然很多問題，之前也思考過，也改進過，但在真正的工作環境中，看到很多code smell，也無能為力，只能麻木了。
參加一下這樣的培訓很有好處，對各種code smell/重構方法等進行了分門別類的系統介紹，還有精心設計的實戰演練，和一些方法的演示，都非常有裨益。
概括一些我認為比較重要的經驗：1 代碼是反復修改出來的。我之前也有此體會，我覺得好的代碼就是修改修改再修改才出來的，跟寫文章是一樣的。不過，事實上，軟件公司可能並不這樣認為，它可能覺得寫完代碼提交之後就不應該修改，如果修改說明質量不好，有些甚至采用強制措施鎖庫等，不允許修改。）
2 小粒度重構。把重構分為若干小步，一次只走一小步，修改一點點之後立即運行測試用例，通過之後繼續走。也成為baby step。不這樣做，很可能無法做到隨時運行用例，檢查修改是否會破壞已有功能。）
3 用工具進行重構。用工具效率會高很多，也不容易出錯，熟練掌握這種套路之後，甚至可以放心的去對一些看不到懂代碼做重構。難怪TW不懂業務，也能大刀闊斧的指導重構啊。由此看來，現在更多的傾向於補充系統用例，而不是重構，也有點保守了啊，當然安全非常重要，講重構的也都強調有自動測試保障再重構。）
4 注釋是smell。最好的代碼是非常簡潔，本身代碼就是自注釋，無須額外注釋的。）
5 長函數是smell。長不是絕對長度，一個做軟件的人，如果看一眼該函數，不懂它要干什麼，那麼就是長函數。）
6 注意寫代碼的層次。寫上層的東西，也就是接近用戶的[比如類的使用者]，那麼它裡面每句話都應該是面對用戶的，用戶無須弄懂內部原理也要能很容易看懂。真正的實現可能被封裝在一個私有方法裡面。這種思想在敏捷的story中也有體現，它要求story的描述要是用戶都能懂的。這一點，我覺得也可以總結為“寫代碼要像寫文章一樣的寫”，估計寫文章，沒有人會把文章寫得別人看不懂吧？）
本文出自 “果凍的軟件技術博客” 博客，請務必保留此出處http://sinojelly.blog.51cto.com/479153/225444
