从入职到离职的收获—

在北京这家公司工作四个月，从入职到熟悉工作，进入工作状态，忙碌，再到交接工作，离职，短短四个月时间，收获还是蛮多的，在这里与大家分享一下。

一、刚刚入职

在这家公司刚入职的时候，对自己能不能胜任工作，心里还是有点敲小鼓的，把姿态放得很低，似乎每个人都挺强，导致自己不够自然大方，做事“如履薄冰”，现在回想起来，完全没有这个必要，既然公司已经接收你来工作，自然是对你的能力有了基本的认可，愿意承担一定的风险，自己完全没有必要妄自菲薄，别人相信你，自己更要相信自己。前期有这么长时间的积累和磨练，肚子还是有些墨水的，不明白当时担心个什么劲，可能是对新环境的不适应吧，既来之，则安之，自信满满地迎接挑战才是最实在的。

刚开始，一般不会给安排重要的任务，首先了解整个项目的基本情况，然后了解公司的开发规范。我去的时候，项目的雏形已基本有了，开发boss给安排了一个简单的模块来练手，想快速上手，自然不免模仿别人的代码，模仿别人的风格，至少不应该有太大出入，如果自己从头创造那就太慢了，而且会影响整个项目的一致性。如果功能类似，也可以直接把别人的代码复制过来改，前提是，一定要搞明白代码的意思，不能“贴过来，一运行能达到想要的结果”就完事，这里省事，后面出了问题你都不知道是哪里的问题，而且维护起来也很麻烦。

二、工作中

1、模块不是独立的

公司的项目管理并不完善，开发人员一般都是拿着需求文档在做开发，没有设计文档，自己设计一条线，界面，业务逻辑层，数据访问层，这几层都是自己搞定，据公司某总说，文档不完备，匆忙上马，这似乎是中国特色了。

我开始拿到了TL模块的需求文档，简单看了看，就开始敲代码，感觉挺简单的，很快就完成了，后来发现错误百出，究其原因，是自己把这个模块独立起来看，并没有认真分析这个模块在整个系统的位置，和其他模块的关系。开始意识到，仅仅了解自己模块的业务是不够的，因为一个模块不可能是孤立的，他需要为别的模块提供接口，或者调用别的模块提供的接口，在某些状态下，功能的实现方式也是不一样的。所以，不能只关注自己这块业务，对相关模块的业务也要有一定了解，要有全局观意识。

2、实现功能是不够的

在做ML模块的时候，因为时间比较紧，并没有考虑代码的可扩展，可维护性，完成了功能就了事了。可是后来需求变更了，麻烦来了，我需要做的修改太多了，越改越乱，最后只能整个推翻掉，重新开发。不可维护的代码，会把自己整死的。这次得到的教训是：如果你的模块需求变更比较快，一定要尽可能让程序可扩展，可维护，减小代码复杂度，不然修改可能是颠覆性的。不能急功近利，应付差事。

3、做好记录

开发的过程中，认为需求中某些部分并不合理，找需求boss沟通，得到许可，按照自己的想法来做，可需求boss并没有来得及修改文档（这是经常事），代码提交测试后，测试根据文档来测，给你提bug，你只能再找他们沟通，因为开发到提交测试，时间间隔比较久，可能需求boss早就忘记了，这时候是谁的责任？还有就某些问题讨论的时候，讨论结果如果不记录下来，当测试给你提bug，你又不得不找boss为你证明，很可能boss都忘记这个问题了，你找谁说理去。这个教训是：谁也不保证系统绝对成熟，需求不会变，应该准确记录，与需求沟通的结果，如有必要，要在代码注释中记录“什么时候，谁让改了什么”，不至于最后互相推脱责任。开会的时候，会议记录一定要作详细，不至于浪费时间讨论重复的问题。

4、界面类似的功能整合到一个界面要慎重

开发过程中，在TL模块有三个功能的界面类似，就放到了一个界面里，在代码里通过判断上级传过来的值，来决定某些元素的显示与隐藏，同样要据此采用不同的业务逻辑。这就出现了问题，因为代码中不免会出现很多if语句，无疑增加了代码的复杂性，如果出现bug，修改起来必须非常小心，不然可能改出更多bug。但同样在ML模块，三个界面功能类似，我并没有整合到一个界面，因为有前面的教训，但后来依然出了问题，相同的代码我要维护三份，而且这块还特别复杂，改起来特别繁琐。所以如果要把界面类似的功能整合在一个界面一定要慎重。

5、文档变更要及时通知开发人员获取最新文档

在做TL模块的时候，我根据1.0版的文档开发，可是中途需求对文档进行了修订，并没有通知我，也没有发给我最新的文档，后来测试提bug的时候，我才知道我们依据的文档不一样，查服务器才知道，svn上需求文档新增了一个2.0的doc，我当时就抓狂了，一方面因为我没有及时查看svn需求文档变更，另一方面也要怪需求在改动文档后没有通知大家获取。错误很低级，但还是提醒大家，需求文档在改，更新完了，一定要及时通知开发人员，不然开发还拿着老文档在做，后果可想而知。

