时间是一条永不止息的长河！对于渐行渐远的2013，依依不舍吗？试着挽留吗？又想要留住点什么？翻看自己的工作笔记本，纷繁芜杂的写了有近两本，试用期的日报以及之后的周报，合起来也有近50页的word文档了。可能总结一下经验教训，展望一下姗姗而来的2014是最好的告别方式！
来到公司刚好半年的时间，虽然之前从事的也是软件开发的工作，但所做的都是电信相关软件的开发，来到激光行业可以说是“转行”。除了写软件的一些通用语言和算法，基本没什么相关性。一切都要重新学习，从激光行业的各种概念、术语，到相关机器的操作，板卡的的安装，信号的测量，测量设备的使用……。业务上的尽快熟悉是融入团队的重要一环。对于刚入行的人来说，有一种“空杯”的心态十分重要，在遇到不懂的东西时，除了自己努力找办法解决之外，及时请教同事、领导也是必不可少的。只有这样，在把遇到的问题一个个都解决之后，个人才能成长；再者就是部门的氛围以及同事间的沟通与交流，融洽的同事关系，积极向上的氛围，不仅可以增加个人的归属感，对提高工作效率也是十分有益处的。在这里十分感谢数控部的同事们，这里的氛围是我非常喜欢的！
这段时间，我的主要任务是负责MM打标卡的功能完善和Bug修改；另一个就是把MM分支的更新代码移植到原来的SmartScanner中。就功能完善和Bug修改来说，基本上每个问题的修改所涉及的细分代码块都不相同，这就需要快速的熟悉相关代码的实现。因为如果不清楚相关代码的来龙去脉，根本谈不上修改，即使勉强为之，也有可能带来新的问题，导致得不偿失！这也确实锻炼了自己看代码的能力，感觉自己还是有所收获的！我对看代码的总结如下：首先要找好主题，专注于某一功能的实现，某个类的职责或当前所要修改的Bug涉及的点。只有目标明确了，才能有的放矢。看什么问题都应该从大处着眼，从小处着手，在把相关代码的脉络弄明白之后，再去关注细节的东西。比如看函数，可以通过函数名，大概猜测实现的功能，如果命名规范，并且有适当的注释的话，也就不用猜了；再来看输入的参数和输出的结果，了解函数的前后关系；最后再仔细地来看实现，当看到有调用其他函数时，可以深入进去看，但粒度只限定在一级，即只看被调用的函数本身，对于被调函数中调用的其他函数则直接忽略。因为粒度太细的话，容易把主线遗忘，搞到最后云山雾罩，不知所云！既不利于问题的解决，也不利于自己水平的提高。对于调用当前所关注函数的代码也是这样处理。细想起来，虽然我没有读过某一期《大族人》上介绍的《目标》这本说，但其中阐述的以目标为导向，再运用TOC（Theory Of Constraints）理论找到不同阶段要达成目标所面临的瓶颈,并集中精力加以解决，从而逐步达成目标的观点是类似的。
在全面了解各模块代码的同时，虽然广度够了，但也凸显出一个问题来，那就是对某块特定的代码缺乏深入的掌握！认识的深度不够会带来一个问题，即要对一些功能的完善提出建设性的建议就比较困难，比如说目前的两个功能完善点：首先是回型填充问题。我们现有的算法对有些图形填充出来的效果转角处是尖的，而希望可以处理成圆角，这对加工效率和外观效果都会有影响；再者就是位图扫描算法。我们现有的位图扫描算法是“点阵式扫描”，这是一种比较低效的算法，也是我们打标位图时速度没法提高的根源。效率更高的“准矢量扫描”方式还有待开发。对这些问题的提出和后续的完善都是需要深入进去才能做到的。问题或者说瓶颈已经暴露无遗了，这是需要在今后的工作中加强的。
代码移植工作总的来说还算顺利，碰到的大部分问题都是MFC框架的问题，很多问题都可以在百度上找到答案。比如说“dlgdata.cpp的line 43出错”，那多半是因为控件的ID处置不当导致的问题，只要看看自己最近移植的代码涉及到的控件是否存在冲突即可；“DoModal不成功的问题”首先要怀疑的就是相关的对话框资源是否已经成功添加到了后缀为rc的文件中；还有一个比较典型的问题是，如果移植的对话框与相应的类没有很好的关联起来的话，也会报很多莫名其妙的编译错误，刚开始不知道如何是好，后来请教了一下同事就恍然大悟了！被问题蹂躏的次数多了，不成专家都难！就某种程度来说，我们好像应该对问题与困难持一个欢迎的态度，但当问题真正摆在眼前的时候，特别是比较紧急的情况下，是否还能有一个心平气和的心态呢？这看来是没有一定的修炼而不可达的吧！当然在MFC的道路上我还是一个初学者，要学习的东西依然还很多，对其消息机制还缺乏透彻的理解，界面的制作也才刚入门，很多控件都还没用过，更别说自己定制控件了。
纵观这段时间的工作，有两点是令自己感觉比较有挫败感的。一是打标控制的测试，这一块的测试受到板卡状况，接线，软件的综合影响，只要其中有一块的配合不到位都可能出问题。刚开始接触时简直不知道从何下手！印象最深的就是“YAG激光器测试”，其中碰到的“不出光和光强不够”这两个问题让人纠结了好几天。刚开始一直坚信不是代码的问题，但当把能想到的点都验证完之后，问题依然得不到解决时，内心的坚持就开始动摇了。归根究底，还是测试的思路或方法不当导致的。当内心的想法不笃定的时候，就容易受外界因素的影响，而当外界的因素在不断发生变化时，整个人就会变得像没头苍蝇一样到处乱撞了。这个时候即使撞破了头也是于事无补的！最好的办法就是静下心来，重新梳理一下思路，把流程整理好，一步一步的照着流程来走，一个问题一个问题的排查，最终总能找到问题根源的。经过10月份的测试后，心里大概有了一个排查问题的思路。那就是先从物理的接线，光路状况开始排查，确定这两方面没有问题后，再去看软件，测量信号。用“排除法”步步为营地查找问题的根源。二是PCIFiter相关代码功能添加和问题处理。同时这也是个人感觉比较核心，非常重要的模块，关系到客户使用软件的直接感受和打标效果。到现在为止，对这块代码的把握我感觉只是刚入门，还有一些问题一直没办法真正理解，比如各种激光器的出光时序，相关信号之间的配合，各种激光器的资源使用情况，如IO口，以及振镜的控制等。寄希望于在后续的工作中把这些难点一一攻克。
对于工作上的建议，我暂时想到的有两点（仅供大家探讨）。首先，编译速度慢向来是造成C/C++“程序猿”肾上腺素上升的元素之一！还好，现在有了IncrediBuild工具软件，它是一个分布式的编译工具，可以把工作组里所有电脑的空闲CPU都用上（想想都令人流口水！这多像什么“深蓝”啊“银河”啊之类的超级电脑！），从而大大加快编译的速度，提高团队的开发效率。工程越大，加入开发组的电脑越多，速度的提升越明显！之前的公司用的是VS，不知是否有适合VC的版本。其次，“代码走读”机制能在一定程度提高代码的健壮性。具体来说就是，当团队成员中某人在一定周期（可以灵活确定）内新增、修改的代码量较大时，找一个合适的时间大家一起坐下来，对这些代码来一次全面检阅。这不仅可以杜绝编码不规范，扫除个人思维盲点导致的错误，集思广益地把某些算法做到最优化，还可以加强团队沟通，锻炼个人表达能力。当然，这些不是我的原创想法，很多都是各公司都在用的。思路大概如此，但操作的具体方法就可以很多样化。无论什么制度、措施的实施都需要一定的成本，这些也都不例外，可能会占用一些大家的工作时间，所以具体操作的频率是需要综合考虑的。
斐然与否的成绩都已成过去，唯有继往开来！问题与困难从不主动让道，但我相信有了数控部大家庭的上下齐心，那些都不过是我们前进道路上的一个个台阶而已！一个崭新的春天正在向我们招手，让我们迎着春风，和着美好的祝福，为数控部的做大做强而努力！