程序的思考

一个古老而又广为人知的谚语说道：“正确第一，效率第二，如果答案错了，程序的速度就变得无关紧要了”。正确还是错误？

前段时间做了个C的项目，我一直负责算法的部分，说实话算法确实很烂，不过感觉程序的运行效率还算OK，也能满足用户体验的需求。

一直在自我安慰以及劝导同事"能跑，并且不出问题的代码才是好代码，至于你代码写的多漂亮已经不是重点了"；

在一个没有严格代码审核的项目组，没人关注你代码写的多么的漂亮；他们只是关注你写的程序是否能跑，以及是否稳定。

还记得以前在外企工作的时候，都会有人审核你每天所提交的代码，还记得有一次修改大洋彼岸一位同事的代码，

当时他定义了两个变量做双重循环的参数，l1，l11，当时为了修复一个issue不得不添加一个循环，为了代码风格统一我就自己新加了一个参数 l111，

第二天米国那边发来邮件大意为“我很惊讶，既然能编译通过”。显然他将 l(L) 看成可 1 ，关于这个问题我只是像我当时的leader解释了一下，后续的解释工作也是他帮我完成的。

而今天，哪怕你将代码定义成 l1111111111，l111111111111111... 也不会有人管你。因为场景，环境都不一样了，

在外企的时候一个一年的项目在现在单位只需要两个月，最多再加三个月至半年的维护期，我承认这样的团队很有战斗力，我也承认现在的公司已经通过CMMI5了，很多人很迷信这一可笑的认证。

但是没有办法最求不一样，如果我们追求的是优秀的话，那么老外追求的是卓越。并非崇洋媚外，只是经验之谈。

老外的工作习惯是花跟多的时间将一件事情做好，注重工作流程；而我们是花少量的时间做好一件事，注重工作结果。

两种截然不同的工作风格目的却是一样的，就是将工作做好，达到预期的效果。

但是前者会让我们的工作生活很happy，不会那么累，enjoy工作的过程。而后者更加注重于效率往往一件工作没结束就开始新的任务，人会很累而没有激情。

与时俱进，因地适宜。不管怎么样的严格的审查机制，或者是多么懒散的管理制度。重要的是融入其中，适应当前的工作环境，形成自己的style尤其重要。

你觉得怎么做能够提高工作效率，其他的都不重要，什么软件工程，代码规范都是扯蛋。不是说他们没用，而是需要根据场景去定制一些东西，你的style就是你的规范。

至于文章的开头提出的问题，是我在《编程珠玑》中看到的，个人认为是正确的。

有两种代码我是不会就看的，一是，不能运行的，二是，不是我能力范围的。