昨晚发生了一件尴尬的事情，一个月前接手一个 C# 的项目，拿到后因为很多功能无法正确运行，于是开始大海捞针般的查错。结果错误很隐晦，是一处未初始化错误导致的。当时改完，迅速提交到局域网的 SVN 中。这事也就算过去了。后来又改了几个小 bug。 待达到基本可用的状态后， 就没再管了。再后来，公司局域网互相不通，搭建的 SVN 居然无法被同事访问，于是想改用公网服务，首选当然是 Github，可惜私有项目的月费感人，实在用不起。退而求其次，改用 bitbucket， 这个也算是和 Github 齐名的 git 托管商，而且还有吸引人的优势：私有项目免费。
这时遇到一个技术问题，虽然提交的次数少，但依然有一些 log 产生了，SVN repository 转 git repository 倒不是没有办法，但步骤的确也比较繁琐。我想着大部分问题已经解决，以后的开发肯定也都基于这个版本，索性将当前版本作为 init 得了。于是提交上去的，是几乎没有任何日志的 repository。
事情过了快一个月，逐渐也被我淡忘了。没想到就在昨天，又被突然唤醒。
领导今天要去外地见一位软件使用者，但家里笔记本并未安装这个项目，于是就从 bitbucket 上去取代码。没想到竟是龟速，我得知这个消息，便也在家里取了一遍（我家里电脑恰好也没有取过），竟然也是龟速，而且将近 89% 左右会 fail 掉，从头 clone 了多次，居然还会并不会续传。（这里依然是对 git 的了解不够深入，应该有办法做到续传）这可怎么办。恰好领导那里有最原始的版本，问我可否基于这个版本，run 起来。
我想到那个最致命的 bug，无非就是增加一句初始化的语句而已。于是在 bitbucket 网站上在线翻翻看，这里又要吐槽一下 bitbucket，搜索功能完全不知道在哪里，细节上离 github 还是差很多，每个网页打开还特别慢。因为我记得我是做了注释的，且应该标上了我的大名。那么最简单的方式就是搜一下 pezy 即可。
结果找了半天都没找到。于是只能走另一条路，从错误查起，原路走一遍，看能不能记起来。于是远程领导笔记本，在 VS 里调试了起来。前面说了，这个错误很隐晦，而且 C# 中满地的 try catch，错误被捕获的地方，完全从堆栈里看不出错误的源发地。更何况，即使找到错误源发地：是一个 map 取一个不存在的 key 所致，也根本不知道这个 map 到底发生什么，导致了该 key 的缺失。如果真要重现我当时修复的步骤，得查来查去分析半天。而且我始终记得我是有注释的，能找到我的大名的。
最后一直查到凌晨了，浪费着两边的时间。领导提醒我不要再查了，明天直接给他修复版，或者告知他那句话是什么，在哪里加。这事就算暂时告一段落。
心里实在不好受，这样的结果，有好几个机会都可以避免：
结果就是这么寸，几个机会都被错过。心里气的牙痒痒，却无计可施。一夜都没睡好。
今早匆匆来到办公室，迅速在 VS 里搜了一下，心一凉，居然没有我认定的注释！也并没有什么我的大名。也许当初觉得这是 bug，修复也就修复了，用不着留下什么痕迹，再不济，还有修改日志不是。这就成了连环无解坑了。
还好我机器上还保留了一份 SVN 的 repository，迅速查了一下日志，找到了那句话。给领导发了过去。
一时间，百感交集，不能自已。
其实这句话我脑子里还是有印象的，昨晚远程的时候还真就找到了这个变量，但初始化语句没写对，也没写在正确的地方，导致无功而返。所以还是以上那几个原因，但凡有一项我做到了，做好了，都不会出这样的事情。
除了自责，我还带有情绪地将锅甩给了 bitbucket，本来网站的交互做的就让人不是很爽，没想到真用起来还出了这样的篓子。（虽然大部分都是我自己的问题），但毕竟给我留下了心理阴影，更何况速度真的是硬伤。我决定规模稍大的代码，不再用 bitbucket 了。
亡羊补牢，我决定重建记录，将代码存到 http://code.taobao.org 上去，至少它的速度没问题，所支持的 svn 也更适合目前的团队，毕竟操作简单，就是给我这个打杂的人减少负担啊。
总之，日志很重要，脑子没那么好使，还是要烂笔头。既然依赖工具，就养成使用工具的良好习惯，让一切都处于可控的范畴。
2017-08-15