标签归档:总结

平淡走过的2009

每次写年终总结的开头,我都很俗套地说“时间过得真快”或者“How time flies”,不过今年我貌似高尚了些,我不想发表这样的感叹。仔细一想,其实时间还是那个时间,只不过今年在平淡中度过。

工作半年后,一切尘埃落定,工作上趋于稳定。每天按部就班完成客户布置的任务,或紧或松,算是比较有规律。自己一点一点朝着目标前进,逐渐适应与客户电话,逐渐适应团队合作,逐渐适应渐渐压上身的管理任务。如果说前半年是技术入门和基本工作习惯的养成,那么整个2009便是默默地积累经验。从一开始只会埋头写代码的小伙子,慢慢变成一个会考虑项目周期,思考团队合作的工程师。这当然要感谢我的技术主管给我这个机会,不断的让我在实践中成长。

在“相信自己,勇敢面对”的2009年全年主题映照下,我厚着脸皮跟客户在电话中说英语,如履薄冰地给客户写邮件,心里有底没底地做项目计划,为了2个星期的任务虚心地向大牛学习C++,将自己积累的微薄经验小心翼翼整理成“谁动了我的代码”系列博文,利用周末整理团队宣传PPT,在新人面前有条有理的讲解团队文化和特色,以带人带心的企业文化为指导来训练新人。我相信,经过我的努力,团队会一天一天变好。

团队的发展中自然有“新陈代谢”,随着老人的退出,新人也就逐渐从后备成为主力。这其中会有个工作移交的过程,一个没有经验的新人代替一个有经验的老人并且要求马上上手工作,就像是水池中一边水高一边水低,把中间的隔板抽掉,两边的水融合会产生一个比较大的激荡。幸运的是在我和同事的努力协调下,这个激荡显得不太明显,甚至客户都没觉察到。当然人的离开除了工作上的影响还有就是感情上的影响,毕竟是一同征战一年多的战友,突然的离开也会给情绪上造成影响。于是这平时隐隐的浮躁便再度爆发一次。

浮躁给人最大的坏处是不能沉下心来做事情,甚至无法做任何思考。在我记忆中,大三时期放弃考研后产生的浮躁,让我不得不一度离开学校去电信企业给人修宽带。我相信浮躁是因为感觉上没有事情做(事实上可能有很多可做的事情),于是开始无聊,想象力丰富的人便开始尽情想象。于是当时读大三大四的我只好出去打工来充实自己,从而来克服浮躁(打工经历确实让我收获到许多)。这次浮躁的解决,还得感谢我的技术主管,那次跟她在MSN上将自己的浮躁爆发出来。她给我两个选择,离开或留下。站在十字路口的我,突然意识到自己还是个资历尚浅的人,突然意识到身边的人和事还不够好,同时责任心让我不能选择离开。也许是浮躁爆发出来,也许是面前的十字路口场景,让我当时彻底决定沉淀下来,因为我还很嫩。

沉淀下来后真的发现周围很多事情和人都需要改进,这之中必定要站出来一个人主动地改变这一切,而我就要“相信自己,勇敢面对”。改进总要有方向,在我们团队和总监的讨论会中,也分析出了我们的弊病是“生产率不高”。既然如此,2010的目标便是让我们更好更快的工作,去掉一些冗余的流程和不必要的东西,快乐高效的工作。具体怎么做便该好好想想了。

说了这么工作,确实是因为工作占据一年中大部分时间,而生活便是精彩的点缀。

十月三号,中秋节,我10分钟的篮球激情转化成一个月的卧床生活。在家SOHO 一个月,确实感觉到信息化工具的发达,让我们自由自在的国际化着。还有一个收获,我便知道什么是骨折了,再也不会拖着一条以为是扭伤而实际是骨折的脚暴走几公里的路了,想想我当时还是挺坚强的,有当特种兵的潜质。

个人感情方面的事情,也是我没完成的目标之一,不过有进步的是心态更开放,行为更主动。这东西急不来,哥只想找个对的人,仅此而已。借鉴工作中浮躁的经验,还得平常心,平常心。

就这样走过去吧,2009,我回了回头,向2010大步迈进。

 

如何写好商务邮件

在公司里面经常写邮件,给同事写,给主管写,给客户写,给不同的人写不同的邮件。写了这么长时间邮件,自己的各方面邮件意识也在逐渐增强,可是总是在邮件用词方面拿捏不准,需要Tech-lead review之后才能发给客户。我们客户的高层有个不好的习惯,Email只看前三行,所以如何用简短易懂的语句把你的意思传达成了一个重要的话题。

