参加industriallogic的软件培训，有很多感触。
正像敏捷一样，一位创始人也说敏捷其实并不神秘，一个爱动脑筋的程序员做几年软件之后，自然会采用这些方法来改进工作效果/提高效率。确实也是这样。
软件培训内容也是这样，虽然很多问题，之前也思考过，也改进过，但在真正的工作环境中，看到很多code smell，也无能为力，只能麻木了。
参加一下这样的培训很有好处，对各种code smell/重构方法等进行了分门别类的系统介绍，还有精心设计的实战演练，和一些方法的演示，都非常有裨益。
概括一些我认为比较重要的经验：
1 代码是反复修改出来的。（我之前也有此体会，我觉得好的代码就是修改修改再修改才出来的，跟写文章是一样的。不过，事实上，软件公司可能并不这样认为，它可能觉得写完代码提交之后就不应该修改，如果修改说明质量不好，有些甚至采用强制措施锁库等，不允许修改。）
2 小粒度重构。（把重构分为若干小步，一次只走一小步，修改一点点之后立即运行测试用例，通过之后继续走。也成为baby step。不这样做，很可能无法做到随时运行用例，检查修改是否会破坏已有功能。）
3 用工具进行重构。（用工具效率会高很多，也不容易出错，熟练掌握这种套路之后，甚至可以放心的去对一些看不到懂代码做重构。难怪TW不懂业务，也能大刀阔斧的指导重构啊。由此看来，现在更多的倾向于补充系统用例，而不是重构，也有点保守了啊，当然安全非常重要，讲重构的也都强调有自动测试保障再重构。）
4 注释是smell。（最好的代码是非常简洁，本身代码就是自注释，无须额外注释的。）
5 长函数是smell。（长不是绝对长度，一个做软件的人，如果看一眼该函数，不懂它要干什么，那么就是长函数。）
6 注意写代码的层次。（写上层的东西，也就是接近用户的[比如类的使用者]，那么它里面每句话都应该是面对用户的，用户无须弄懂内部原理也要能很容易看懂。真正的实现可能被封装在一个私有方法里面。这种思想在敏捷的story中也有体现，它要求story的描述要是用户都能懂的。这一点，我觉得也可以总结为“写代码要像写文章一样的写”，估计写文章，没有人会把文章写得别人看不懂吧？）
