这其实是《0bug -- C/C++商用工程之道》一书的读者朋友发给我的信件,这位读者显然在公司里面已经是一个技术骨干了,拥有较强的实战经验,也开始带新人了,然后,在新人的工作上,他遇到了一点问题,就来向我咨询。
我本来考虑,直接回复他算了,不过想了一下,还是公开回复比较好,因为我感觉到,他的问题比较有代表性。其实带出了一个很敏感的话题,就是“新人入职以后,该怎么做?”
好,我们先看看原文,再来分析。还是那句话,一家之言,欢迎拍砖哈。
原文:
在chinapub上看了样章,虽然没有代码大全经典(笑,绝对不是砸场子来的),但是我会买一本推荐给新入职的同学阅读,毕竟CC的厚度就够吓人了。
除开前来表示敬仰外,也问点非技术性的问题。
俺是一业内菜鸟,入行一年有余。目前供职的公司开辟了新领域,而老业务也要维持嘛,于是就招了不少人,于是我就成为这一批入职最早的一位,主要工作是维护老产品。
经过大半年的摧残,俺终于明白了其实写程序是在和人打交道的道理,也能够提出一些意见影响技术主管的决定,虽然经常被他说俺的设计太过书生气 =。=,比如俺一直宣扬应该尽可能的使用编译器来约束代码的使用者(或代码本身的特性),只要是你不期望的(不喜欢的)调用方式(或某种特性)就让他编译不过是最好的,防止代码污染。
近期不时去关注下新老同学手上的代码,考虑怎么去做重构,怎么去整理出开发库。
不看不要紧,一看就郁闷了。俺是个懒人,一看见有人可能下一个错误的决定,并且出了错还可能拉上我去耗时间就觉得焦虑。一焦虑就会变得很残暴 T_T
举个典型的代表,入职大半年的小A,现在手上拿着主要模块之一(该模块从来都没正式交付给我维护,但该模块产生过的严重bug,俺都参与过调试)。
在新平台下做测试,发现因为平台差异,在某handle被关闭后的一些看似无关的调用会失败。于是乎,小A就在这些调用前又打开这个handle,写了100行左右的代码,并引入了一个不算严重的bug。
发现bug后,建议他再看看(再测试下),经过1天,bug依旧。于是就指出了bug,然后建议我们是否不应该直接就这样暴力的把bug解决了,而是先去考虑下,这个时侯某Handle被关闭是设计如此?还是一个隐含的bug?以及触发这个bug的原理是否彻底搞清楚了。
过了两天,再一看,还是这么修改的,再一交流,小A表示bug已经解决了,没问题,但bug发生的机理依然不能表达清楚(我也不知道小A是否真的搞懂了)。而事实上这个问题是一个隐含的bug,那些调用就应该在handle关闭前执行。
这个时候如果是老肖会怎么做?
我的做法是直接找到技术主管提出自己的看法,然后请来资深的前代维护者,花了5分钟确认了我的看法,删除掉那100行代码,调整了关闭handle的时机。
事后想起来,我的处理方式是否太粗暴了。是否应该先尝试用更直接的方式与小A沟通,而不仅仅是建议。但是我又感觉对于小A如果建议了,都依然没有改观的话,更直接的方式也不一定有效。与其让自己焦虑,还不如快刀斩乱麻,要是我也忙其他的东西忘记过问了,岂不是又多一颗×××。
自省后觉得状态不太对啊,想听听老肖的看法。
我的回答:
这位朋友你好,你的信件我仔细看了,也想了差不多一周左右,确实有点难以回答,我只能尽量。如果答得不好,还请见谅。
咱们还是先挑点简单的先说吧,有个铺垫,容我也喘口气,呵呵。
“比如俺一直宣扬应该尽可能的使用编译器来约束代码的使用者(或代码本身的特性),只要是你不期望的(不喜欢的)调用方式(或某种特性)就让他编译不过是最好的,防止代码污染。”
这句话我明确说,我认为你对,应该发扬。我们知道,其实真正做0bug的程序,有点难,主要原因我认为,我们程序员是人,是人就有可能犯错误,有思维惯性啊,思维误区啊,或者根本就是考虑问题不全面,设计时漏想了了一块,这都可能导致bug。
其实有开发经验的朋友应该都知道,bug其实不难,只要发现了bug,程序员总有办法修订,难的是bug的查找和定位,我们无数次因bug导致的加班,其实更多地是在找bug,而不是改bug。
我在《0bug -- C/C++商用工程之道》一书中,提出无错化程序设计方法,其实主要就是针对这个问题在解决。首先我的基调就是,不相信人,包括我自己,因为我也是人,呵呵。因此,我在书中强调编程规范,强调程序易读性,强调严禁变量转义和一语多义,不但从思想上预防bug,更多的我是在讲方法和习惯。即很多实用,用一个规范,用一个习惯解决整整一个方面的bug。
比如说判断语句,常量写左边,if(i==0),如果写成if(i=0)表达式恒定为假,就错了,但是,如果我们养成常量写左边的习惯,永远一写就是if(0==i),当此时我们少写一个=号时,编译器立即报错,因为常量在语法上不可被赋值。类似的例子还有很多,我的内存池注册机制,就是利用程序自己来统计指针变量的使用情况,一旦发现未释放指针,立即报警,预防内存泄漏。
大家注意没有,所有这些规范,方法和习惯,我都是想尽办法,争取向C的语法规约,或者说编译器的报错边界在靠拢,力图使错误在编译的第一时间,在程序第一次被运行,就被报出来,并顺便帮助程序员定位到错误处,请问,这种bug还可怕吗?
还有,我在书中强调匈牙利命名法,就是喜欢它有个严格的约定,当把一个成员变量改为全局变量时,根据命名要求,变量必须要改名,由m_xxx改成g_xxx,这一改,编译器会找出一堆调用错误,那么,是不是在帮助我们,仔细检查每一个调用点,让我们来判断,这次改变变量的作用域,是不是合理,以及是不是有隐患。
因此,我这里明确提示一下年轻的朋友们,请尽量利用好编译器,它找bug比你准确得多。好的程序,不是一写出来就没有bug,而是写出来第一次编译一大堆bug,然后我们改,当什么时候改到编译器不报错,我们的程序就彻底没有bug,那么,我认为,这就是最理想的0bug程序,同时,这个程序员,可以称之为0bug程序员。
好,现在我们来讨论第二个问题。
第二个问题,我归纳一下,你看了那位小A的代码里面有明显的bug,于是有点焦急,沟通效果不好,小A虽然改了,但是没有改到根子上,bug依旧。这件事情,我直说啊,你做得不到位。
为什么说你不说小A呢,原因很简单,你比他资深。我们以前带团队,有个原则,同样的错误,如果是团队犯了,年轻的,刚入职的,不但不骂,还要安慰几句,资深的就骂,特别是级别高的,越是狠人、牛人骂得越凶,因为这里面有个原则,“资格=责任”。
比如说火车站候车室,一个人心脏病突发,大家都没辙,只有一个人是医生,但是他没有出手,这个人最后死了。想想看,大家是骂所有人,还是骂那个医生?肯定是医生啦,因为他有这个治病的能力和资格,但是他不治,就是不负责任,其他人由于不懂,就没有责任。
因此,这件事情上,虽然我不是很清楚你们公司的行政职务定位,但只要你比他早来一天,你就有责任。
当然,也不是说这件事情上你有多大的错误,但是,我个人建议,你的沟通方法需要改进一点,一般说来,我们做事有个原则,“重大问题,立即开会”。
要知道,在公司里面,不管是哪个级别的员工,其实都有权利开会的,开会并不是很复杂的事情,不是说只有主管才能开会。哪怕一个才入职1天的小弟,发现问题,我教他们的方法就是,先找我,讨论,一旦发现问题很严重,通常就是立即开会。我负责去请比我职务更高的主管,一起参与。
开会不是目的,目的是提醒所有人,我们有个问题,重要问题,如果不解决,会影响后续很多工作,因此,这是重要事件,请大家知晓。另外,我们要讨论一下,该怎么做,同时,还要对新员工做出表彰,因为他的这个发现,帮助我们预防了bug,节约了成本。
因此,我觉得你的第二个问题,其实就是一个会议的问题,你可以主动请求你的主管或经理,召开一次专题讨论会,就这个问题的根源,解法,做个分析和结论,拿出正确的解决方案,再委托这个小A去实施即可。
正如你举的例子,这个问题根源是小A没有理解程序设计的原意,打开了一个已经关闭的Handle,导致新的bug,那么,开会时,自然大家可以分析清楚,这个Handle原来为什么会被设计为关闭,来龙去脉如何,如果要再利用,该怎么做,其实在会上只要摊开来一说,应该不难的,那么,知道了来龙去脉,知道了原理,我想,小A的实施,应该不会再有bug了。
之所以采用开会形式,其实是有很多好处的。人都是要脸的,当一个人自己做事时,很容易忽视自己的bug,对自己有点放任自流,即使出现一点问题,也不会仔细思考,但是,当问题一旦暴露在大家面前时,人往往就会打起精神,负起责任来,认真对待,其实这也是帮助小A养成良好的职业操守。
当然,开会有开会的方法,我们曾经规定,两个人以上在一起讨论工作,就叫开会,我们不建议开长会,大会,不允许开无结果的会,每一次开会都要有结论,每一次结论都要有记录,并且,纳入工作日记管理,主管下面要查实施效果的。你能明白吗?
嗯,我们再来谈谈第三个问题。
第三个就是你直接向我咨询,你找主管的做法好不好?
我的回答是,也好也不好,好的是,你找主管,开始争取团队的支持,找来前×××发者,并解决了问题。从工作效果上,好。
但是,也有很不好的一面,你发现没,在这中间,没小A什么事,那你想想,他会怎么想?是不是很没有面子?他会不会因此感到自卑,或者受到伤害,并因此而消沉,离职?
我们经常说新人离职率高,老板就骂,现在的年轻人怎么啦?养不家的猪,主管也跟着骂。其实有时候,反过来想,我们这些主管,自己有没有责任?是不是我们很多时候没做好,导致了不可挽回的结果?新人好不好,我的建议是,老板可以骂,但是,主管最好别骂,因为往往会骂到自己头上的。
我的建议,最好的做法,你和小A先开小会,讨论一下这个设计有没有潜在的bug,当你们能达成共识,再一起找主管,让前代作者和小A交代,这个东东的原理是什么,你和主管旁听,在中间你适当参与讨论,引导小A自己总结问题根源,以及解决方案,让他自己说出来,大家评判他的解决方案是不是对,当最后他自己都能说对的时候,你认为这个问题的解决,还难吗?
这样的好处显而易见,你们没有责怪小A,更多的是针对他知识和经验的不足,在帮他提高,提高到他自己拥有解决问题的实力,并且自己拿出解决方案,最终解决掉这个问题,你说,他是不是很有面子?
一个新人,到了新公司,主管悉心教导,不批评,只培训,自己不断提升,并且,能解决很多公司的关键问题,自己觉得自己逐渐成长为公司的重要人物和骨干员工,请问,这个新人会没事跑路吗?
这里提示一点管理方法,“上情不能下达,开会,下情不能上达,私下讨论”。这也是我自己总结的一点管理经验,你这个问题,既有上情不能下达问题,又有下情不能上达问题,建议可以参考我的这个原则,一般说来,你做到这一步,方方面面的顾虑就都考虑差不多了,最后,小A受表扬,你的评价也不会错。
当然,在这期间,必要的沟通技巧必不可少,沟通技巧,可不是说话客气就算完,是很多素质的综合,包括换位思考,包括耐心倾听,包括引导思维,等等,建议以后可以学习一点沟通方面的知识,会对你的工作很有帮助的。
嗯,从这个问题,我再引申第四个问题,就是站在小A的角度,该怎么看待这件事。
这其实是换位思考了,我们说完了你这位资深员工,或者说主管朋友,那么,我们来说说,作为新员工的小A,应该怎么做,才能更加符合公司的需求。
我在《0 bug ---- C/C++商用工程之道》里面,其实这个问题多次涉及并讲解,这里我再多说一次。
在书中,我讲过一个故事,就是以前一个团队成员,独立完成一个项目,但是显然没有做好,他做的算法没有和我们商量,或者是没有重视我们开会时给他提示的重要算法关键点,自己一个人闷着头做,一个简单的数据库树形目录体系解析模块,他做了接近4个月。最后,我们全体同事的模块都完成了,单独等他等了两个月。
我没有办法,最后在项目deadline之前两天,正式接手他的工作,我发现他把问题做得太复杂了,写了整整15000行代码,中间绕来绕去,造成了无数的bug,最后无法交工,并不是程序没有写完,而是bug太多,无法稳定运行。
我没有办法,重构了他的代码,中间我引入了一个我发明的“工具类”方法,1200行代码,两天做出来,一次过,0bug。他当时都惊呆了。最后,由于他表现不好,被公司请去喝茶,到另外的公司上班去了。
这个故事我记录在《0 bug ---- C/C++商用工程之道》工具类这一小节中,有兴趣的读者,可以看看。
那我们来看看他的问题是什么?
这么多年的程序实战经验,我发现新程序员入职场,往往会犯两种错误:
1、不喜欢求助,新人并没有把团队视为自己的资源,更多的是想表现自己,因此遇到问题,喜欢自己钻牛角尖,尤其是还有一点面子观念,怕自己问很傻的问题被人笑话,结果呢,导致自己死K不出来,大家想帮忙帮不上,干着急,最后事情还没办好。
这里我建议各位同学,当你们第一次入职场的时候,摆正位置,你们就是新人,新人不懂,是正常的,有问题,自己想出了解法,可以主动找老员工或者主管谈谈,你不是去问他,你把你的解决方案说给他听,让他们参谋,是不是合理,这一般都没有人会拒绝,而且,可以获得很有效的帮助,这比你自己全部去想,效果好的多。
我们不建议新员工事事不动脑子,全部靠别人帮忙,但是,我们强调,新人最好在动脑子的前提下,请主管和资深工程师帮助自己点评一下,帮助自己查漏补缺,这是非常好的习惯,会帮大家少犯很多错误的。
2、喜欢玩技巧耍酷。这也是新员工喜欢犯的错误,很多新人入职,由于在公司没有地位,急于想表现自己,这体现在开发中,特别喜欢玩一些比较精深的算法,以显示自己很牛,并试图通过这些表现,让大家重视,或者尊重自己。这也要不得。
我经常喜欢说一些新员工,“耍酷耍到自残”,呵呵。敲代码,明明有方便的VS2008,不用,非要用vi,好像不用这个,就不能算Linux程序员。就看他打字的时候,两个手像蝴蝶一样在键盘上飞,花枝招展,煞是好看。结果最后一看,他产量最少,笔误最多。
我写了n个Linux服务器了,到现在不用vi,我就是在VS2008里面编辑,然后,VC编译,运行,通过,ftp到Linux,make,运行,通过,就好了,VC的编辑环境很好用,我们敲代码,每个变量名,函数名,只输入一次,这里拷贝一下,那里用点自动弹出,哪来的笔误嘛。
这还好,仅仅是习惯问题,最多影响一点产量。有一些朋友更要不得,一个简单的被动池算法,又是动态内存分配,又是链表,又是树,忙活了半天,最后出来,一堆的bug,好不容易改好bug,QA一测试,程序不可用,重构。原因很简单,没有考虑到内存碎片的影响,无法满足7*24小时运营要求。
像我们老工程师呢,看看数据边界,嗯,最多1024个单元,不多嘛,一个静态数组搞定,然后在数组中做点重用逻辑,根据概率分析,效率不比动态分配的差,程序简单得多,而且没有bug,静态数组,更不可能有什么内存碎片。完了收工。
大家觉得哪个好?
这些,都是我过去碰到的实例,我也share到《0 bug ---- C/C++商用工程之道》一书中,很多时候,不要为了写程序而写程序,要聪明点。
我经常开会时劝小弟,“请你们用脑子写程序,别用手写程序”,大家能明白什么意思吗?
好了,总结一下吧。
目前很多朋友,不好找工作,主要原因是因为学校里面的知识,不是很合用,企业的需求与我们的实力之间有落差。但这个问题其实在我看来,不难解决,目前有很多好的培训班,也有很多优秀的培训机构,我们只要潜心学习一段时间,掌握基本的企业开发技能不难的。
但是,我发现大家讨论时,很少讨论一个问题,那就是:“进去了以后怎么办?”
今天我将就这位朋友的问题,谈谈主管如何管理新人,也谈谈新人如何融入企业开发团队,希望能帮到大家。
其实这些东东并不复杂,说穿了,因为不值几个钱,但是,请大家关注,就这么一点点思路,理念和方法的差异,有的人就能在新公司迅速定位,并不断出成绩,最后成长为公司的业务骨干,获得重用和高新,但有的人,就是没有办法获得稳定的工作,最后变成跳蚤,到处乱跳,始终无法成就自己的事业。大家愿意做哪一种?
其实我写《0 bug ---- C/C++商用工程之道》一书,很多时候我自己都在想,我讲的重点是什么,最开始定位的时候,我是程序员,我当然应该写技术,但是写到一半想法就有点变了,待书出来,面世,我发现其实我真正写的,是怎么做人和做事的原则。
我一直建议大家,代码不值钱,别被代码迷住了,要跳出代码看思想,就是因为我觉得,一个新人走入职场,技术上的问题真的不是什么大问题,最大的问题,是怎么找到正确的工作方法,少犯错误,争取转正和进步。我觉得这才是最重要的。
我可能由于水平有限,写出来的书,这方面说了一点,但是没有重点突出,表现上也不够醒目,只有我这里多发点帖子,请大家关注这个要点了。
欢迎大家以后就这个问题和我多讨论,我希望能帮助尽可能多的朋友,获得满意的工作,并且能够做好,成就自己的一番事业。