1st. 邮件和IM的比较

        公司有主要的两种电子沟通方式:邮件和IM (MSN)。

        1. 场合

                一般邮件用于比较正式的场合,IM则可以随意说,但是在我们公司,基本上谈论工作的话题都用英文,至少我们项目组是这样。

        2. 使用时机

                邮件一般是用于交流重要的,可保存的,可作为证据的,让对方必须知道的信息。

                常见使用案例:

                       { 主管对下属的命令,下属对上司的Report或Plan,团队内部重要代码的更改,SVN check In,向客户发布软件包,公司内部的提醒通知……}

                IM一般用于交流即时的,需要大量互动的(讨论),闲聊的。

                常见使用案例:

                        {对于软件某个Bug的讨论,约定开会的时间和地点,讨论下一步的作战方案(确定后再用邮件通知),生活的闲聊,非工作方面好的网址的共享,中午吃饭的号召}

        3. 主要优点

                邮件一般都比较正式,好处在于保留证据,为下一步的行动或者责任归属提供有力的可追溯的材料。

                IM一般比较形式上比较随意(内容不一定),好处在于即时性强,当团队内部需要讨论一般问题时,IM是比邮件和Face-to-Face更高效的方法。(当然如果IM文字无法讨论清楚还得Face-to-Face)。

        4. 格式

                邮件格式整洁清晰结构性好。

                IM无格式要求,甚至可以大量使用表情图标。

2nd. 写好邮件的原则

        1. 结构清晰

                很简单的道理,有的人一天收到几十上百封邮件,他不可能每封都看得很仔细,就像高考作文改卷老师一样,谁能够在30s内让他知道你写的内涵你就能得高分。同样的道理,结构清晰对写和读邮件的人都高效。

        2. 语句有针对性

                就事论事,不要用大量篇幅说些比较general的东西,不要话中带话。邮件是文字,不是Face-to-Face,收邮件的人不会也没有时间从你的邮件中反复揣测你说话的真正意思。

        3. 不要带感情.色彩

                一般正式的商务邮件不要带个人的感情.色彩,尽量客观真实的描述现实,否则容易引起误会和不必要的口水战。

        4. 格式细节

                不要出现文字错误或者语法错误,降低客户满意度不说,而且引起商业上的误会就不好了。

        5. 从对方角度思考

                想象自己是读邮件方,怎么才能让“自己”读起来爽点,自己就怎么写。

3th. 一个好的邮件结构

        主要是应用List技巧。反复使用下面的结构完成邮件

                {

                        标题

                        1.

                        2.

                }

4th. 一些好的写邮件技巧

        1. 使用List.

                参见3th。

        2. 写摘要。

                如果邮件很长,特别注意在一开头以独立段的形式写摘要(Summary),让读者第一眼就知道你这个邮件干什么的。(特别针对那个客户高层……嘿嘿)

        3. 关键标题要用Bold

                加粗关键标
题或者关键词句,让人可以快速扫描结构。举一反三,还有加下划线,添加文字背景颜色。

     4. 多用被动语态

                被动语态在于客观地说明,这样更加避免主观认为,而且显得更加专业。[Update: 2009-10-29]

 

写好邮件是我一直要学习的课题。

【更新于2011-8-27】经过将近三年的积累,我写了一个针对新人的写邮件的培训教程《学做职场邮件达人–新人入职》,点击下载。更多请关注我的微博@圆木菠萝头

客户需求变更

// Updated on 2009-2-22.加了tag 谁动了我的代码
还在大学的时候就知道IT业的客户经常变更需求,然后随之而来的就是工程师们狂改代码。现在在公司接触到的第一个项目,客户是美国的企业,客户方有两个人,一个管技术,一个管业务。做了一个月,才知道美国人也经常换需求,而且有时候根本不知道自己到底需要什么,管技术的和管业务的互相没有太考虑对方,技术的不太懂业务,所以设计的架构满足不了业务的需求;业务的不懂技术,以为移个按钮改个逻辑就马上可以实现(面向过程语言)。结果就导致需求一变再变,架构也一变再变(-_-!)。私底下我已经开始将其称为变形金刚。

于是乎。。。。。。

