公司终于继QQ之后，正式对MSN痛下杀手了！很快，MSN将无法使用了，我们也将和华为一样慢慢进入到一个封闭的世界中了。

朋友们，再见了~~~~~~~~~

配对编程：提供持续的信息反馈和确保正在编程的人进行重构、测试和遵守编码标准，实现代码共享目的。

       初识敏捷开发的人几乎都会被这一打破传统开发模式的新模式所吸引，觉得新奇无比，然而在了解其工作机制之后，很快的就会形成极为明显的两大阵营。我从来没有实践过配对编程，但是我体会到偶尔的两个人一起调试程序的乐趣和优势。然而，即便是有一天我有了决策权，我也很难肯定自己愿意让员工按照配对编程的模式进行开发，因为这种模式是否能够成功取决的人为因素似乎太多太多。没有实践自然没有发言权，依然是转载一篇自以为论述的比较透彻的文章吧(来源：ZDNet)：

配对编程是极限编程里争议最大的做法之一——支持者和反对者对此的反应都相当强烈。那么什么是配对编程？为什么人们对此的反应这么大？

Laurie Williams将配对编程（Pair Programming）描述为“一种编程风格，它由两个程序员并排在一台计算机上工作，连续协作完成同一个设计、算法、代码或者测试”。从上面的描述我们可以清楚地看出，配对编程的含义不仅仅是编程本身的键入，我个人认为“配对开发（pair development）”应该是对这种活动的更好描述。

配对编程不是一个人简单地看着另一个在做什么——在卓有成效的配对工作里，这两个合作伙伴常常工作在不同抽象层次，一个人关注的是为实现眼前目标而编写的代码的细节，而另一个人考虑的是更大的前景和下一步要做的事情，这两个人的角色频繁进行更换。这是一项高强度的、严密的，且常常令人疲劳的活动，但是能够创造出经过深思熟虑的高质量代码。

反对配对编程的大多数强烈反应都源于配对编程对社会上业已形成的软件开发习惯的挑战。

对编程的传统看法是在隔离上花一大段时间，在此期间程序员进入一个“流程”，只与计算机和他们自己的思考模式进行交互。这样做的结果就是，编程往往更受性格内向的人的欢迎，因为这样的人喜欢将社交活动减到最少，而对那些外向的人却吸引力不大，因为他们更希望时时刻刻进行合作。

当然这些都是一般的想法，但是总有不愿意与其他人肩并肩工作程序员，对他们工作的满意度肯定会受到像配对编程这样的事的影响，了解这种情况是非常重要的。

对配对编程也有反应不太强烈的反对，一般都是与让两个人在一台机器上工作所花费的时间肯定要比他们各自独立工作然后合并工作成果所需要的时间多一倍的思想有关。

如果将软件开发的因素限定为编程的时候我们能够输入有多快，这肯定是对的，但是根据Kent Beck的观察，如果情况真的如此的话，我们给每个程序员一份Mavis Beacon（盲打教学软件）就行了。

 

我自己不会盲打，我也从来都没有在面试别人的时候问过他们的打字速度，所以打字速度是我们的主要关注因素的想法是值得怀疑的。然而，软件开发是一项智力活动，它能够从清楚的表达和思想的合作发展中受益，而配对编程在这两个方面都有所帮助。

       另外一个误解是，配对编程成功与否，应该最终由产出的软件的质量来确定。当两个人合作的时候，至少有三种结果：

l         软件

l         对应用程序的共同理解（业务域、设计和实现）

l         技能的转移

这些变化的比例取决于配对的平衡和动态，但是上述所有三者都会在某种程度上表现出来。当一个经验丰富的程序员与一个新手配对的时候，配对产生的软件可能不会被那个有经验的程序员单独工作产生的软件更多，但是这个新手肯定会学到很多关于这个应用程序的知识以及关于编程的基本知识。

将这一情形与两人单独工作相比较——我们可能得到更多的软件（尽管我们可能希望更加注意新手编写的软件的质量），但是我们却没有实现知识或者技能的转移。如果我们让这两个人在同一个小组里，配对编程就是两个人度过共同时光的理想方法。

而另一方面，两个有经验的人可能会发现配对编程里没有什么技能的转移，但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案，而且错误更少。

配对编程的另一个目标是尽可能广泛地传播应用程序设计和实现的知识。

