第三周小结

说心底的话，并没有想好给这一周写一个什么样的主题，所以就决定随意地写一下了。

这一周的心情管理算是达到了自己的预期。当前的状况并没有得到太多的改善，但是我自己可以很从现实地角度来看问题，思考现象背后深藏着什么，以及我在这个问题中的位置、角色和职责了。有些因素是很难改变的，特别是改变其他人或者所在的大环境； 相对而言，改变自己、适应环境是更容易的，也是最现实可行的办法。想尽一切方法去完成你的事情，达到你的目的，这才是自己应该尽的职责。

加上上周，所完成的事情总共有3件，其中是2个缺陷的修复，另外一个是关于数据库进程和线程的故障梳理（或过程梳理）。

• 上周的缺陷是跟一个GUC参数相关的全局变量，当初写代码时，别误会：）不是我写的代码，并没有完全地知道GUC参数的处理和加载过程，对于已经线程化的实例，使用一个进程级的全局变量，意味着这个变量无时无刻地被一堆线程修改着；终于，与主备切换过程结合起来，共同发生了非预期的问题。
• 本周的这个缺陷倒不完全类似。问题被搁置了5个月了，今天再次分析，从另一个角度尝试着去看，竟然柳暗花明又一村，发现了线索。对于发生在glibc库等地方的coredump问题，无数案例总结出来就两个点： 第一，问题发生的根因不在gblic库本身，而是我们的程度代码写得有些问题； 第二， 问题原因来讲，非法内存访问这个原因占据得最多。 另外，从这个缺陷还看到了新知识点，子线程的启动和退出完全有可能发生在pthread_create()函数还没有调用完成之前； 所以，对于全局变量以及内存的处理，如果跨线程进行处理，一定要非常地小心。
• 线程和进程的过程梳理，还不能够谈得上什么故障梳理，因为有一大片是涉及到数据可靠性相关的、并没有深入梳理。花费了三四天的梳理，结果看来，其中的问题是不少的，有些还是基础性的或者框架性的。另外，还能够看到另一个暴露的问题时，在多人开发一个大的系统时，每一个开发人员了解更多的周边知识，将更利于系统的开发和代码的健壮性； 若每个人只是小守自己的一亩三分地，对于身边的模块和代码照猫画虎般地修改，而不问为什么，那么这个系统的代码将会成为那个破窗，慢慢地腐化。

作为一个软件工程师，他的发展必然会经历一些困惑期或者瓶颈期的。这些可能是某方面知识的缺乏，也可能是与人打交道的经验缺乏，也可能是处理事情和挑大梁的压力。但是不管怎么样，只是站在原地不动，只是一味地看着问题和困难，停止不前的话，那么困难依然是困难，困境依然是困境，什么都不会改变的。做一些事情去改变，总是要比什么都不做要强得多。向前进的要点是什么？从我强的人说是三点：

• 要有全局观
• 抓住主要矛盾
• 及时总结

我现在能够做到的、有意识做到的只有最后一点，而前两点还只是在努力地去理解和实践。

学习是一个坚持的过程。但是从年初三个周来看，计划的事情似乎并不乐观，想去做的事情太多，实际做了的事情还是太少。还要得再想想，怎么破这样的一个困境呢？

有一个小生命在路上了，我要更坚强、更勇敢地向前进！