6、有问题要及时提出来

有问题要及时问，不能憋着，拖来拖去可能会引起大麻烦，每个公司都有自己的积累和开发方面特有的东西，你不熟悉是很正常的，不要怕丢人，要善于勉强别人。

提问也是要讲究技巧的：

（1）不要在别人忙着的时候问别人问题，很容易招人烦。

（2）如果不是什么必须当面谈的问题，尽量不要直接到人家座位上拍人家。可以采用聊天工具（一般公司都有自己指定的）预约，问问人家忙不忙，什么时候方便帮助一下你。

（3）提问要找对人，一般团队都有些技术超牛的人，也有对业务超熟的人。如果拿着业务问题去找前者，效果肯定不好。

（4）别忘了说诚恳地道谢。

7、开会

发现每次我们项目组开会，一开就是半天，每次开会都不好好把握时间，也不好好把握开会主题，明明是要讨论某某模块的需求的，结果开着开着就开始说说这，说说那，半天时间一晃就过去了。有时候，遇到一些棘手问题，这个得等领导批，那个得等某某意见等等，既然这个没有结果，就先放下，何必拿出来讨论，讨论最后依然没有结果。开会没有明确主题，东扯西扯的，不抓紧时间，我只能跟着干瞪眼。好像大家的时间都很多似的，伤不起啊。开会明确主题，把握时间，做好会议记录，这是必须的。

8、代码规范

公司代码审查做得并不好，大家并没有严格按照规范来，无论是命名还是注释，都是自己的风格，显得很混乱。这样会导致怎样的结果？我是尝试到了，项目开发过程中，boss说这个项目要通过iso等一些标准，出台了一份规范，要大家按照这个规范来，从我的模块开始，可是我的模块已经开发接近尾声，可想而知，我改起来是一件多么痛苦的事。

如果在项目开发开始就明确规范，执行严格地代码审查，我想大家也不用后期再去做这些繁琐的修改去适应规范了。

9、想全面了再开始？

这是在一次与boss聊天中得到的启发，我们做的项目前期调研做需求做了很长时间，迟迟没有着手开发，总是希望把需求做的特别详尽，恨不得做好一次就不用改了，可是总是不能调研完，项目时间在无限制地延长，直到大boss发火说，你们别调研了，再调研黄花菜都凉了。这才着手开发，开发的过程中又发现，很多需求设计并不全面，根本无法实现，根本不符合实际。其实，我们是不可能把需求完美到一次成型的。在开发过程中完善需求，完善设计是不可避免的。个人觉得，对于比较大的项目，还是采用原型开发，经过几次迭代使系统趋于完美比较好，或者采用先完成系统的核心功能，让系统跑起来，再去完善边边角角的方式。说来说去，无非是选择软件生存期模型的问题，详见我的另一篇文章《软件生存期模型》

三、离职

说起离职，暴露了公司很多问题，我的离职让整个项目组的忙碌了起来，很戏剧性地是，这两周似乎公司的效率提高了很多。因为我要离职，测试要加班测我已经开发的模块，开发boss要找出和我有关系的模块，看看有什么没有开发的，似乎大家都在围绕我开发的模块干活，异常忙碌。开发boss恨不得在我走之前，我开发的这块就能运行起来，一点问题都没有，我不得不说：那是不可能的。因为我做的时候，需求就不完善，很多地方都有待其他模块完成后，综合考虑。我只能保证主要功能没有问题。在我要离职之际，boss依然在提新的开发任务，而没有给我足够的时间整理手头的工作，做好交接工作，以便让后来人顺利接手。直到临走的前一天，才开始把我的工作交接给另一个人，甚至最后一天，我还接到了新的开发任务，这样匆忙地完成交接，会带来两个后果：1、接手的人不能顺利消化我留下的模块，我只能匆忙地为他讲解整个业务逻辑和里面需要注意的问题。2、如果后期维护遇到什么问题，他们免不了还得给我打电话，因为我没有时间留下详尽地文档来供他们参考。如果公司能在我提出离职之际，认真评估我的工作量，及时进行交接工作，后期肯定会省很多麻烦。

总结

在这个公司，在尽职尽责地完成开发任务的同时，自己获得了不少开发经验，学到了许多为人处事的经验，认识到有效沟通在项目开发中的重要性，同时也深刻认识到项目管理的重要性，能不能让一个项目在可控范围内有条不紊地进行，需要丰富的项目管理经验，还需要公司提供一个良好的制度保障。

最后，感谢这段时间来给予我帮助的同事，谢谢你们腾出自己宝贵的时间耐心地帮助我。感谢我的米老师，谢谢您这三年来的教诲。任重道远，我会继续努力！