27th Dec 2016

很不开心，看同事留下来的代码感觉逻辑非常混乱。同事喜欢用简单直接暴力的方法解决问题。不考虑代码是否易读，易于修改。在一些命名上也完全无法体现这个变量/方法所代表的含义或者应该具有的功能。

1. 以后一定删掉不要的注释掉了的代码，我不想留一份心思给这些不知道何年何月你还想用的东西。
2. 以后绝对不给变量简单命名为 flag，命名为 isXXX 不知好多少。
3. 为什么不把重复的代码提炼出来？每个方法里都写上相同的三四行四五行代码写得不烦我看得不爽啊。
4. ORM 是个好东西，自己字符串拼接 sql 简直蠢加想死。

不过还好，反正刚看了重构的书，就拿这个代码练手了。

---

13th Dec 2016

jvm -D 参数真是个黑科技，可以传各种参数进去。现在知道的至少可以为 logback 配置文件所利用，不知道对于其他的 xml 文件是不是同样适用。在代码中又应该怎么去调用这个参数。

---

10th Dec 2016

如果遇到一个问题，到底应该按照一个什么样的步骤去解决它呢？

1. 如果这个问题你之前就遇到过了，那当然努力回忆就好了。
2. 如果没有遇到过，我认为首先就要去收集大量的信息。依靠”XXX 挂了”这个信息是很难做出可靠有效的判断的。 说到这个，在遭遇了各种各样的问题以后我才终于意识到了日志的重要性。日志能够指出你什么地方不对，或者记录程序之前干了什么，直接间接的帮助你定位问题。
3. OK,我们已经有了足够多的信息了。下一步就是利用这些信息，一步步的顺藤摸瓜找到问题的源头。 如果问题难以定位，我们可以在代码中插入更多的日志记录，然后尝试重现问题。

如果我们需要新增一个功能，需要考虑那些方面呢？

1. 哈，如果这个轮子已经有人做出来过了，你还需要再重复一次吗？能不能直接用别人的轮子呢？尤其是公司内部就已经有人实现过了？
2. 如果这个功能是原有功能的一次更新，或者替代了以前的功能，那他能向前兼容吗？
3. 如果是一个全新的功能。它该如何与其他组件通信协作？怎么样才能避免破坏现有的架构设计？
4. 易于拓展吗？易于修改吗？耦合紧密吗？

---

1st Dec 2016

12月的第一天悄然离去了。昨天今天晚上都尝试着在博客上新建一个文件夹，把每天的总结都放进去。这样别人在看我的博客的时候就能将博客与总结分开了。

想法不错，不过目前看来，Jekyll对这个还没有很好的支持。对_post文件夹的操作还是要更加丰富一点。

不行就不行吧，咱就写到这一个文件里好了。

1. 最近发现也能解决一些同事提出的问题了，这让我很开心。
2. Sword分配了许多Consul相关的问题交给我处理。磕磕绊绊也干了一两个月，总感觉自己对于Consul的理解已经突破天际了。下午听了Michael的分享会后发现自己果然还只是一只井底之蛙。
3. 有时间要去查一查logback配置文件的具体含义