过早的优化是万恶之源

过早的优化是万恶之源

作者：Grey

原文地址：

博客园：过早的优化是万恶之源

CSDN: 过早的优化是万恶之源

本文搬运自自己的博客园博客，发布于 2014-11-06

这两天，我做了两件事：

　　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. 效率这个东西，是很重要的，特别是在做项目的过程中，如果能尽量让机器帮忙解决的事情，就不要人工去做，而对于程序员来说，尽可能多的写一些小工具（当然我技术不好，可能写个工具的时间都要影响进度-_-#）来帮忙解决一些手工问题：比如之前在每个版本打分支的时候都需要建立项目的空目录，然后申请相应SVN权限，然后把空目录删除，将上一个版本在svn上copy to 一份出来作为开发，因为工程比较多，这个建立空目录的过程很繁琐，所以我就写了一个cmd脚本来运行建立新目录，这样每次打分支之前运行这个脚本即可，省去了一些copy/paste操作。
3. 项目开发的过程中，核心的技能就是尽量精确的评估，如果一件事，你没有评估就贸然去做，是一件非常可怕的事情，如果让我重新选择，我不会拿上班的时间再去重构这部分代码，我会先把任务完成，完成的基础上，下班后，在Intern version（for practise）上练习重构。
4. 突然想到自己为什么要用这个标题。-_-# ，重构的这部分代码不是我写的，当我看到这样的代码的时候常常会特别愤慨地说当时为什么写这样难维护的代码出来，后来当我写这个小工具，回头看看自己曾经写过的那些一点都不亚于这种难维护的代码的时候，我明白了：在做项目的时候，特别是极度紧迫的时间里，解决问题才是最重要的。如果你效率极高，能力极好，脑海中各种模式烂熟于心，一看到一个场景立马可以构建出可重用，易扩展的代码，那无可厚非；但是对于我们这些普通小白码农来说，首先解决这个问题，有时间多自己再折腾折腾把。