这是通过配对轮换实现的，这样小组配对的每个人都可以通过一段时间和其他所有人进行配对，而且应用程序的特定部分都会由尽可能多的人来解决。在这种环境里，糟糕的代码不会存在太久，因为它被暴露在很多双眼睛下（这就与开发人员代码开发背后的一个原理相似），而且当设计周期到来的时候，小组就会从所有人的贡献里受益，而不需要仅仅依赖某个熟悉应用程序特定部分的个人。

 

配对编程还有其他多种好处：

l         直接的、连续的代码回顾

l         与别人工作会增加责任和纪律性。在有人盯着的时候去偷懒要困难得多！

l         两个程序员具有相同的缺点和盲点的可能性很小，所以我们会获得一个强大的解决方案。

l         如果走进死胡同，配对浪费的时间要少得多，因为其中一个人不可避免地会厌烦，从而希望寻求帮助。

在定期配对轮换的情况下，上面列表里的最后两项尤其现实。当然，做得看起来像配对编程的方式有很多，但是却无法实现，或者破坏了这些优势。

如果不进行配对轮换，那么你所获得只会是编程的小圈子，知识和技术的转移也只会是最小。有些公司将配对编程用作是消灭个人空间（每两个程序员只需要一张桌子和一台计算机，不是吗？）的理由，这只会忽视程序员的人类需求。

希望让程序员一天八个小时都配对工作是不现实的——配对的持续交互带来了精确和清晰的结果，但是这一过程也是耗费精力的，而且（一个人）总是会有开发以外的任务要完成。

实践经验告诉我们，配对编程是提高软件质量和减少开发时间的有效方法，但是它并不适用于所有的程序员，它需要一种经过仔细思考的方式实现才能有效。

这一个多月过的紧张、繁忙，因为年中考核要写总结，因为部门整合要写各种整合方案，因为学习敏捷开发要写心得，因为……总之，各种原因导致每天平均的码字量都在千字以上。一天下来不光脑子累，连指头都是热的。

思考是一个痛苦的过程，因为清醒而痛苦，因为看得清却无法改变而痛苦，为自己的渺小而痛苦，咋办呢？~~~~~~听点音乐、看点电影分散一下心情吧

重构：确保加入新功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试。
作为新员工，入职后的很长一段时间都是在阅读“前辈”们的设计文档和程序代码，在维护以前的项目。这原本是最快捷的学习过程，然而不幸的是我们常常看到的是与实物不一致的设计文档和纷乱、繁杂的代码。代码中的变量常常不知所谓，定义的变量、方法不知道在哪里调用，不知道什么作用。偶尔看到的注释却发现除了里面除了注释是谁增加的，却不知道对应的是哪些修改的代码……越看越糊涂，怎么办？干脆自己重新写一个吧！
我在处理入库的代码时询问提交人某个目录里面的代码有什么用时，得到的答案却往往是“不知道”。生命周期越长的程序，里面的目录和文件越是繁杂，从名称上很难看出文件之间是什么关系，类似以test这样的无意义的名称命名的文件随处可见。
关于重构，是一个相对复杂的话题，通常按照对一个问题的考虑思路是这样这样论述的：重构是什么？为什么要重构？怎么重构？
有本书名字叫《重构——改善既有代码的设计》，专门论述重构，我想自己再怎么写也不可能好过它了，所以推荐大家去看书吧。下面还是为大家说一下当年我们软件开发团队中的一些做法（和测试原则一样，在没有接触到敏捷开发之前我们就已经有意识的在某些方面做一些改进了）：定期进行代码检查，增强代码的复用性
代码复用性的提高势必会加快整个软件开发速度，而代码复用性的提高对开发效率有着最大的积极影响，但是它也能产生最大的消极影响。重复使用的积极影响和消极影响的关键差别可以只用一个词概括，那就是“质量”。如果重复使用的程序达到零缺陷，那么重复使用会产生积极影响。如果重复使用的程序充满了缺陷和错误，那么开发效率会大大降低。我们现在的开发很大程度上是在copy。这不是说我们的工作没有创造性，反而对我们的代码质量提出了更高的要求。
软件检查提高开发效率的同时改进质量，测试一旦开始，有很多缺陷的软件不会被允许交货。问题太多的软件会延长测试过程，同时加大测试成本直到超过项目预算的一半。
对软件开发来讲，设计和代码的预防性检查打下了牢固的质量基础，同时加快测试过程并减少问题的出现。
下面总结了最常见的方法：
 1、走查
    最平常的回顾可能是非正式的走查了。是指任何两个以上的开发人员以增进软件质量为目的所召开的回顾技术工作会议。走查对于快速开发很有用，因为这样可以在测试前就发现漏洞。举例来讲，测试能够发现需求漏洞的最早实践是需求刚被列入清单、设计和编写的时候。走查可以在写设计说明书时，在设计和编写完成之前就发现漏洞。走查可以发现30%到70%的程序漏洞。
