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

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

肖舸老师

在坛子里混了这么久， 看了很多同学的代码， 感觉到大家的代码， 学校里面的书生气有
点重，对于细节考虑不够，有时候，感觉和吃了颗苍蝇一样，确实很不舒服。

这里根据我个人的经验， 给大家简述一下， 工程化代码， 以及简单代码， 不容易出错的
代码的一些基本写法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大家别不习惯，出去之后，走上社会，大家会发现，很多东东都是灵活的，不是一成不

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

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

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

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

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

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

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

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

学生评论：

西安工程大学 袁小龙(数据库学生) ：
老师的话总是能给人启迪。我就向往着teamwork 的生活，希望老师还能继续发帖，让我们
这些学生提前感受，学习到社会的知识~~谢啦！

河南成功学院 Gwolf 团队 赵鹏(C/C++爱好者) ：
呵呵，喜欢读，因为简单，明了。不为别的，喜欢这种风格。
内容来自真实的一线，说服力强！

黄海峰(网络管理爱好者) ：
我才毕业没多久，发觉很是理想主义，很想当“独行大盗”的心态，有时甚至感觉单位的前
辈写代码过于迂腐，但是遇到问题找他们时，他们又总是能很快把我指通，我晕。经验呀。