当前位置:C++技术网 > 资讯 > 简述如何书写工程化的简单代码

简述如何书写工程化的简单代码

更新时间:2015-10-28 21:11:55浏览次数:1+次

1、工程化代码,首先考虑是团伙作案,独行大盗的时代已经过去了,呵呵,因此,特别强调“人”能看懂,很多教科书上给出的示例,一切以计算机能正确run为准则,写出的代码只有计算机能看,作者本人再看都要想半天,这不是好代码。

工程项目团队,很多时候都是大家合作开发,你的代码,可能使用者不是你,下一个维护者也不一定是你,与人方便,与己方便,当有一天你对着一堆看不懂代码大骂的时候,想想,从我做起,给别人点方便。

2、简简单单写程序,不是说惜墨如金,多敲一个字符都嫌累。

Unix时代,没有显示器,都是电传打字机,编辑器也是行编辑器,因此,每多敲一行字,都是钱,再加上那会内存小,编译器能用的空间有限,因此,Unix的老程序员,对于变量名,函数名,标签,珍惜得很,很少用2字符以上的,这是历史因素,人家穷,小家子气。

不过,现在大家用的都是以G为单位的内存,液晶显示器,IDE又那么强悍,拜托,起名字给长点,有点表意性好不好,别一段程序写下来,满篇都是“你猜”两个字,看程序的人要疯。

3、注释,很多教科书,一说编程规范性,就是注释,好像这是程序易读的唯一方法,大学里面的老师,没见识过大型工程开发,没一次干过几十万,上百万行代码,这么说也是可以理解的。

不过,工程程序员,项目压力一般都很重,在开发时,所有的注意力都在如何实现需求上,很少有人能有闲心,有耐心,精雕细琢自己的代码,甚至,很多代码,都是交工前最后一刻写出来的,因此,要求详细注释,在工程开发中,实际上没有可操作性。

起码我自己都做不到,这就是为什么我特别强调命名表意,程序写短点。即使程序员没有注释,看字面意思,也能大致理解。这么说吧,看别人的工程代码,没有注释,是正常,有注释,是福气。

嗯,有时候是霉气,很多程序员,开发时写注释,后期出现bug,开始疯狂Debug的时候,那会哪有时间改注释哦,能把程序改对,都是烧高香了,最后,很可能注释和代码是反的,顺着注释看,顺理成章就掉坑里去了。

是那句话,别期待注释,别全信注释,注意自己的程序,自身的表意性,至于你自己写不写注释,如果在我的团队里面,.h文件里面的公有函数和方法,一定写 全,每个入口参数的含义,返回码的含义,越多越好,别人正确调用你的程序,bug就不会找你麻烦,这是为了你自己。至于其他方面,爱写不写,我不管。

4 再说简单,简简单单写程序,可不是说你惜墨如金,是说让读的人,感到简单,脑子里不转弯。这很好理解,我们做出一个产品,好不好,用户说了算,你的软件产 品可能有特定的用户,但你的代码本身,也是产品,你的团队伙伴就是你的用户,大家可能听说过换位思考,我们写程序的时候,除了想象客户会不会骂娘,还有没 有想想,以后读我们代码的人会不会骂娘?

团队中有规范,按照规范来,不要讨论合理不合理,先照做,大家养成阅读习惯,看代码就不难。

写代码,不要耍酷,年轻人,或多或少都有点爱表现自己的欲望,人之常情,可以理解,不过要控制。哪些为了一个算法的优化,绞尽脑汁,最后把三个变量节约成一个变量,把四重循环节约成一重,看似水平高了,可是,算法复杂度高了,看的人就晕了。

不想挨骂的话,老老实实的写吧。函数内部的变量,只要不是动态申请的,一般都建立在浮动栈上,随着函数的退出,就会自动拆除回收,给下一个函数使用。对象内 部也差不多。所以,不妨多用几个变量,老老实实地写,不玩什么花样,看得人看得轻松,其实自己脑子也清晰,不容易出错。

武侠小说中,说越是大宗师,越不喜欢用奇门兵器,一路简简单单的太祖长拳,破尽少林寺七十二绝艺,这说明什么?把事情弄复杂,弄玄妙,不算本事的,能用最简单 的招式,化解最复杂的问题,内力够了,自然可以。提高自己内在能力,就是减少对招式的依赖,简单,直接,直奔要害。以最小的成本,获得最大的收益,大家说,是不是?

5、规矩,很多人,一说工程化开发,就认为编程规范很重要。于是开始找大公司的开发规范,于是,网上的华为软件开发规范,传来传去,大家奉为圣旨。谁要敢说半个不字,管杀不管埋。

规矩是人定的,每个人群,每个开发团队,都有自己的开发方向,常用工具,所以,编程规范其实是很小范围的东东,都是针对目前项目最有效的,很难想象,一个做.net的开发团队,拿着华为用gccVxWorks工程的编程规范,能做好事情。

什么规矩是最好的?我的理解,最合用的就是最好的。系统设计完成,开发之前,项目团队在一起开个短会,讨论一下规范,把大的几条定出来,之后就随着项目的进 行,不断补充罢了。很多时候,项目经理也要尊重程序员的习惯,一个程序员用VCIDE习惯,总不能为了写gcc,强迫大家都用vi吧。这里面有个个性化 的规矩问题。

大家别不习惯,出去之后,走上社会,大家会发现,很多东东都是灵活的,不是一成不变的,很多人就在哭,这个世界 太黑暗了。其实是自己不能灵活变通。项目组,有牛人,大家一般会跟着牛人走,他的恶习都可以变成团队规矩,这也合理,没有牛人,大家一盘散沙,就在接口处 统一,里面程序乱点没啥,也可以,方法太多了,只要能出活,出来的代码,大家基本能看懂,其实就ok了。

像那种,还没做事,先说一大堆规矩,程序员学习规矩和习惯养成都要半天,这些,最后都是项目成本。江山易改,本性难移,做项目管理,何苦来和每个人作对,尊重一下大家的习惯,直接把习惯做成规矩,不是更好?

6、轮子,笔者生活中,遇到很多了,坛子里面喜欢拍砖的人,也不少,开口就说,这个世界需要依赖工具,自己造轮子的人是笨蛋。

这个话确实见仁见智。很难说对不对,不过,笔者建议,初学者还是少用别人的轮子。

大家毕业,走上工作岗位,还有几十年呢。谁都不知道这辈子是不是一定在某个平台,或者某种语言,某种框架下写代码。

一旦年轻时,习惯了享受某种框架的便利性,就很难深入思考了。那随着年纪增大,走向架构师岗位的时候,由于很多底层的特性思考不够,会后继乏力。我们说,出来混,总是要还的,现在享受了,但是,这辈子的债,总得换,到三四十岁再来重新学习研究,会很难的。

很多人大言不惭,一说就是框架,以框架搭建工程固然很快,但是,想想看,做框架的人,和用框架的人,哪个水平高?哪个收入高?其实很多时候,企业的架构师,就是针对项目或产品,为项目团队制定本企业合用的框架的。

学着自己写队列,学着自己写堆栈,再代入到实际工程中测试,做一些量身定做的优化,你的水平会迅速提升的。