2、代码阅读
    代码阅读是比走查更正式些的回顾方式，但仅适用于代码。代码阅读中，写这段代码的程序员把代码清单交给两个或更多的审阅者审阅。审阅者阅读代码并把发现的错误报告给作者。代码阅读能发现的漏洞是测试时能发现漏洞的两倍。这意味着，在快速软件开发时，将代码阅读和测试结合在一起，会比仅仅测试在时间进度上更具有效率。其实，作为新员工在阅读前辈的代码时，一边阅读，一边试着按照自己的理解去做一些修改，看看结果是否和自己想得一致的做法从某种意义上来讲就是重构。
3、检查
    检查是一种正式的技术回顾，他被认为是在整个项目中最具有效率的差错方式。使用检查的方法，开发人员要接受关于检查的特殊训练，并且在检查中扮演重要的角色。在检查会议之前，“仲裁人”发布产品要被检验估算的消息。“审阅人”在会议前检查程序，并且用检查列表激励他们的回顾工作。在检查会议上，“作者”通常要解释要检验的东西，“审阅人”鉴别错误，“书记员”纪录错误。在会后，仲裁人写一份报告说明每个漏洞和该如何处理它。贯穿整个检查过程，你需要收集漏洞的数据，花一些时间改正漏洞，花一些时间再进行检查，以便你可以分析软件开发进程的效率并不断改进它
    和走查一样，你可以使用检查的方法比测试先一步发现漏洞。你可以在项目中使用它对需求分析、用户界面原型、设计、编码以及其他人为的过程查错。检查可以查出程序中60%到90%的漏洞，这点要比走查或测试要要。因为可以在开发周期的早期应用，因此，检查方法被证明可以节约10%到30%的开发时间。一项对大型程序的调查结果显示，在检查上每花1小时，可以避免在维护中33小时的花费。检查比测试有效20倍以上。

昨天经小蛇提醒，查看了一下国家于2008年1月1号执行的“职工带薪年休假条例”，其中重要的内容摘录如下：

第三条 职工累计工作已满1年不满10年的，年休假5天；已满10年不满20年的，年休假10天；已满20年的，年休假15天。
国家法定休假日、休息日不计入年休假的假期。
第四条 职工有下列情形之一的，不享受当年的年休假：
(一)职工依法享受寒暑假，其休假天数多于年休假天数的；
(二)职工请事假累计20天以上且单位按照规定不扣工资的；
(三)累计工作满1年不满10年的职工，请病假累计2个月以上的；
(四)累计工作满10年不满20年的职工，请病假累计3个月以上的；
(五)累计工作满20年以上的职工，请病假累计4个月以上的。

 

当时自己就很困惑，这个“累计”是怎么计算的呢？如果是不管哪个公司只要工作就算的话，目前这个公司怎么知道呢？就这个问题专门邮件咨询了一下公司的HR，结果得到的答复是“因为来公司以前的工作年限不好认定，所以以司龄为标准”，又给劳动保障部打了电话，得到的答复是和小蛇说一样的“累计是按照工作时间计算，不特定具体公司，只要能够通过社保、劳保等证明工作时间即可”。这样看来，公司的确没有按照国家政策执行。此时，我们该怎么办呢？这是一个令人头疼的问题。。。。。

 

 

IT是越来越颓废了，做软件的和水泥的，做硬件的是砌砖头的，好不容易当个项目经理，也是个包工头！

测试：一个功能存在的前提是有一个测试能够验证它，任何有被破坏的可能的代码就必须有一个对应的测试。

以前当硬件环境有限的时候，程序的编写非常讲究效率，对内存的使用都要精打细算。很快的，硬件环境极大的改善，开发工具越来越“傻瓜”，程序员们再也不用精打细算的过日子了，然而渐渐的，程序员的简洁意识也越来越薄弱，所以，内存泄露的问题越来越严重。

