在坛子里混了这么久,看了很多同学的代码,感觉到大家的代码,学校里面的书生气有点重,对于细节考虑不够,有时候,感觉和吃了颗苍蝇一样,确实很不舒服。这里根据我个人的经验,给大家简述一下,工程化代码,以及简单代码,不容易出错的代码的一些基本写法。 1、工程化代码,首先考虑是团伙作案,独行大盗的时代已经过去了,呵呵,因此,特别强调“人”能看懂,很多教科书上给 出的示例,一切以计算机能正确 run 为准则,写出的代码只有计算机能看,作者本人再看都要想半天,这不是好代码。工程项目团队,很多时候都是大家合作开发,你的代码,可能使用者不是你,下一 个维护者也不一定是你,与人方便,与己方便,当有一天你对着一堆看不懂代码大骂的时候,想想,从我做起,给别人点方便。 2、简简单单写程序,不是说惜墨如金,多敲一个字符都嫌累。在 Unix 时代,没有显示器,都是电传打字机,编辑器也是行编辑器,因此,每多敲一行字,都是钱,再加上那会内存小,编译器能用的空间有限,因此,Unix 的老程序员,对于变量名,函数名,标签,珍惜得很,很少用 2 字符以上的,这是历史因素,人家穷,小家子气。 3、注释,很多教科书,一说编程规范性,就是注释,好像这是程序易读的唯一方法,大学里面的老师,没见识过大型工程开发,没一次干过几十万,上百万行代码,这么说也是可以理解的。 不过,工程程序员,项目压力一般都很重,在开发时,所有的注意力都在如何实现需求上,很少有人能有闲心,有耐心,精雕细琢自己的代码,甚至,很多代码,都是交工前最后一刻写出来的,因此,要求详细注释,在工程开发中,实际上没有可操作性。 起码我自己都做不到,这就是为什么我特别强调命名表意,程序写短点。即使程序员没有注释,看字面意思,也能大致理解。这么说吧,看别人的工程代码,没有注释,是正常,有注释,是福气。 嗯,有时候是霉气,很多程序员,开发时写注释,后期出现 bug,开始疯狂 Debug 的时候,那会哪有时间改注释哦,能把程序改对,都是烧高香了,最后,很可能注释和代码是反的,顺着注释看,顺理成章就掉坑里去了。 还是那句话,别期待注释,别全信注释,注意自己的程序,自身的表意性,至于你自己写不写注释,如果在我的团队里面,.h 文件里面的公有函数和方法,一定写全,每个入口参数的含义,返回码的含义,越多越好,别人正确调用你的程序,bug 就不会找你麻烦,这是为了你自己。至于其他方面,爱写不写,我不管。 4、再说简单,简简单单写程序,可不是说你惜墨如金,是说让读的人,感到简单,脑子里不转弯。这很好理解,我们做出一个产品,好不好,用户说了算,你的软 件产品可能有特定的用户,但你的代码本身,也是产品,你的团队伙伴就是你的用户,大家可能听说过换位思考,我们写程序的时候,除了想象客户会不会骂娘,还 有没有想想,以后读我们代码的人会不会骂娘? 所以,不妨多用几个变量,老老实实地写,不玩什么花样,看得人看得轻松,其实自己脑子也清晰,不容易出错。武侠小说中,说越是大宗师,越不喜欢用奇门兵 器,一路简简单单的太祖长拳,破尽少林寺七十二绝艺,这说明什么?把事情弄复杂,弄玄妙,不算本事的,能用最简单的招式,化解最复杂的问题,内力够了,自 然可以。修炼内功,就是减少对招式的依赖,简单,直接 ,直奔要害。以最小的成本,获得最大的收益,大家说,是不是? 5、规矩,很多人,一说工程化开发,就认为编程规范很重要。于是开始找大公司的开发规范,于是,网上的华为软件开发规范,传来传去,大家奉为圣旨。谁要敢说半个不字,管杀不管埋。规矩是人定的,每个人群,每个开发团队,都有自己的开发方向,常用工具,所以,编程规范其实是很小范围的东东,都是针对目前项目最有效的,很难想象,一个做.net 的开发团队,拿着华为用 gcc 做 VxWorks 工程的编程规范,能做好事情。 什么规矩是最好的?我的理解,最合用的就是最好的。系统设计完成,开发之前,项目团队在一起开个短会,讨论一下规范,把大的几条定出来,之后就随着项目的进行,不断补充罢了。很多时候,项目经理也要尊重程序员的习惯,一个程序员用 VC 的 IDE 习惯,总不能为了写 gcc,强迫大家都用 vi 吧。这里面有个个性化的规矩问题。大家别不习惯,出去之后,走上社会,大家会发现,很多东东都是灵活的,不是一成不变的,很多人就在哭,这个世界太黑暗 了。其实是自己不能灵活变通。项目组,有牛人,大家一般会跟着牛人走,他的恶习都可以变成团队规矩,这也合理,没有牛人,大家一盘散沙 ,就在接口处统一,里面程序乱点没啥,也可以,方法太多了,只要能出活,出来的代码,大家基本能看懂,其实就 ok 了。 像那种,还没做事,先说一大堆规矩,程序员学习规矩和习惯养成都要半天,这些,最后都是项目成本。江山易改,本性难移,做项目管理,何苦来和每个人作对,尊重一下大家的习惯,直接把习惯做成规矩,不是更好?
大家毕业,走上工作岗位,还有几十年呢。谁都不知道这辈子是不是一定在某个平台,或者某种语言,某种框架下写代码。一旦年轻时,习惯了享受某种框架的便利性,就很难深入思考了。那随着年纪增大,走向架构师岗位的时候,由于很多底层的特 性思考不够,会后继乏力。我们说,出来混,总是要还的,现在享受了,但是,这辈子的债,总得换,到三四十岁再来重新学习研究,会很难的。 很多人大言不惭,一说就是框架,以框架搭建工程固然很快,但是,想想看,做框架的人,和用框架的人,哪个水平高?哪个收入高?其实很多时候,企业的架构师,就是针对项目或产品,为项目团队制定本企业合用的框架的。学着自己写队列,学着自己写堆栈,再代入到实际工程中测试,做一些量身定做的优化 ,你的水平会迅速提升的。 (肖老师) |