实习总结

实习总结

 

我无法完全从技术角度叙述这半年来实习的收获。在这期间触动我的事情太多，技术带给我的成长与它们带给我的成长相比，简直沧海一粟。

北京

在我看来，北京最大的特点不在于繁华或是快节奏，而是鲜明的贫富对比。

繁华的地方繁华无比。林立的写字楼、奢侈的巨型喷泉与整齐的草皮、蜿蜒的立交桥相与衬托，就连不大的烧烤店，也是某著名电视剧的特约拍摄地点。

落破的地方落破无比。贴满各种小广告的平房破漏不堪、土质地面的胡同窄小又曲折；每每傍晚，炊烟从各个角落升起，叮叮当当的炊具碰撞声可以和大型的交响乐晚会相提并论，唯一的缺点就是不那么动听。

我，和很多北漂客一样，正是这鲜明对比的见证者。每天早晨，我们都从北京最落破的地方爬起来，奔波一二个小时，到北京最繁华的地方出卖体力或脑力。

有一点，我比其它北漂客更加不幸。我很少有机会能看到傍晚的炊烟，听到那不动听的交响乐晚会，我的每一天几乎都是加班的一天，每晚陪伴我的是寥寥几人的地铁车厢和与这有关的惊悚传说。

传说北京修第一条地铁的时候事故连连，迟迟不能竣工，于是请来了风水先生。风水先生仔细考察后说，你们惊动了太多的魂魄，工地怨气太重，不过想要竣工也不难，子时（也就是晚上十一点）后是魂魄们休息的时间，你们要保证在子时前关闭地铁并空驶一个往返，将被惊扰的魂魄安稳地送回原地休息。相关的负责人答应后，地铁才顺利竣工。

这个传说告诉我们，在北京，鬼才有休息的权利。

没有生活

实习之前，我的幻想是“技术、技术，还是技术”，实习之后，发现现实是“加班、加班，还是加班”。

“每一个加班的公司都在高速发展，而每一个不加班的公司都在走下坡路”，项目经理说的很多话我都不记得了，这句却从没忘过。上网翻了资料，在中国，似乎每个公司的经历都是这个结论的正面论据。于是反过来，这也成了每个公司的信仰。

记得刚进公司的时候，面试过我的那个同事请我和另一个同我一起入职的新人吃饭，我傻乎乎地问，“您觉得在北京生活得怎么样？”，面试过我的那个同事抬起头，很惊讶地看着我说，“生活？北京哪有生活！”

的确，北京没有生活。我的打卡记录显示，平均每月有15天我是九点半以后下班的，而我从公司到住的地方，乘地铁也要近两个小时；在我实习期间，真正属于我的周末不超过三个，而这些周末我除了累得闷头大睡，什么也没干；通宵，不过是家常便饭。

什么叫学习？

日子是空虚的。越是空虚就越想看书，于是我买了本《时间简史》，计划用它来消磨我在地铁上的时间。不幸的是，三个月后的今天，我还是没能把那仅有几百页的书看完，原因是几乎每次地铁都能把我晃得睡过去，这是睡眠不足最本能的反应。即使这样，我还是感觉很快乐。这快乐就好像小时候给我一个坏闹钟，我能就天天对着墙角拆上一两个星期而乐此不疲。

学习本应该是这样的。

如果不用为了考试背什么狗屁泰勒公式，记他妈什么级数收敛判定定理，做冗长冗长冗长冗长冗长冗长冗长冗长冗长冗长冗长冗长的练习题，我本可以捧着一杯热茶坐在图书馆的角落，欣赏每一个伟大数学思想的来龙去脉，体会世界上最聪明的人们留下的思想中的美妙之处，仅仅是欣赏，仅仅是体会，心有所合之处就随意留下些自己的想法。如果那样，我就不会像现在这样，抱怨高数线代忘得一干二净，抱怨浪费了一个学年的晚自习却什么也没给今天留下。

如果不用为了考试去计较什么“挑剔”的“剔”是读一声还是二声，计较什么时候该用“终身”，什么时候该用“终生”，记什么自相矛盾的语法。我本可以躺在床上细细赏读完欧享利的《命运之路》、老舍的《骆驼祥子》、鲁迅的《朝花夕拾》，从中得到自己的体悟而不用任何人把它们分析得支离破碎。如果那样，我不会像现在，面对天天就站在我必经的地铁站口，几十年如一日回收过路人手中的旧报纸、旧瓶子的七旬老人苍白的头发、深陷的皱纹，不知如何下笔记录那伟岸的身影，也不会在她将颤抖的手伸向我，我眼泪夺眶而出时，不知道怎样用文字描述自己复杂的情感。

