过早的优化是万恶之源

这两天，我做了两件事：

　　1.重构了系统某个模块的部分代码：

　　花了一天时间，一个6k多行的java文件，搞到4k行加若干个类文件，恕我能力有限，后面的实在重构不下去了，那是一种3个domain属性名几乎一样100多个字段但是却用同一个copy了三遍的方法来处理的欲哭无泪，那是一种使劲滚鼠标滚轮都滚不到一个方法尾部的绝望（100多个字段的几个类属性equals来，equals去，get来，set去的，这样类型的方法有那么五六个，你说能不多吗）......

 

　　2.做了一个日志处理的小工具：

　　客户要求把日志里面记录的一些东西整理出来发给他们业务人员分析，有若干个日志文件，20多m一个，我本来打算一个一个Ctrl＋F，Ctrl＋C，Ctrl＋V的，但是后来想到自己能否更高效去处理这件事，毕竟自己出来工作两年了，很多时候做一些重复的事情，这样不会有提高，所以我决定用自己写个处理日志的小工具

　　把一个log文件里面的内容按关键字找到然后解析相应字段然后格式化写到excel里面去，

　　我把日志简化一下，其中一个片段样子大概是这样的：

　　　　field1:＝value1

　　　　field2:＝value2

　　　　field3:=value3

　　　　......

　　　　......　　

　　　　......

　　　　xxxxxxxxxxx：field3:value3 field4:value4 field5:value5　

 

　　我们需要取得field1，field3，field4，field5名字以及值 

　　field3-field5很好办，直接定位"field3:"所在的行，然后把这一行取出解析出来即可

　　但是field1的值不是很好处理，我当时就想了最傻的一个办法：扫一遍文件解析出field3-field5，然后用field3的值再扫一遍文件找到field1的值，速度那个慢呀

　　后来就想了一个稍微更聪明一点的办法，

　　把

　　　　field1:＝value1

　　　　field2:＝value2

　　　　field3:=value3

　　封装成一个数据结构, 每一行用一个字符串来装，在扫描第一遍的时候，就把这个数据结构的用List存起来，假设为TempList，把field3－field5作为一个数据结构存进一个list，这样的话 我处理之前得到的field3－field5这个List和这个TempList，内存操作，速度提升很明显。

 

收获和教训：

　　1.做这两件事的一个大背景是在版本正在开发的过程中，我写的版本计划预留了一部分时间去应对需求变更，但是自己却花了多余的时间做了第一件事，吃力不讨好，最后还没动需求要做的东西，重构了半天，代码还是如此的让人绝望，现在才深刻体会到，看别人写的优秀代码，是对自己的一种提高，看别人写的很恶心的代码，对自己也是一种提高：告诉自己不要这样写。

　　2.效率这个东西，是很重要的，特别是在做项目的过程中，如果能尽量让机器帮忙解决的事情，就不要人工去做，而对于程序员来说，尽可能多的写一些小工具（当然我技术不好，可能写个工具的时间都要影响进度-_-#）来帮忙解决一些手工问题，会大大提高自己的工作效率，同时，又可以锻炼自己的编程能力。

　　3.项目开发的过程中，核心的技能就是尽量精确的评估，如果一件事，你没有评估就贸然去做，是一件非常可怕的事情，如果让我重新选择，我不会拿上班的时间再去重构这部分代码，我会先把任务完成，完成的基础上，下班后，在Intern version（for practise）上练习重构。

　　4.突然想到自己为什么要用这个标题。-_-#