我印象非常深刻的就是以前听过一个同事讲过这样一件事情：他们做软包的部门有一次将测试完成后的程序交给外方，结果外方根据他们的测试用例逐一验收，结果当一个操作重复进行了将近500次的时候，程序崩溃了。当外方将这个信息反馈给中方人员的时候，他们的第一个反应就是“这帮人疯了，谁会去重复做一个操作这么多次啊！”，因为他们在测试的时候就是做一次，得到一个结果正确了就算通过了。

测试原则在我理解中应该是敏捷开发中最重要的原则。因为对于敏捷开发，它是欢迎变化的，也就意味着频繁的修改。如果这种频繁的修改没有测试做保证的话，那么最终的结果只能是一堆错误百出、隐患重重的垃圾。这其实也是很多敏捷开发的实践活动没有取得成功的重要原因：在实践中没有抓住测试这个环节，忽视了测试的重要性，或者就是根本没有能力做到符合标准的测试的能力就急急忙忙的进行敏捷开发的实践。

和很多人谈起敏捷开发、极限编程的时候，大家对于结队编程、工作40小时、减少文档这类特点最感兴趣、羡慕不已，仿佛敏捷开发的这些特点才吸引了他们去关注敏捷开发的。却忽视了对测试、重构这些真正需要我们认真思考的原则，一说起测试的问题，他们就会说这些我们现在也在做啊！可是，我们有没有认真地考虑过我们现在做的测试是否全面了，对测试的目的、意义、方法的认识是否到位了？

极限编程中对测试总结了7种类型，来看看吧，我们目前的测试能做到哪些？：

（1）自动化回归测试（Automated regression test）

    运行自动化测试代码来验证当前的修改没有破坏已有的功能。

（2）单元测试（Unit test）

    验证单元级别的代码工作是否正常。

（3）公共API测试（Public API test）

    验证被第三方开发人员调用的API可正常工作，并且得以文档化。

（4）私有API测试（Private API test）

    验证内部使用的API工作是否正常。

（5）命令行测试（Command-line test）

    验证在命令行输入的命令工作正常。

（6）用户界面测试（User interface test）

    验证界面层的功能是否正常。

（7）“狗粮”测试（Dog-food test）

    这里用了一个有趣的名字“Dog-food test”，自己的“狗粮”自己先尝尝！在企业内部使用自己开发的产品，通过这种实际地使用来确保功能正确，满足使用要求。

 

开发人员会有一种长期沉积的观点：测试，那是测试人员的事情！我们虽然要求提交测试之前要有自测，可是我看到的也仅仅是一个自测报告，我们自测的时候是否有测试用例？是否有测试代码？这些测试代码都是否做了很好的保存，以便将来修改程序时能够复用作回归测试？

在以前的软件开发团队中，我们要求对所有的数据层（java程序）都要有单元测试代码，用来测试输出的XML格式数据，并将这个XML格式数据作为接口提交给界面层（javaScript、HTML）测试界面功能，同时还要对中间的业务层（java程序）作单元测试验证业务功能的输出输入。这些都是开发人员自己利用Junit框架编写的测试用例和代码，而所有这些也都跟源程序一样规划目录结构，作为源程序结构的一部分进行版本控制。这些方法就保证了当人员的变动时、当程序需要修改时，通过这些单元测试代码可以有效地保证软件变更后的功能验证。

其实我一直都觉得，无论软件、硬件开发，测试人员应该是有丰富的开发经验，并且要有比开发人员更深入的思考水平。如果进行敏捷开发实践的话，开发和测试人员的区别无非是负责编码和负责编写测试代码的区别，而从编码难度上，两者是没有什么差距的，甚至从思考的程度上，编写测试代码要更想得更多、更深入一些。

可以看出，敏捷开发中对测试的要求如此之高，也就对所有希望进行敏捷开发实践的团队提出了一个很高的要求：我们是否能够有能力将测试提到如此高的层面？我们是否有能力如此之高的测试人员？我们能够坚持无论任务多么紧张，都不能裁减测试的原则？所有的这些问题从本质上说其实都是对长期以来沉淀的观点、思维习惯的一种挑战。因此，敏捷开发与其说是一种开发方法，不如说是一种开发理念，它需要的其实是我们观念上的变革！

