时光荏苒，如果从大三时候在北京开始实习算起，这已经是我作为一个程序员的第四个年头了。重读加入现在公司以来的年终总结，感受自己的变化还是挺大的。在这里晒晒自己的心路历程，欢迎吐槽。
这是我入职第三年（刚刚过去这年的）总结（2015，有删节），2016我会更努力的成长。
2015 年度总结
2016年1月6日
从加入公司到今天，刚好是两年零五个月，时间过的很快但很充实。相比往年年终对于一年一年逝去的感慨，今年倒是更多了些平静。在一个较短的时间内，回顾这一年所发生的过往，在回忆转化为文字的过程中加以简单思考，就是下文的目的。
今年上半年，我主要在迭代和客户问题这两个方向上同时学习和工作。8月，脱离迭代开发后，专职从事客户问题和POC的处理工作。12月中旬开始，全职参加GG 2.0的初期准备工作。这一年，也尽力为Team培训了几位新人，ZZ、HH、GG、YY和SS，简单地协助其他同事辅导了TT等新人。
- 回顾年初目标
首先，回顾一下年初时所给出的目标。
- 完成国际化工具，使其成为一个广泛使用的实用工具。
- 进一步熟悉MM逻辑，完成MM代码重构工作。
- 进一步熟悉GG，更加有效的完成CI和POC的工作。
- 深入学习.NET MVC框架，完成AA原型的编写。
- 继续学习Bootstrap，整理出一份较为完整的前端编写规范，并继续提高自己对前端技术的掌握。
对于目标1)， 这一年我一直没有完整的时间去全心完成这个改进，好在10月份的时候有一些空闲时间，所以把原来代码中关于JJ部分的API封装全部抽离，并重新封装了一个JJ Wrapper项目。这些主要是一个基础的结构和基本API的示例，后来由刚刚入职的新人YY进一步测试并拓展封装了JJ的主要功能。虽然后来没有更多的时间继续把这个API应用回国际化工具里，但是只要再有时间，这不会是一件难事了。
回想入职以来的这些小工具，很多是断断续续的，但是这也给新人带了一个好处，这些工具成为了一个有效力的玩具，帮助实习生可以在入职的初期就去逐步适应较大规模代码的开发工作。这包括SVN的操作、如何适应一个包含特定模式的代码结构（学会如何去看别人的代码），以及一些今后可以用到的基础技术（比如REST API、WinForm等）。同时，在一个又一个新人的推动下，这些小工具项目，也成为他们之间的一种隐性的传承。
对于目标2) MM在GG 1.6中添加的MM INBIN功能，通过这个功能的添加，MM的后台整体读取和调用已经被聚合，同时这部分代码采用新结构编写，也是希望能够作为一个新结构的推动力量。而针对前台结构的重构，由于时间所限，这并没有实现，不过由于其他同事的努力，MM又增加了一套全新的更合理的前台结构，虽然没有全部取代以前的前台结构，但从推进的角度来讲，也是一个很好的改变。
对于目标3) 是今年的一项主要工作内容，这是一个逐步适应的过程，自己觉得做的并不够好，所以也只求个人对于POC、CI方面的工作能为Team缓解一些压力，而非增添压力就好。
对于目标4) 和5) ，都是针对技术的学习，目前对于Bootstrap的理解还不深入，而AA原型的编写则处于相关文档的整理阶段。这两项都与未来GG 2.0的开发相关，也是当前和今后学习和努力的主要目标之一。对于前端开发文档，目前已经基本整理完成，期待稍后能有更多开发人员的加入，以添加更多的实际场景。
- 新人培养
- 关于实习生的培养
今年的工作从总体上看，培养新人所占据的比例是很大的，在这个过程中我确实体会到了很多，对很多问题有了新的认识和想法。抛开具体的时间点或背景不谈，回顾起来，对于新人培养的方式，总体上是逐步的走向模式，又从模式中逐步走出来。不过总体的原则并没有变化，我的目标就是尽力为新人在初期建立起比较明确的核心价值，培养好基础，并尽快做出成绩，提升主动性。
ZZ从14年11月17日入职，到3月23日离职，一共在公司实习了4个月的时间。不过现在回头想想，感觉他在我们这儿的时间仿佛有一年一样。ZZ是我在咱们公司第一个完整带的新人，从带他的第一天开始我就尽我所能，希望能把所有会的东西都交给他，从最基础的方法、类开始，再到Web、HTTP。虽然他是DLHS大学的实习生，但只论技术的话，他的基础并不能称为优秀，没有Web的实践经验，甚至对OOP也有些认识不足。不过可以感受到，他在为人处事上是所有我带过的新人中最聪明、最会做事情，也是最为圆滑的一个。这种圆滑不是贬义，而是夸他把握的比较适度。同时，他也非常明白我对他严格要求的苦衷，能够理解别人，所以在工作上也非常配合。因而，在他离职前，他所写的日报质量、培训成绩以及在实习期间完成的工作，都是比较令人满意的。
当然，从另一个角度来看，他的聪明主要体现在他对于自己的事情都是很有规划的，而且非常勇于决断。前一点是很多新人没有的优点，绝大部分的新人都需要导师为其详细的规划步骤，甚至很多新人对于这些规划并不能理解或接受。而后一点，则是我所缺乏的，果断，不犹豫，抓住机会，这也是在他离职之后我思考最长时间的问题。
和每个新人交心，尽可能的建立信任，尽可能的多沟通，这不仅能够更多理解他们的特点，也能更多的把握他们想法的趋势。对于ZZ的突然离职，我确实感觉有些不知所措，但是并没有感到一丝的意外，也没有感到难过。其实很早之前我就从他那里得知，或者意识到，他不会在公司干的很久，他有自己的雄心，他希望能去一个有更多机会的平台，他想一步一步的攀爬，而我们公司只是他的第一个台阶。他曾表达过不会在我们公司做很长时间，可问题是，虽然当时我意识到了这点，但我依然固执的认为，他会出于我自身的投入，以及个人关系的维系，可以确保他能在一定的时间里留在这儿。这是我的错误，我不该把工作依赖于个人关系，不应该过多的把精力放在一个篮子里，我没有把握好度，而是选择了全情投入。
ZZ选择了北京，去了QUNAR网，他没有忘记我们这里，这些是我最大的欣慰，所以我没觉得任何失望，而是对他满心期望。
说到机会，我觉得哪里都是有机会的，每个人面对机会的想法不尽相同。一些人可能太过关注机会，把机会当作了工具，把生活当作了爬山，拾级而上，彼此攀比，总希望能到一个更高的地方，可一山总比一山高。就我看来，机会可以是自己创造的，也可以是别人给予的，事在人为，所以我更看重的是方向。生活不是爬山，而是向一个合适的方向不断探索。为一件自己喜欢的事情，或者为了做自己喜欢做的事情而不得不做的事情，然后把每天一半的生命投入其中，创造或改变，那这就是值得的。
对于ZZ的培养套路逐渐演化成为一种模式，严格的日报要求，严格的新人作业质量要求，培训期间同时完成一个小工具的维护及编写，侧重扎实掌握技术基础，要求时刻清晰地认识自己所编写代码的意义，等等。同时，对待新人的投入也变成一种模式，初期尽力纠正对于一些概念的理解，对于学校不理解的东西尽力弥补，尽力在认识上加强培养，树立自己的原则。总之，就像BZ哥曾经说过的，每个新人都是一样的，都是张白纸，看你怎么培养。我同样依照这些准则面对下一个新人，HH。
从5月4日HH来到公司，到9月1日他提出离职后被调转部门，又是4个月的时间。和他相处的经历，对于我来讲仿佛是两年一样，我让他在我们公司重新上了大一和大二。这位新人不知道通过我们公司在哪个学校的哪次招聘通过哪位领导的哪种漏洞被哪样的选入！不过，从当时的场景来看，我只想一心依照领导期望，认真把每位新人带好。我依据他的特点，开始努力尝试各种方法来诱导他，这个过程我就不讲了，我相信当时坐在附近方圆20m范围内的每位同事都是了解的。
实话实说，HH的部门调转对于我是很大的打击。一方面，我没想到，这么长的时间，从一个for循环都写不明白、基本没上过大学、已经不会看书学习的新人，到可以基本写一个包含前后台的“打地鼠”游戏的新人，我花了多少精力？跟他谈了多长时间？他连这些都认识不到，竟然选择离职，竟然在提出离职之后又反水选择调转部门？但是，站在今天回看，HH的问题，我有三大错误。
首先，我把所有新人都当作是一张白纸，都是可塑的，认为谁都可以被改造，被影响。这种片面的期冀忽略了现实，而这种期冀也绝不能让Team的效用得到最大化，只会白白浪费资源。万事除了其辩证的两面性，还有其核心的本质属性，好与坏的本质。明知无力回天，却还不把主要精力放在正确的地方上，这是无效的。
第二，我太缺乏果断，发现苗头没有尽早除掉，而总是期冀未来，在一次又一次的现实之后，仍然没有下定决心，没能在最好的时间点做出果断抉择。
第三，在一些情景下，不能在思想上快速的改变大策略，没有学会物尽其用，完全被一时之气冲昏头脑，没有冷静的做出更好、更明智的选择。
在带HH的同时，由于TZ出国，于是就帮忙带了新人GG。从工作的角度上讲，这没有给我增添多少工作量，有了GG也能让HH增加一些紧迫感，有个比对。GG的执行力非常强，和HH有着鲜明对比，让他学啥他就学啥，只需要点明方向和计划，执行不需要监督，工作很有节奏感、很清晰，执行完成就会非常及时的给出反馈。我个人觉得GG的潜力很大，也希望他能有更多的机会和平台来展现自身的能力。当然，另一方面，对于他，我更多的是一些愧疚，虽然形式上我也与他有着很多交流，但是我没能把心里的关注更多的转向他的身上，而在HH调转之后的一段时间里，我也没有很快的重整心境，把更多的关注给予他，在这些问题上，我做的非常有缺失，也是一个很大的失误。
在这个过程中，还协助辅导了ZK，这个主要是在毕业设计上。5月是今年最忙碌的一个月了，当时既有迭代任务和Bug（MM INBIN），又有一些CI问题，还要帮ZK处理毕设，而最最忙碌的这些基本都发生在两个星期之内的。通过这件事，一方面我算是体验了一把“极限挑战”的感觉，另一方面也确实需要我们关注实习生毕业设计的问题，ZK在毕业之后就选择了离职，而其他新人也同样都有这类考虑。是自己去写还是尽早去买，作为新人导师，应该提早给出引导。
通过HH的事情，我对新人培养方式的理解，从之前的模式中逐步走出，我明白了对待每个新人一定要有不同的态度，不同的策略，不同的期冀，我不是baby sitter，那不是有效力的选择。对于新人的培养，我总结起来应该既追求慢慢来，又追求尽快表现效用。“慢慢来”是希望新人能够从根本上提升自身的素质，这包括个人的基础技术能力，在团队中的定位和沟通能力，以及对自身性格的强化或弱化。这一点因人而异，不是谁都能接受别人所限定的模式或者道路的，也不是每个人都可以简单的归为一种模式或者道路。同时，这一过程的执行，也必然是点到为止的，我所扮演的角色，更应该是在大场景下，对一些关键点或者阶段性的指引者，而非baby sitter。这些非常需要我去注意，当然，在这个渐进的过程中，对于新人最初的阶段，不可能不给予更多的关注，每个新人的培养都需要一个初期的适应和道路选择（发展道路的选择不是姓什么的问题，而是方式的选择）的阶段，而这个阶段需要我们花费更多的时间、精力去体会。
而“尽快表现效用”则是希望与公司其他的新人相比，更早的表现出自身的进取心，并将其培养为一种习惯，早点拿出“成绩”，早点体验“成绩”，早点进入工作的良性循环里。这也是为什么我对于以往每个新人，都要求他们在初期去完成一个小工具、小玩具，而非尽早进入项目的原因，只有体验到了这种成绩所带来的成就感、认同感，他们才有更多的可能去发掘自身的主动性，然后基于此，去主动进取，主动工作，主动考虑留在这个公司，或者留在这个行业。这一点，并非在每个新人身上都能实现，HH没有实现，他没有在长期做好这种准备。GG实现了，也许更多的空间能让他给Team带来更多的可能性。ZZ实现了，但没能让他留下来，他曾跟我说，在北京经常凌晨2点下班，他感觉累，但却实实在在，他选择了自己的路。我没法给他们做选择，但是我们可以影响他们，从结局来看，也许不是所有新人都能留在这，但是这些走出去的新人，一定不会是不认同我们的。
也许，这种培养新人的观点显得理想了，但我觉得至少它与一些无为而治的观点相比，是对立的，务实的。面对TT、YY和SS，我努力地去适应并改变。他们都是我上大学时学校实验室的学弟学妹，能和他们仨在同一个Team下一起工作，也算是一种机缘巧合了。我非常期冀于他们在新的一年能够成为有效力的成员，展现出各自的能力，也为自己做出成绩。
- 新员工培训
今年，继续为新入职员工进行“III”课程的培训，通过批改他们的作业，我发现随着时间的推移，新入职员工的作业质量正在不断下滑，原来对于技术的追求，对于问题追根溯源的态度也在渐渐消失。
究其原因，一方面个别部门对于新人作业的要求显得急功近利，按时交作业成了唯一的要求。为了能按时交作业，新人的导师允许新人抄袭作业，从而导致新人很多基本的知识点被跳过。目前，绝大多数来到咱们公司的新人在校或在职期间，并不是.NET方向的，对于C#的了解并不充分，培训可以让新人有效的进行一些语法、规范上的转换和适应。个人觉得，这些初衷已经被少部分人背离，与其这样应付，不如节省些时间允许这些部门自愿放弃新人培训转而自行培训好了。
当然，付出带来的回报有时候会是惊喜，下边这封是我这一年收到的唯一一封让我感到无比光荣、欣慰和振奋的邮件，我感觉非常开心，每每重读此邮件，总是充满动力。
- 回校招聘
十月，应GG哥要求，我返校为公司招收一些实习生，这些同学都基本限定在实验室的范围内。重回实验室，分外亲切，我在那儿度过了人生最美好的四年。由于大四的时候就见过这些同学（当时他们是大一），所以沟通起来很顺畅，很开心。最后一共有14位同学参加了公司相关的笔试、面试。通过这次招聘，最终有5位同学加入了公司，其他同学有些是由于自身原因放弃了职位，有些则是由于自身技术的缺失而没能通过技术面试。
针对招聘，我建议公司应该注意时机，如果过早，在校的同学可能都觉得不着急、不愿决断，过晚则会让很多好同学进入其他公司。所以可以考虑进行多次宣讲，逐步渗透。先通过大三期末的宣讲，把一些工作上的事情讲清楚，简单对公司做个介绍，让大家对“工作”、“北上广”有个概念上的认识。而在大四的九月初和十二月末进行一大一小的两次宣讲，分别针对主流同学和考研失利的同学，这样不仅可以提高招聘的效果，也能以此加强公司在各个学校中的声望。
- 迭代开发
今年参加了GG 1.6和1.5.2的两次迭代，期间主要针对MM INBIN、TM、MS Report等功能进行开发。在迭代开发的过程中，深感全新功能的开发要远远比更改原有代码容易得多，我这边几个功能都是基于新结构进行的全新编码，而对于已有功能的耦合则是依仗了很多老迭代开发的鼎力相助。在大家的帮助下，新功能在各个Service的应用容易了很多，相比刚来GG的第一年，一切都自己傻傻地抠，要有效了许多许多。
对于刚刚投入迭代或维护的新人来讲，不要轻易尝试更改老代码的实现，一定要努力设计新代码的实现，这是我个人的建议。对于老代码，简单的重构并不能解决问题，以1.6版本为转折点，目前GG核心代码已经稳定，肆意的更改代码结构很可能会导致产生成片的bug，不过这并不是主要的问题，主要的问题在于目前并没有足够的时间来完成这些bug的修改，很多问题被遗留下来，成为产品的CI，并且这些CI将在每个客户身上重演。而结构的大范围改动，势必会给CI Team带来巨大压力，尤其是在面对客户升级的情况下。按照现有对于客户升级时间的预估形式，结合新版本的大改动，将客户的自定制POC或环境定制迁移到新版本的代码分支上，工作压力、测试难度都有很大增加，而升级包的质量也势必下滑，导致经常重新发包，影响客户信心。对于1.x的代码，重构或改进的工作是非常必要的，但是不能看到哪改到哪，最好能总结问题产生的原因，如果是逻辑定位上的原因，则考虑能否在今后的大版本中给出全新的设计。如果是代码结构的原因，最好能成块重新实现部分代码，尽量避免简单直接的改动。
对于新功能的编写，一定要多想、多沟通。MM INBIN功能就是一个例子。这个功能经过多次与PM和QA的反复讨论，一次又一次的明确需求和可能性，尽可能的把握住细节而不急于编码。我个人的感受是，在开发期间，讨论的时间可能占用了2周多，而实际的编码可能只有3、4天，另外有2天用来整理文档。明晰的逻辑和数据结构是保证一个模块今后出现更少问题的前提。而适当的文档则会有力地协助其他同事对于新模块的维护。对于GG 1.x上的新功能，我只能期冀每个人都能更多思考。
此外，对于MM而言，遗憾的是由于Team迭代期间的资源紧张，虽然完成了对MM后台代码的整合，但是没能将其应用到所有模块中，也没能去掉那些冗余、重复的代码，期盼后人能够早日在1.x上解决MM的剩余问题。
- CI与POC处理
来到GG至今，一共协助Team处理了83个客户问题，做了几个简单的小工具（GG CI Tool、GG SQL EE Tool等）。
首先，处理CI对我英语的阅读和写句子的能力提升很大，这是最为直接的感受。现在读英语文章的时候，绝没有刚来公司时候的那种吃力了，由于一直坚持仿效LL哥，写英文Comment，虽然有非常多的语法错误，但是随着时间的推移，写句字已经不再是一个问题。特别是直接写英文Comment减少了Project Team同事的工作量，这也让我和很多Project同事更加熟悉，她们也成了我的英语老师，反馈了很多我的语法问题。另外，在处理CI的过程中，我还有机会和国外的Support同事通过Lync进行交流，虽然没有直接语音对话过，但是，从第一次根本不敢一个人和外国人打字（必须把LL哥也拖到群里），到后来，喜欢上和外国Support打字对话（特别是我们的日本和法国Support，因为他们的英语和我一样不好），这很令人开心。
其次，经历的这些CI，也让我逐步掌握了处理GG CI的经典步骤。来了问题先要读明白客户的遭遇，然后查看JJ所给的信息是否完整，不完整则立即打回（这种Case还是比较常见的，我们的Support有时确实很随意，总会看到只有一句话的JJ）。随后，查看Log中的异常信息，看看是否在以前遭遇过，是否是已知问题，确定是否和客户的环境信息有关，是否跟最近的Hotfix有关，确认是不是客户的操作有误。如果没有结果，则根据Log中的异常信息搜索整个GG解决方案，找到抛出异常的位置，分析前后代码，推断可能性。然后马上去找对应开发，各种明确逻辑。如果根本没有日志，那就得靠猜想了，如果各种尝试都没能让问题在我们自己环境上重现，那就只能来一句“Sorry, we can’t reproduce current issue, please help us to start a WebEx session with our customer for further investigation.”然后约WebEx，客户不约或者约了没解决，那就出诊断Hotfix，一方面让客户知道我们在努力解决问题，一方面也能为缺乏Log的GG回回血。一句话，有效地解决问题是核心。
回头来看，这一年所有处理CI的经历都是无比珍贵的，这不仅仅是如上两点略带玩笑性质的论述，更多在于体验一种更切客户实际的场景，了解客户们究竟想怎样用GG，究竟他们在使用GG的过程中遇到了什么问题，我们以后在开发的过程中，一定要更注意什么。
另外，实话实说，同LL哥和QQ哥的CI相比，我处理的问题无论在数量还是难度上，都是绝对无法相提并论的，CI Team的艰辛我深有感触，LL哥和QQ哥付出的努力，不是一般人能做到的，我要感谢这段时间他们的照顾，希望以后能更多的回报他们，回报这段难忘经历。
而对于客户POC的开发经历，则与处理CI有非常多的相似之处，这里我感觉最重要的两点是预估时间，和开发态度的抉择。
POC的预估时间并不能总是可以按照实际来给出，开发和测试Team在评估后，总是会对具体的数值进行多多少少的剪裁，让这些数看上去更“合理”些，同时，给出预估的人未必就是实际开发的人，每个人对于相关模块的熟悉程度各有不同，所以会导致一些POC的实际开发时间被延期，所以，个人感觉，预期之后延期让客户有违约感，倒不如在给出评估的时候就多要些实际开发时间，不能过分客气。
另外，开发态度的抉择也是一个不得不思考的问题，很多时候我们在POC开发之前总想着一定要做好，不能再编写低质量的代码了。但是，一旦我们投入实际的编写，在遭遇一次又一次挫折和加班后，我们开始不断退却，只求尽快结束这个梦魇。这个情况是很难避免的，我们没法简单的在一定时限内改变环境，更多的只可能是被环境所左右。关键是，对于POC的我们如何选择在今后把他们Merge回产品之中，这个过程是否包含了谨慎的重审，还是，这只是一个拷贝代码的过程？至少对于我来说，之前Merge代码的过程就是闭眼拷贝的过程，一些功能我根本不知道他的作用，只知道通过谨慎的代码拷贝，可以通过QA的测试，我的工作就算是完成了。这很可能就是不稳定代码的一个重要来源。
其他方面，今年还对TTTT这个大客户的定制需求进行了前期设计调研。这主要是基于SCS进行的，通过这个过程，对于GG如何有效的适应Multi-Tenant场景进行了学习和思考。此外，在客户问题处理及POC的开发过程中，与QA Team的协作也是极为重要的，至少就我而言，很多逻辑并不熟悉，都需要通过询问我们的测试同事来进行了解。这里我想特别称赞一下我们的QA LP，她工作认真仔细，对待问题追根溯源，也愿意热情地回答我们这种开发的问题，是同学们学习的好榜样。
- GG 2.0挑战与愿景
从12月7日起，我开始全职从事GG 2.0的前期准备工作，工作主要在升级和Service组织结构这两点上进行，并参加了几次对于GG 1.x 需求的重分类讨论。
回想去年年终总结的最后，我添加了一个大长SQL作为附录，这个SQL一方面是为了揶揄下当时的Report模块，自嘲下自己，表现下无奈，另一方面也是想阐明对于改变的急迫期待。其实，每一个GG同事都有这样的想法，谁不想让自己天天为之工作的项目更好呢？从根本上来说，2.0项目就是在大家这种期待中产生的。但是，我个人觉得，2.x绝不是对于1.x的重写或重构，而是重新审视1.x的需求，重构逻辑，重新设计。GG 2.x并不与1.x冲突，在一定时间内，两者一定是并存的，而且1.x很可能（也很应该）会继续得到发展，2.x是基于1.x已有的Case，没有1.x在前期的积累和探索，是不可能有2.x的未来的。
对于JJJJ，现在有的只是期冀，面对漫漫长路，真心希望每一位参加GG JJJJ开发的同事，都能够投入其中，把自己的想法融入产品，不要只是把它当作是一份工作，把新GG当作自己的孩子，视如己出。以此建立一种氛围，每位加入JJJJ开发的同事多多沟通，多多思考，付出真心和努力。我坚信，如果我们努力的得当，产品方向把握的合理，新GG一定不仅可以解决以前的很多问题，同时，也极有可能成为我们公司今后最有发展潜力的旗舰产品。
- 其他事宜
今年4月我参加了公司一系列TS的培训课程，主要是QA及IT相关的课程，在这个过程中，我学到了很多关于服务器的配置、维护内容，感觉还是很有用的。但是，个别讲师也确实存在准备不足的问题，特别是AD FS等课程，讲师的准备实在欠妥。真心期盼讲师能够更多的重视课程，也希望培训结束之后可以增加对于各个讲师的评分评价，以作为一种培训质量的反馈，让那些认真准备培训内容的讲师得到更公平的环境。
5月中旬，参加了公司的SSS培训，虽然我没有参与过任何SSS项目，但是通过这个培训，我切身感受到了所谓“产品”与“项目”的不同之处，并见闻了我们公司刚刚投入SSS项目之时遭遇的种种问题。这些问题实战性极强，虽然今后的一定时间内不会为自己所用，但是真心期望这样的培训和讨论能够更多的举行，让我们更多的体验到除了代码以外，贴近客户、贴近商业的感觉。
- 明年的目标
2016年的目标只有一个，全力以赴做好新GG，这比什么都重要，也希望由此，充实地度过我在我们公司的第三个年头。
以上就是我对刚刚过去的2015年的一个总结，我没有像去年一样，按照月份进行回顾，同时很多篇幅也都被聚焦在了人上，而关于迭代、CI工作中的见闻或感想并没有太多的提及，一方面是因为这些内容很多我都已经总结到GG JJJJ的OneNote记事本上，另一方面也真心觉得，工作而已，很多都是已经习惯了的流程，所以没有在此详述。
最后，祝各位同事在2016年一切顺利，身体健康，也期待我们的GG越来越好。
