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