while((next电话会议 != null) & (Project != Release)) {
在与变形金刚的电话会议中,我们往往会讨论因为上次的设计带来的issue。然后,变形金刚一般会针对你提成的问题解决你的问题,一般不会考虑对之前的设计带来什么影响,也不考虑future。于是这次电话会议结束之后,回去发现对过去和将来又会造成issue,于是下次的电话会议再问变形金刚怎么解决这些新issue。
}

其实变形金刚无处不在,美国有,中国也有。美国的变形金刚再怎么变,擎天柱可能始终是卡车,而中国的擎天柱就有可能在你不经意之间变成红蜘蛛战斗机。所以我们唯有减少抱怨,分析下遇到这种问题怎么办,因为要为遇到中国的变形金刚做准备。

变形金刚变形一般可能会出现一些特征(我目前遇到的):
1. 客户方不了解需求。
客户方通常不只一个人,至少有两方,一个技术,一个业务。技术和业务都了解一些对方的工作,但没有仔细了解,也没有时间了解(否则为什么外包),于是技术的把架构设计出来,准确的说是架构大框架,不是所有的架构细节。于是我们提成业务的一个功能该架构不好实现,就开始等客户的feedback。有时候技术业务会在电话里面互相讨论需求到底是什么样。

2. 电话会议不平等。
不是说地位不平等,而是准备不平等。我们电话会议之前都是准备充分了,而客户电话会议前往往没什么准备,所以遇到一个问题会感觉到很突然,于是会临时想或者技术业务客户互相讨论,然后又不好意思让我们在电话那头等很长时间,于是就会在匆忙间做出一个决定,以后错了大不了再发issue,再改。这就是甲方乙方对待事情的态度不一样,这点可以理解,毕竟对方是给钱的。

3. 只解决当前问题。
当你提出一个issue的时候,他们就事论事,不考虑(也没时间)现在的变更对以前和未来会造成什么影响。所以他们的feedback通常会解决那个issue,但是很有可能和以前的rules冲突,也有可能对未来造成大大小小的影响。于是会再出issue,于是直接看上面的while循环。

我目前遇到的主要这3个问题,其实这里面折射更多的问题,就不一一展开。

这3个问题都可以理解,毕竟对方是客户,customer is god。他给钱你就是因为他觉得麻烦,他认为你专业,所以想让你帮他承受麻烦。所以不能对客户要求太高,就像我们不能对上帝要求太高一样,如果他们的责任心做事和我们一样,那他们自己就做了。但是哲学告诉我们事物是互相影响的,生产力可以决定生产关系,生产关系也可以反作用于生产力。客户可以决定项目的工程师们,工程师们也可以反作用于客户。最直接的可以反映这一点的就是,任何需求变更都会带来时间成本,我们的客户恰好是按时间算钱的,所以客户更改需求不但要承受工期带来的延长成本,还有看得见的白花花的美元成本。

所以遇见客户需求的变更,我们也要Change with speed.
1. 技术方面
技术方面是我们最应该主动控制的方面,因为我们就是干这个的。首先架构设计合理,按照软件工程的思路做成可扩展性强可维护性强的软件。Coding方面,尽量使用面向对象OO的观念去编程,封装继承多态。如果你的项目是面向过程,至少可以多用用封装吧。好的编程思想会让你在变形金刚变形的时候坦然处之。

2. 电话会议前的准备。
电话会议前可多做做准备,将以前做过的在脑子里理一遍,最好记住issue所涉及的关键点。这样如果客户“就事论事”在提出issue的时候,可以马上回复告诉他这解决方案与之前提出的rules冲突或者与未来的功能点造成影响。当然这点做到很不容易,因为是电话会议,所以反应以及表达都要快而且扼要。不过要注意,适可而止,不然客户会在你这里感受到强烈的“挫折感”而郁闷之极。

3. 电话会议后的准备
电话会议时按照第二条所说会有些难度,那么可以在电话会议后,将本次电话会议做出的重大决策记录成document,发送给团队成员问有没有重大issue,然后连同issue发送给客户,将本来应该在电话会议时快速反应说出的话而没有说的话连同决策内容一起发过去,邮件为FYI(For your information)级别,主要是让客户Confirm一下,也作为未来如果出现重大issue而block项目进度的时候跟客户谈判的依据。
“你们的进度怎么又拖后了??”
“不好意思,这是上次根据您要求的变化现在带来的后果(有邮件为证),我们正在积极处理善后工作,不过时间不得不延期,请您理解”

