在魔都两年工作小结

转自一个高中同学博客 http://user.qzone.qq.com/853436204/blog/1345288142

以下仅为个人观点，如有异议，欢迎拍砖。

 

    话说昨晚由于太累，下班回家后就躺床不起，等起来看时间时，忽然发现已经8月份了。蓦然间，才发现又一年过去了。如果加上实习的一年，我这个2B青年在码农界已经混了两年了。虽然称不上老狗一条，也算是有所感悟吧。 怎么说呢，这两年，经历了相当多的事物：技术上的，人事上的，处事上的，处世上的。很多很多。如果要全部说出来，恐怕我这张八婆嘴半天停不下来了。所以我就捡最简单的事——写代码说起吧。 代码这个东西，说简单就简单，说难也难。从最初在大学的啪啪啪到现在的啪。。啪。。啪，可以说的确改变的不只是速度。很多时候，自己觉得：要写出很好的代码，力不从心。因为注意的实在太多太多。由于种种原因，很多时候简直无法顾全。但是下面的几个标准，我可以说做到了，所以我相信对于这些，我有发言权。 

 

    1. 健壮。这里的健壮性和行业术语“鲁棒性”还是有差别的：毕竟我没有还那么牛，能够写出那么强的代码。 我说的健壮性是指：写代码的时候，要想方设法避免自己容易犯的低级错误。我相信每个人在做事的时候都有一些坏习惯，而这些坏习惯很有可能演变成以后的隐患。而改变这些坏习惯显然不是短期内容易做到的事情，甚至有时候永远也改变不了。比如很多人吃饭的时候喜欢bia ji。而我的对策就是： 想出一个策略，能够让这些坏习惯的危害减少到最小，并且标记那些容易引起坏习惯的地方。比如，赋值符号“=” 和 比较符号“==”，我相信有一部分同行特别容易写错，尤其在条件判断中，不留意就把比较符号写成赋值符号。我本人就是喜欢这么干。而相应的策略就是：在条件判断中把常量写在前面。当然，我相信这个策略很多同行都知道。我的意思也不是以此居功， Instead， 我只想说这种策略的确容易接受：至少我现在还是喜欢混淆这两个符号，但是由于每次在犯错的时候，系统都会提示错误（用VI写代码的牛人可以无视）。在不让自己痛苦的同时，降低甚至消除了这个坏习惯带来的风险，何乐不为呢。当然，还有其他方面的一些策略：比如应对不可见字符的策略，比如动态绑定不确定的策略等等。不再赘述。总之，用新的策略去减少坏习惯带来的风险，以此增加代码的健壮性，至少是简单加愉快的。 

 

   2.简单。怎么说呢，这一点是与我大学时候的观念有冲突的：在大学，想着各种犀利的算法，各种强大的设计，各种神一般的写法。比如最经典的一个问题就是：用最少的代码，给出给定日期的下一天是什么时候。当时我是各种膜拜那些牛人，觉得他们就是高手，应该向他们看齐。然后带着这些想法，来到公司，换来各种挨骂。。。 后来，渐渐发现，在企业开发中，我发现：那些都是浮云，真正好的代码，满足的条件虽然有那些因素——尽量少，算法好，设计完美。但是这些都是最后才满足的，也就是说：还有很多前提条件的。比如当初我经常被问的一个问题就是“ 你自己哪天哪天写的代码， 现在得花多长时间才能看懂”。这是个很实际却经常被忽略的问题。当然，我也不赘述这个问题的答案是什么，因为仁者见仁，智者见智，懒者见捷径，蠢货见笔头。还有一个问题就是“你为什么这么写，一定要这么写吗”。这个问题问的很刮骨——很容易被问的语噎。比如说很多人喜欢多进程，多线程，或者搭建很多框架（这句话可能有些显摆的意味，换个语境应该会好点：很多人喜欢在自己的电脑里面装N个安全软件，什么360，卡巴，QQ管家啥的，也不管是否真的有这个必要）。但是我相信，有部分人在这么做的时候，根本没问过自己为什么。或者有人问过自己，结果以“这样方便”或者“这样踏实”安慰自己。这样做的结果，可能是安全隐患，也可能是啥事也没有。当然，作为同行，我祝愿这些人遇到的都是后者。但是，我觉得，这样做至少不算个普适性的好习惯，——毕竟在实际操作中，开发者经常面临很多的资源限制：硬件性能（我相信现在这个限制应该好点了），成本限制，人手不够，时间限制，维护难度等等。在这么多的约束下， 我觉得，开发者应该做的，是在众多选择中不得不选择一些，然后在这些中选出最优的方案。我相信，不论在哪个领域，一般情况下，很多最优的方案，往往是最简单的，最自然的。选择如此去做， 一方面可以大大减少代码的简单度——对于闻名的方案，天下谁人不识君，一读便懂；另一方面，可以大大减少自己的设计时间——至少你不用自己去琢磨该咋样咋样才最好。风险也少，又节省时间，何乐不为。当然，那些从事于性能优化的人请绕道，毕竟本人没那么犀利，这些观点不适合你（没有半点讽刺意味）。 

     当然，以上说的都算是大的方面，毕竟只有在全局设计的时候才会遇到框架或者方案之类的问题。When it comes to coding, the word “easy” means: natural.也就是说：自然的，才是最好的。比如多个变量reset, 很多人都喜欢这样写:a=b=c=d...f=0;当然，这样写也未尝不可，而且看起来代码很少。但是，殊不知，这样的写法，至少有一个隐含的意味在里面：这些变量都相等。当然，我说的这句话是废话：大家都是0，当然相等。可是，我们当初的目的是reset这些变量，而现在这么做，第一个给人的印象就是：你让他们相等，然后别人最后看到0， 又得出结论：他们都等于0，然后读者自己推断：都相等且等于0，然后读者得出结论：他们都被reset了。当然，这个推论过程没有错，而且不怎么占用时间。可是这么做，是不是有点喧宾夺主甚至会曲有误周郎顾呢？目的是什么，我们就怎么做，我相信这个道理应该不会错。所以，上面直接写成“a=0,b=0,c=0....f=0”:这样多清晰——至少让读者第一眼就知道：哦，你是让这些变量reset。当然，很可能经过底层优化，上述两种做法的最终运行代码都一样，而且运行结果肯定都一样，但是给读者的感觉显然不同——代码不仅是要运行的，更是要维护的。 总之，简单就是美。 

 

   3.简洁。初看起来，代码简单了，很多时候就臃肿了，就与这个观点矛盾了。其实不然，由于简单导致的臃肿是我们选择的结果，不用去在意——鱼和熊掌，不可兼得。我说的简洁是其他方面的。 我相信很多同行从事过维护别人的代码，我也相信很多人在读别人的代码的时候不知道问候了多少个以及多少次代码作者的家人。其中很普遍的一个原因就是：那些代码就像老太太的裹脚布——又臭又长。那么我想反问一句：我们自己写代码的时候，是不是考虑过这个问题呢？比如我当初，写代码很喜欢ctrl C + ctrl V， 或者一个函数就像没节的竹竿——一口气到底。我不知道同行们怎么想，至少我现在很后悔当初这么做:阅读器来真坑爹，哪怕是阅读自己写的代码。所以我认为，写代码还是要要考虑到一些简洁的规则：比如， 相同的代码段不要出现两次，比如说，一个文件里的函数不要出现超过两层调用（我说的是一个文件，跨文件调用请绕道），比如说，一个函数不要多于一个屏幕显示（如果你说你把长屏竖过来我只能摊手），比如说。。。类似的经验还有很多，都记下来的话， 即使不是 mission   impossible， 也得remember the alamo了。对此，简单的方法就是——写代码的时候经常告诫自己要简洁。 长此以往，你就会自己总结出很多经验，我相信这些经验都是合理且有效的（至少我这么试过）。当然，如果哪一天你觉得做的够好，然后到网上去搜一下相关经验， 我相信你会发现：很多经验你已经具备了。Just try and prove it! 

 

    末了，我感慨一下：要想写出好代码，甚至仅仅是合格的代码，还要注意很多东西，上述三点也仅仅是我自己总结的经验中的一部分。由于时间限制（快下班了），我也懒得赘述，权当抛砖。