woman-sitting-on-concrete-stairs-holding-sparkler-2058791.jpg
前言：
有幸在公司参加了一个老师的培训课，感觉需要总结出来一点东西，以防以后忘记，好记性不如烂笔头。其实老师讲的挺好的，整个培训过程中，一直在围绕着重构和单元测试在扩展，介绍了很多工具和学习的思想，话不多说，开始写了。
代码重构：
这个想都不用想，必须要做的。可能有两种做法，一种是在写代码之前，就已经想好如何重构了，大概分成几个方法去写。另外一种是先写完代码，然后再去重构、提炼代码。个人认为这应该是两种境界，第一种是更高的一种境界，在下笔之前已经胸有成竹，而且竹子的叶子和根在哪个位置都清清楚楚。我自己还是处于第二种，要想做到第一种，就必须要把单元切割做的更细，更专注......在努力进步中......
防御性编程：
这个其实和安全有点关系了，也就是代码的健壮性，从整体性来说，进入方法前要做一些边界值，特殊值的判断，在方法结束的时候，对应的要处理异常。当然，其他的安全措施还有很多......
单元测试：
这个真的是很重要，年龄越大，越来越体会到......想想年轻的时候，别人也经常说，但是就是重视不起来，所以有些时候，有些事还是需要自己亲身经历，才会记忆深刻，才会真正想改变。
所以，总结了一句话：有些话要敢于去说，有些事要敢于去做，有些事要敢于去想，只有这样，才有可能提前经历一些事情，让自己更早的领悟一些东西。其实说到单元测试，老师说过一句话：测试驱动开发，要先写测试代码，然后再去写代码，我也认为这样是很有必要的。首先，当你写完单元测试的代码的时候，你自己对本身的业务逻辑有一个整体的梳理。然后再去写代码，写的时候就不用费尽脑汁的一边想业务逻辑，一边还要写代码，只专注一件事情，才能提高效率。写完之后，直接运行单元测试，就可以验证代码的正确性，其他的就不需要做了。
这样对于以后自己要想修改自己这块的代码的时候，也大有裨益，只需要运行一遍单元测试代码，就可以验证功能是否受到新代码的影响，而不是需要从头到尾再去检查一下代码的逻辑，费时，太消耗精力。我发现这也是我们大部分时候都会抱怨自己时间不够用，其实细细的分析我们平时的具体工作，是因为我们的效率不高导致的。
单元切割：
个人感觉这能够反映一个人的架构能力，也就是架构师必备的技能。当拿到一个功能需求，如何把他切割成一块一块可以具体去编码的小方块，是很考验一个人的综合素质的。
首先拿到一个功能需求，不是立刻就去动手怎么写代码，而是先找一个画图工具，发散思维，想想这个功能由哪些小的功能点组成，想想客户想要实现成什么样子，想想如何做才能让这个功能更加丰富，想想如何做才能提高性能、可扩展、监控、容错性好......综合这些方面，慢慢的应该会拆分成一个一个小功能模块，可以先发散思维，后续再决定是否全部要做，还是分期去做。
如何阅读源码：
1、首先可以利用工具，提炼出类图或者流程图加速我们理解。
2、先阅读版本比较低的源码，这样代码量少，高容易理解，然后再一步一步的去阅读高版本的。
3、对比阅读，相邻两个版本对比式阅读，看看发生了哪些变化，为什么要这么变化，是如何做到的。
4、抓住一个核心变量，跟踪它的生命周期。
解决问题的思路历程：
尽量让自己解决问题的思路沉淀下来，可以以图或者文字等等，这样可以有助于以后优化自己的思路，也可以让自己更清晰的看到整个思考过程，看看到底发生了什么。恐惧源于未知......
合理的利用工具：
工具是个好东西，像电脑、汽车、计算器等等，大大的提高了我们的办事效率，让我们有更多的时间和精力专注于核心、重要的事情上面。所以合理利用工具也是一项必备技能。编程也一样也有很多好的工具，我们要善于寻找、发现。
工具：
yEd Graph Editor（画图） Enterprise Architect（该有的都有） Understand（重构代码） Sword soft screenink（Mac 画图） Data creator（造数据） Data Factory（造数据）
推荐的书籍：
《彩色UML建模》《重构：改善既有代码设计》
建议阅读的源码：
Junit源码、Hadoop0.1源码 Linux 源码
编程思想：
单元切割、重构、工具
HTSM.png
网友评论