简单设计：通过所有测试，没有重复和费解的逻辑代码，简单的设计能保证代码的简单。

       每次在对用户需求的讨论时，最花时间的往往是一些特殊场景下的需求，这些功能需求往往仅占用了整个业务需求的20%，却花费了80%的时间去争论是否需求、如何实现。这就是著名的2/8原则。

       开发人员往往是完美主义者，在开发的过程中精益求精，希望自己的软件一旦应用改动尽可能的少，于是程序的可扩展性成为我们经常考虑的问题。

       一直不能忘怀的是当自己刚入行的时候，在客户现场维护“前辈”们的程序，竟然发现了一段代码是用来实现“复活节彩蛋”的！

关于简单设计原则，自己就不多写了，转载一篇文章献给大家，因为我觉得看的很有共鸣！

       Kent Beck在《解析极限编程——拥抱变化》中为简单系统制定了4个评价标准，依次为（最重要的排在最前面）：

— 通过所有测试；

— 体现所有意图；

— 避免重复；

— 类或者方法数量最少。

说易行难。知道这些标准并不等于说我们已经遵循了这些标准。开发人员并不是喜欢故弄玄虚的空谈家，实干家的精神使得他们视复杂为猛虎，却同时明白追求简单往往意味着设计力度上的百倍付出。在设计时，我们不仅要考虑软件的功能，还要考虑软件的性能、可扩展性，模块间的耦合关系，系统的稳定、部署和更新，版本的管理，系统的安全，界面的友好程度。要想实现简单系统，可谓是蜀道之难，难于上青天！

Do the simplest thing that could possibly work! 这是XP（Extreme Programming，极限编程）人士大声疾呼的口号。还有一个响亮的口号是“You aren't going to need it”。这其中包含的核心意义就是不要为了考虑程序的可扩展性，把目前不需要的功能加入到软件中来。极限编程提倡开发人员不要“杞人忧天”，既然未来的天是否会塌陷还有待考证，不如脚踏实地关注目前需要做的事情，至少在态度上更为务实。虽然，这种做法颇有几分“目光短浅”的嫌疑，然而软件开发人员毕竟不是预言家，未来的功能扩展无法估计，与其花费精力与时间去考虑整个架构的可扩展性，倒不如集中精神对付眼前的需求。我们也许会承担未来因为扩展而承担的巨大代价，但还有一种可能是，在付出了巨大代价解决了系统可扩展性后，又因为系统的变化脱离了预期的轨道，从而导致此前的心血付诸东流。

所以，演进的设计更符合极限编程的核心准则。然而简单并非意味着简易，所谓“大道至简”，自简入繁并不难，化繁为简才真正需要大智慧。我们必须理解的一点就是，所谓的“简单系统”同时还应该保证它的有效性。举例来说，如果我们要开发一个数据库管理系统，按照当前的需求，由于数据库访问并不频繁，我们可以采用按需创建数据库连接的方式，一旦结束访问就关闭连接。但随着该系统使用人数的增多，数据库的频繁访问会使得原有的数据库连接策略成为系统的性能瓶颈，此时，我们就需要修改系统，将原有的数据库连接策略改为连接池方式，专门负责连接资源的分配与释放。

如果我们从一开始就考虑引入连接池，对于之前的简单需求而言，是否意味着过度设计呢？按需创建数据库连接的方式确实简单，但它对于客户的需求而言，是否又是最有效的解决方案？在此刻，或许被指责为过度设计的方案，在彼刻或许又被推许为最完美的方案，那么我们应该按何种标准来评判解决方案是过度设计，还是简单设计？

事实上，问题并不在于设计是否过度，而在于设计的理念。是只做目前需要的事，还是未雨绸缪，想好今后的功能扩展？这个问题的答案还需要实际的项目开发来检验，根据不同的需求，答案会因此而异。最流行的未必就是最好的，极限编程自有它的适用场景，迭代开发模式在特定的场景下也会成为最佳的软件过程方法。

小版本：用最少的代码工作量带来最大的业务价值。

这个原则是意思是为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。

这么一说，感觉这一原则对我们公司的产品是没有什么适用性的，我们不可能让运营商承受这样的高度迭代过程。然而，正如我一开始就提到的，我们学习敏捷开发、极限编程的目的不是为了解决所有的问题，而是开拓思路，防止我们的思维僵化。据我的观察，我们的测试部开发的自动化测试、调试软件就非常适合利用这个原则。客户是谁呢？就是负责生产调试的内部客户。