4. Set the right expectation
这是我的Tech-Lead教给我们的,就是设置合理的期望值。有时候客户要改变需求的时候,你要适当的给客户一点”punishment”,比如安排plan时设置一定的时间buffer,一来是给自己降低risk,二来让客户知道每次的变化都是有cost的,而且越到后期cost越大,改动架构cost更大。不要让客户觉得任何改变对你来说都是分分钟的小case,尽管有时候确实如此。否则会让客户养成“乱改需求”的不好的习惯,而且客户在改变的时候考虑得也不会太周全谨慎,反正你可以“分分钟”搞定。
这是一般的情况,紧急情况另当别论。

这是取自于目前项目的体会,但不仅限于这个项目。

下面分享一个真实的小故事,我们的Director以前当Tech-Lead的时候经历的一件事:

当Director带领的团队用java构建客户的某个系统到最后快Release的时候,客户突然有一天对他说:“恩,微软的人找到我们,准备跟我们公司合作一起开创美好的未来,但是有个要求让我们的这个系统采用.Net平台,所以,所以,你们能不能换换?”-_-!

That`s all。

Advanced Training总结

整个的Advanced Training持续时间一个月。任务是做一个类似于JUDE一样的UML辅助建模工具,工具要基于.NET开发者。因为公司Securtiy policy,所以这里不太方便透漏技术细节,只能记录自己的心得体会。

团队方面,起先是3个人,后来成为4个。Leader一个,我不是Leader。

技术方面,起先开始用户需求分析。我将我分析的部分有哪些模块,模块里面涉及到哪些细节通通写在笔记本上。后来看来这非常浪费时间不说,而且根本就没有看什么。最好的办法就是不管写什么就写到计算机上,特别是事前估计 effort 比较大的要写的东西,写到计算机上面一来打字比较快,二来将来文档化的时候很多东西可以复制粘贴。

团队整体将项目分成两块:数据和UI。 Leader问我们的兴趣点愿意搞哪一块,因为我当时对winform UI 以及 GDI+ 一窍不通,而对数据面向对象建模有点信心,于是我就负责了数据。而Leader就负责了UI及控件。于是我就借用JUDE工具绘制我对项目的类图,就是至少这张类图,我对着他看了3个星期。到了后来coding的时候都有些想吐的感觉,因为我的工作没有一个UI,全是代码。这里有两个场景我印象很深。

第一个场景是关于在团队中要坚持自己的观点。起先是类图设计的过程中,我一开始认定一种类型的连线用一个类,线的基类用一个类,放线的公共属性。而一个member建议用一个字段来表示不同的线类型。Leader先是同意我的观点,然后后期可能因为他UI方面要求我用一个字段,于是我妥协。按这样的设计后,有一天我突然觉得越想越难实现,于是第二天,大概是项目中期的样子,我又去改底层架构,改良了之后的架构不管从扩展性以及健壮性都比以前强得多。这里有两点启示:1. 如果你认为你的观点是正确的,哪怕团队其他成员都反对,你一定要找出事实证据后坚持你的观点,不要轻易妥协。团队需要和谐,团队更需要有想法的人。2. 不管你处于团队哪个位置(Leader更是如此),要考虑自己的部分会对其他人造成什么影响,如果只有自己的爽,将其他人的工作搞得无比郁闷,那你自己到后期依然爽不起来。

第二个场景是关于保持信心的坚持自己的工作。在办公室里面跟其他的团队坐在一起,经常其他的团队做UI的做了一个Demo出来,然后大家都围上去看,羡慕的不得了。这一来表面一个技术点被攻下,二来表面项目进度又进了一步。如果旁边的团队经常这样欢呼,而自己面对同样的类图工作了3个星期,信心是有点影响的。一来不知道自己团队的这些技术点攻破没有,二来别人接触到了新东西而自己没有(以为自己没有成长)。不过后来的事实表面,这一套底层架构设计的非常成功的,任何的操作都变得非常简单,只是在写API details的时候自己想吐。

总的来说,在群硕工作就会经常完成一些看似不可能完成的任务,我们都没有想到一个月的时间能够做出来一个像模像样的基于.NET的UML制图工具。是为记。

Basic Training 总结

Basic Training结束了,9.1日开始Advanced Training,现在将这上班一个月学到的东西整理一下,因为公司的安全制度,所以在公司总结的东西不能带出来,现在只能靠回忆。这样也好,回忆出来的东西更加真实反映了所学的。

按照软件工程的基本流程,可以将整个项目分为几个阶段:Requirement Analysis, Project Plan, System Design, Documentation, Coding, Testing, Release.

Requirement Analysis

客户的需求是在一个文档中体现出来的,因为是training project,所以没有客户。通过分析文档,客户需要一个网上商城的项目,能够进行商品的管理,用户的管理,订单的管理等等,基本算是一个网上商城所需要的最基本最基本的功能。在需求中,我提出疑问,要不要加入用户注册功能,因为需求文档中没有说明。后面的QA session也告诉我这其实是Bug,因为属于“本应该有但需求文档中又没有的功能”。
另外客户需要一个User Service,要求要有Winform的管理平台。简单说就是用户双击桌面上的.exe,然后对数据库的客户进行管理。这部分要求用WCF实现,并且Client用C#实现。
整个的需求分析阶段是对分析能力的考验,你需要站在客户的角度来分析客户到底需要个什么东西,还好我们的客户需求文档是由Trainer写的,比较清晰。真实客户可能根本说不清楚自己需要什么,到时候也是对项目人员的考验。

Project Plan

当客户告诉你说,我们2个星期后要看到成果,你会怎么办?当然要做个详细的计划。而且这和上大学不一样,老师会告诉你这阶段你该做什么,到公司没人告诉你,你要学会自己安排。你可以前面安排得紧,后面安排得松,你可以选择每天加班到凌晨,也可以选择每天5:30回家(只要你有能力),公司24小时营业,如果你认为你是铁打的……扯远了。不过,到现在发现加班不是个好事,经常加班只能说明你的效率慢,能力不够。有本事每天按时下班,工作做得漂漂亮亮,那是最厉害的。
Plan就是对项目的每个阶段的时间估计,需要做什么,会遇到哪些Risk,遇到后怎么解决。特别是时间估计,这点在Plan中很重要。在后来我们的总结中,Trainer介绍经验,一般你的时间估计要比你认为“正常”的时间多一到两个时间单位。比如,我认为做Product模块要2天,但是时间估计要写3天或者4天,因为你不能保证在此模块中你遇到非常cost time的issue,所以要稍微延长些,以保证自己不会delay,经常的delay会给自己不少压力而且客户觉得你不Professional。

System Design

这部分考察工程师的抽象和设计能力。简单的说就是把客户的需求转化为软件系统的表述。根据客户的需求,我来设计相应的架构,从整个软件系统的大框架,到小模块的具体构成,以及coding时要采用的架构。这些整体设计不涉及details,只是各个模块的架构,然后可以把他们组合在一起。这一部分一般会和文档结合在一起。

Documentation

文档部分一般包含两个文档:Functional Specification, Technical Specification.
Functional Specification就是功能说明书,一般是对客户的需求进行总结。将客户口头或者简单文字描述的“场景”转化为清晰的模块架构。这文档不包含任何技术术语,只是对功能的描述,对模块的设计。文档里面包含有Use case(用例)以及各种模块的描述(包括总括和各种功能的描述)。Functional Spec 会给客户看,估计到真实项目中还会给客户签字确认。后面的QA session也说过,这里的设计很重要,如果前期不设计好,后面要改架构,时间和资金的cost会非常大。

Technical Specification就是技术说明书。一般是根据Functional Spec来写的。针对Functional Spec里面描述的模块,根据自己的System Design的抽象,将这些模块转化为技术接口的描述。接口的描述包括接口的功能描述,接口的方法头,接口的时序图,接口的运行过程描述。除此之外,还有对整个软件架构进行技术上的描述,包括分层(比如三层架构),数据库设计等等。总的来说,Technical Spec描述技术架构,但是跟技术语言和具体的技术实现details无关。你可以把Technical Spec给.NET, Java, PHP团队来分别实现。

这部分文档编写用了我们一个半星期,因为原来从来没有人做过,只有一个模版。模版每部分写什么也需要靠自己来悟,Trainer先不会告诉你,让你自己的理解来写,之后会一起来review和discuss怎么写好。

Coding

没话说,就是编码了。结合Technical Spec来写就对了。不过现实中很多人包括我也没有完全按照文档来编程,因为很多东西文档期间都没有想到。

首先来说三层架构,就是DAL, BLL, UIL层。DAL(Data Accessor Layer)数据接口层,所有对数据库的操作(写数据,读数据)都在这一层完成。BLL(Business Logic Layer)业务逻辑层,所有与业务相关的算法都写在这一层。比如说“删除一个用户的同时要删除这个用户的所有订单”。UIL(User Interface Layer)用户接口层,就是我们说的界面。所有的界面的元素,以及界面上的逻辑和验证都在这一层完成。

一开始一直以为自己是三层架构,后期才发现自己是两层架构,就是把DAL和BLL写在一起去了。然后先前低估了UI层的时间,其实UI层很多东西很复杂,包括那天研究gridview到凌晨4点,还是自己效率太低了。其实分层的好处是方便日后的维护以及架构的清晰,虽然说时间和代码量都要比两层或者不分层多得多。但是越到后期效果就越好。

使用存储过程。第一就是为了防止拼字符串太费力,拼得费力看得也费力。第二就是用存储过程不会出现当UI层输入非法字符的时候导致的安全问题。之前就没有用存储过程,然后到了后期全部改工程量很大。不改又容易出现安全问题,所以只好在验证上下足功夫。

还要注意一点是,开发的时候一定要开发完一个模块就立马测试一个模块。我之前是先把所有的逻辑层写完,然后再写UI层。这样有个隐患就是,逻辑层的错误和UI层错误要一起处理,而且当项目很大的时候容易让人抓狂。所以最好的办法就是写完一个模块就去实现一个模块,然后测试它,然后再下一个模块。比如“AddProduct()”写完DAL和BLL层后,立马做个简单的UI层界面,把算法调用,然后去数据库看有没有这个Product(测试)。

WCF Service以及Winform编程也就那样,感觉微软的东西会一样之后,其他的都差不多。不过要深入还是要下功夫的。

I18N,国际化和本地化,体力活。不过要在文化上进行国际化和本地化还是很有挑战的。

log4net。主要是对所有的Exception进行日志记录。

Testing

测试,对软件进行测试非常重要,是在给客户之前的一个保障。基本我们是在QA session,然后我的作品有幸被公测,其他的同事或者QA team的报bug,我就在那里debug。虽然说开发的时候很注意UIL层的验证,可是后来发现bug最多的依然是UI层。

Unit Test。基本是由工程师自己写的模块测试程序,用NUnit实现。

然后在测试阶段,软件工程师要时刻去debug QA报上来的bugs。

Re
lease


Release Note, 告诉客户和QA怎么去配置环境。
Config Tool, 将基本的参数(服务器名字,用户名,密码,数据库备份文件地址,web.config地址)提供给客户输入,然后只需要按一个按键便可以实习所有环境的配置。用C# Winform实现。数据库方面用的是SQLDMO的COM组件实现。

其实感觉 Basic Training 目的是让我们搞清楚软件开发的流程,学习技术是无止境的。

暑假总结

暑期眨眼间过去,似乎这次的暑假一样过得很充实,两次实习构成了它的主线。

好不容易结束了那期末考试后,稍微休息了几天,我们迎来了学校组织的实习。赴湘潭去参加湖南移动基站的代维实习。这次的实习过程不再赘述,可是这次实习让我知道其实做一名基层工程师是很辛苦的。尽管是在电信行业,但不是电信行业的所有人都很有钱,特别是基层工作人员,工资不高工作却累。让我明白我们的专业或许是全校最好,但是远不值得骄傲。

接下来湘潭实习结束后,回家待了几天。来到湖北电信武汉分公司开明路分局实习,职务是社区销售经理助理。在这里,学到了很多销售常识和销售技巧,也知道了中国移动和中国电信的千丝万缕,也明白了中国电信的竞争对手是多么的咄咄逼人。更重要的是基本明白了国有企业的工作模式和一些办公室文化,在看懂了在电信行业竞争日益激烈的今天,中国电信内部其实还保留了浓重的国有机关作风。确实,现在中国电信的在南方的市场份额最大,但是要小心长宽网通铁通的蚕食。

这两条主线的实习让我今生不会忘,毕竟是类似对我的启蒙教育。让我知道,社会远比我想象得复杂,尽管我想象得已经很复杂。

然后就是几次同学聚会,和大学同学几个吃小张烤鱼,和高中同学出来玩了两次。在朋友过生日那天送了个自认为极富有创意的礼物,并且在武汉杂技厅听了纪连海老师激情演讲《大清的君君臣臣》。

可以说,这个暑假是我学生时代最后一个暑假,以后就要走上职业的道路了。

我的学生时代的暑假就这么结束了。