学习本应是发自内心的需要，我需要学习，所以我学习，而不应该是考试需要我，所以我学习。

学习是学习，考试是考试，就好像学习是学习，工作是工作。

公司需要的不是技术，是价值！

之所以说学习是学习，工作是工作，是因为公司从来没有给过我时间学习。

指导我的第二个同事是瑞星公司跳过来的，在他的描述中，瑞星是学习的天堂，也因此，瑞星培养了一大批优秀人才，积累了大量核心技术。瑞星实现了世界上最快的虚拟机，实现了相当优秀的杀毒引擎。但瑞星最后还是奄奄一息了，360仅靠传统的搜索技术就一拳把瑞星打死了。

公司需要的不是技术，什么技术对公司来说并不重要，公司需要的是价值。什么是价值？价值就是破漏不堪的平房变成写字楼和喷泉，价值就是窄小曲折的胡同变成草坪和立交桥，价值就是钱，除了钞票还有股票。“公司应该是用技术创造价值而不是用价值创造技术，瑞星就死在这上面了”，这是那位同事的原话。

敏捷开发

公司关心的另一个问题是效益，也就是投入产出比。在软件这条生产线上，投入和时间成正比，产出和发布的版本数量正相关。公司期望在最短的时间内开发出最多的版本，自然会选择某种形式的敏捷开发方法。

所谓敏捷开发方法，就是为应对需求的变化做好各种准备，包括简化流程、简化文档、小版本迭代以及优化结构。这使得产品可以迅速地改进，适应市场的各种变化。

敏捷开发的精髓在于优化结构，优化结构不特指面向对象，也不特指各种设计模式，它们仅仅是优化结构的几种方法。其实不管是结构化设计，面向对象设计还是前沿的泛型编程，好的结构总可以归结为两个方面：一方面是为避免重复的工作，编写各个地方共用的代码，就好像要我生产地铁，我一定会先生产用来生产地铁的机器，术语称之为“代码复用”，这可以大大提高开发的速度；另一方面是减小各段代码之间的关联，使得编写一段代码的时候仅需要把注意力局限在这段代码本身，而不需要分散注意力去关心别的代码，就好像乘地铁的我从来不关心地铁是怎么运行的，我可以专心地考虑站在哪个位置等地铁抢到座位的概率更大些，然后在地铁上专心地看我的书或是睡我的觉，同时，地铁司机也从来不关心地铁上的人在做什么，甚至不关心拉的是人是鬼，他可以专心地开他的地铁，让我们颇有安全感，术语称之为“解耦合”，这可以把程序的BUG限制在很小的范围内，也为应对需求变化准备了充足的条件。

敏捷开发之伤

敏捷开发也是把双刃剑。敏捷开发的过错在于纵容了需求的变化，常常使得需求的变化超过敏捷方法本身能够应付的范围。是的，敏捷方法能够应付的需求变化是有限度的，就好像一个具有良好结构的房子，一会儿要在东墙上新开个窗，一会儿又要堵上南面的门在北面新开一个，久而久之，会发现已经无法再做改造，因方房子已经处处疮痍，成了危房了，超过需求变化的限度，代码结构就会越来越差，直至不再具备良好结构的特征。

不过也不是没有办法，可以重新盖一个和现在一模一样的房子，这在软件工程学中称为“重构”，也就是保持功能，重写代码。不过现实中这种方法很少用到，原因很简单，公司需要的不是技术，是价值，糟糕的代码结构眼下并不影响产品的价值。

于是，大量的时间消耗在修改BUG的工作上，而修改一个BUG常常带来更多的BUG，于是，越加班就越加班。

总结：学习也需要“解耦合”

事物都有两面，敏捷开发只是遵循这个哲学常识。

抛开消极的一面，敏捷开发倡导的结构优化的确大大提高了整个软件产业的效益。其实，良好结构的两个方面并不是软件产业创造出来的，它本来就存在于我们的生活中，无论是自然科学，如建筑学、工程学，还是人文科学，如管理学，都有极其相似的结论，它，是一种哲学。

学习本应和其它的事情“解耦合”，学习就是学习，不考虑考试的题目，也不考虑工作的需要。这样，我们才能把注意力集中在知识本身上。学习不是生产，我们需要的是知识，不是分数，不是薪水，不是任何形式的价值！