自动化测试、调试软件有个很大的特点就是：变化快，而对于这个特点，正是敏捷开发理论所特长解决的。目前对于这类软件的管理的强度远远要弱于那些产品软件，一方面是因为这些软件因为在使用过程中需求变化太快，如果按照公司的规范输出各类文档，并且按照常规流程管理的话，无法做出及时地响应，会影响工作。另外一方面，就是开发人员的主观因素，常常这类软件都是开发人员在生产线与负责生产调试的人员即时沟通即时修改的，这样的习惯也就导致了习惯成自然，我们的“客户”养成了习惯，开发人员也被迫养成了习惯：开始的时候开发人员往往想反正软件改起来也要比硬件来的容易，那就改吧，一来二往，突然有一天发现自己突然陷入了一个泥潭。

作为技术部的配置管理，我就多次发现这些自动化的测试、调试软件版本混乱的情况，而且从使用这些软件的人员反馈回来的声音中，我们也可以听到对于软件质量方面的抱怨。这就是我说到的“泥潭”：作为开发者，自己每天疲于修改，却无法得到“客户”的认同，这是一件多么让人郁闷的事情啊！

那么我们是不是可以考虑利用敏捷开发的方法来解决这些问题呢？或者，通过一种思维上的启发来“创造”一个适合我们实际情况的方法来解决这些问题呢？我想到了一些改善的方法：

n         增加小版本信息，在软件运行中就能够看到大、小版本信息。

n         增加在线更新功能，这样无论身在公司何处，只要能够连入内部网络，就可以及时、准确地更新程序。

n         增加版本检验功能，根据需要检测版本是否需要更新，以此来保证当需要时，保证所有的客户端都运行在一个基准之上。

n         增加错误反馈、日志功能，保证当错误发生时能够通过邮件将必要的信息反馈给开发者。这样可以防止在问题反馈时问题无法复现或者反馈人说不清楚的情况。

这些方法其实都是我们在很多软件中能够看到的功能，并不是什么新奇的技术，实现起来也很容易，而且我们可以将这些功能作为一个公用模块来保证不同的自动化测试、调试软件不用重复开发。这些功能的实现将会让你体会到更多的方便。

有了这些基础，我们就可以在软件开发的过程中将高迭代过程变得更容易控制、实施起来的效率也会更高，效率提高了，时间节省了，才能有条件去思考、去改进。就如同我们的胳膊自由了，呼吸顺畅了，才有可能将自己从泥潭中解救出来一样。

周二的时候在公司的论坛里发布的关于敏捷开发、极限编程的“火种贴”。当天回帖的人并不多，本来以为公司因为不是纯软件公司，可能没有多少人感兴趣。

没想到，今天有人响应般的也贴了一篇敏捷开发的帖子，甚至还号召成立敏捷开发兴趣讨论小组。甚至还发来了邮件询问，大概计算已经有不下20人对这个讨论小组有兴趣了。

虽然不知道这个火种能够发展成什么样子，但是至少自己去实践了、去努力了。我一直认为：敏捷开发、极限编程不是我们IT开发人员遇到种种问题的终结者。我们需要的是一种新思路，什么方法、理论其实并不重要，但是如果思想陷入了僵化，那么绝对是可怕的！

 

7月8日，是发证日。不过懒得到现在还没动过车。。。。。。

赶在出差之前，终于考完了驾照的最后一门考试：路考。而且很庆幸的没有抽到夜路。

顺利的话，再过10天左右就可以拿到驾照了，也就算是熬出了头，结束了漫长的考照过程，四个月的时间，请了N次的假~~~~~~~~

安全注册工程师的考试今年因为误了报名时间也考不成了，今年考不成，去年考过的两门也白考了，看来这条路终究还是不能成为我的方向，算了，放手吧

接下来的目标是什么呢？公司学院的人问我愿不愿意去当专职讲师，心里有些活动，起码自己前一段的努力别人看到了，认为我是有价值的，愿意要我，这一点很重要！

同事还推荐了去海外（巴基斯坦）做工程项目经理，年薪25万的说。。。。。。

机会很多，考虑再三还是决定：忍

 

因为，自己手头的工作也正进入到最关键的时刻，就像怀孕的宝宝即将出世，希望自己的努力能够被认可，再给自己一个机会！目标嘛，暂时不可说：）