作为一只菜鸟级别的程序猿，我的日常座右铭就是good good study, day day up了...
没错，程序猿这个行业呢，不是你主动学习，就是工作迫使你学习，像我这样的底层的小开发一枚，每天都需要不断地“学习”，首先呢，要学习怎么很好地了解产品经理提的需求，写出匹配的开发文档，然后呢，要学习怎么写出更优雅的代码，提高程序的运行效率，再然后...上班的8小时感觉非常“充实”呢...可能有小伙伴会问，程序猿只上班8小时，不太现实吧，我只能说：兄弟，你很睿智，一眼看穿，怎么可能8小时呢，程序猿的上班时间是没有8小时之说的，保底10小时以上...大家习惯了就好，我不由想起年幼无知的我当初面试时问HR的问题："你们公司加班吗？"，我不知道当时HR是怎样的内心活动，哈哈哈哈...
随着相对于机器语言，更接近自然语言的计算机高级语言的出现，编程变得越来越好入门，也使得越来越多的人进入编程这一行列，程序猿们的生存之路显然变得越发的狭窄，竞争也就越发的激烈，“学无止境”这个词很好地形容了现在程序员们的处境，随着技术语言的的不断更新，我们的程序也得不断地升级更新，适应时代的需要，适应用户的需要，这是毋庸置疑的，不然结果就是被“拍死”在沙滩上...
为了不成为“沙滩”中的一员，我们必须做些什么，作为开发人员，我们暂不需要关心整个产品的架构设计，毕竟上面有架构师，开发经理一些大牛们坐镇，我觉得，我们主要关心的是我们负责的模块，我们对Leader分配给自己的模块要有主人翁精神，简单来讲，这个模块是你负责的，你就要对这个模块负责，从了解需求到模块上线所有的环节必须负责到底，那怎样算负责呢？怎样使得自己负责的模块能够顺利上线呢？我觉得提升自我是关键。
作为一个模块的最终执行者-个体软件工程师，你写的代码直接影响你负责的模块，各个模块的质量又会多少影响整个产品，如果把一个产品看作一个水桶，每个模块就是组成这个水桶的木板，那么问题来了，这个水桶的承载量是由什么决定的？答案很显然，是由最短的那块木板决定的，也就是说整个产品的质量是由最差的那个模块决定的。
由此看出提高个体软件工程师的能力是非常重要的，我们可以参考个体软件过程（PSP），制定适合自己的一套记录表，主要记录1.时间分配，比如一个模块，具体的设计时间，开发时间，2.逻辑的漏洞，比如：什么逻辑漏洞，发现的时间（设计阶段，代码阶段，测试阶段，产品上线后），怎么修复的（具体的修复方式），怎么防止类似的漏洞的出现（一些tips），3.Code Review时的一些记录，比如：代码优化的方案，一些争论点...
那么，小伙伴可能会问，记录这些有什么用呢？
我想说的是，长时间的记录积累肯定是有用处的，首先，第一点时间分配，你可以在拿到模块需求后，快速准确的给出完成这个模块的时间，包括设计，开发的具体时间，这样你的Leader可以在程序没开发之前就很好地掌控各个时间节点，可以有理有据地和客户定下产品各个阶段的交付时间，第二点逻辑漏洞的记录，这个可以结合第三点Code Review一起来说，在review别人的代码时，你可以参考他的逻辑漏洞记录，看看他有没有犯类似的逻辑错误，有很好的的参考价值，当然逻辑漏洞的记录也是要不断更新的，比如一个逻辑漏洞已经很久没出现了，我们就把它划掉，新出现的当然也要更新记录的，尽量做到与时俱进。
一句话总结：Practice makes perfect，大家一起加油吧！Stay Tuned...
