从进职到离职的收获——ICT四个月

从入职到离职的收获——ICT四个月

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

一、刚刚入职

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

 

刚开始,一般不会给安排重要的任务,首先了解整个项目的基本情况,然后了解公司的开发规范。我去的时候,项目的雏形已基本有了,开发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、如果后期维护遇到什么问题,他们免不了还得给我打电话,因为我没有时间留下详尽地文档来供他们参考。如果公司能在我提出离职之际,认真评估我的工作量,及时进行交接工作,后期肯定会省很多麻烦。

总结

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

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

 

 

18楼lyg673770712昨天 22:39
实践所得。。。学习了
Re: shan9liang16分钟前
回复lyg673770712n加油
17楼gxq741718618昨天 22:38
收获好多,师哥!
Re: shan9liang昨天 22:39
回复gxq741718618n加油
16楼e8love昨天 19:20
很郁闷 看见这个 n其实想说的是老板不看你代码 写代码的自己知道n时间和质量 及扩展 的关系nn这也就是 提到 越改越难 现在这样的公司很多 n需求不完善 文档不全 就开始
Re: shan9liang昨天 21:25
回复e8love时间真的不允许,很无奈。大环境这个样子,只能尽全力做好。
15楼laner0515昨天 19:06
厉害撒
Re: shan9liang昨天 19:09
回复laner0515n加油
14楼lilongsheng1125昨天 16:43
收获很多
Re: shan9liang昨天 19:04
回复lilongsheng1125n还行
13楼llwh19900802昨天 09:48
介不介意说一下辞职的理由??
Re: shan9liang昨天 13:45
回复llwh19900802n工作时间不等于工作经验
12楼wangyongxia921昨天 16:06
收获满满哦!
Re: shan9liang昨天 16:17
回复wangyongxia921n一瓶子底
11楼yuyeyi昨天 15:28
国内公司都这样。赚钱为目的。
10楼Wentasy前天 17:19
任道而重远,加油!
Re: shan9liang前天 20:46
回复Wentasyn加油
9楼ahao214前天 17:17
收获不错。
Re: shan9liang前天 17:19
回复ahao214n继续努力
Re: ahao214前天 17:19
回复shan9liangn还要努力。希望过了年能找到个好工作。
8楼bbaibb1009前天 17:16
顶起 我去年开始做我们公司的项目经理 之前什么都没做过,你说的问题我一样不落,全都有,我不知道一个项目经理离职会是什么样子,呵呵。
Re: shan9liang前天 17:17
回复bbaibb1009n等我做项目经理离职的时候,再写一篇文章跟你说哈。
7楼lfmilaoshi前天 17:15
收获呀,为将来茁壮成长奠定了扎实的基础
Re: shan9liang前天 17:16
回复lfmilaoshin加油!
6楼firstocean前天 17:15
如果你看了LINIX 设计思想指导那书,肯定情况会好多了。
Re: shan9liang前天 17:15
回复firstoceann设计思想等等一些书看了其实也不少了,真到了一些公司实践的时候,发现大家其实并不那么愿意遵循这些思想,原因诸多,主要是大家太急躁了,没办法,这都是跟钱挂钩的,很无奈
5楼StubbornPotatoes3天前 10:41
总结的全面。
Re: shan9liang前天 14:27
回复StubbornPotatoesn要说的太多了,想起什么说什么吧
4楼wangxuhebeibd3天前 07:55
像你学习。
Re: shan9liang3天前 08:53
回复wangxuhebeibdn像大家学习
3楼xp12043天前 21:57
挺踏实的小伙子,不错
Re: shan9liang3天前 23:05
回复xp1204n请多指教
2楼haiyan_cf3天前 19:12
总结的这么好,一定是做的很好,加油!
Re: shan9liang3天前 19:20
回复haiyan_cfn努力做
1楼yxqlove03013天前 17:33
虽然我没有亲身经历你说这些,不过也收获不少哦!
Re: shan9liang3天前 18:42
回复yxqlove0301n加油