工作两周年纪念日 - 随笔 (1)

        不经意间看了一眼日历，发现今天是2010年07月07日，这个数字突然勾起了我太多的回忆，因为截至到今天我毕业后工作整整两年了，加上之前的实习的话，整2年零358天。

 

        3年的时间经历过多个项目，也接触过很多技术，从最初的Java，到PHP, ASP.NET, Javascript, CSS，到现在又回归Java，其间经历了几多波折，也曾面临过很多程序员面临的问题：要不要改‘语言’？是做后端好还是前端好？是做开发好还是做测试好？每个问题都困扰过我很长时间，每次都跟上战场的似的要下很大的决心。现在回过头来想想自己经历过的事情，有的让自己莞尔一笑，有的又让自己无限纠结，这大概就是传说中的“生活”吧。

 

        谈实习

        现在很多兄弟姐妹开始工作都是从实习开始，有的人对第一次看的很重，有的人就是随大溜咋都成。其实实习真的很重要，通过实习第一个可以解决的问题就是你是否适合这份职业，是否愿意继续这份职业，如果感觉不适合自己，那就赶紧另起炉灶找自己喜欢做的事情，开始下一段实习，如果这一切的工作都等你毕业之后再去体验，那真的有点儿晚儿。绝大多数人其实都是普普通通的平常人，没看出你比别人强多少，也没看出来你比别人差一大截，真正在毕业之后顺利走出IT行业的牛逼人物不怎么多，因为我们都是一群容易被各种各样的事情和谐的人，被社会和谐，被工作环境和谐。如果真的想做这一行的话，建议尽量找一个好一点儿的实习单位，至少是跟自己的某个理想吻合的单位。而在真正的实习期间，就放低姿态，多看多学多做，因为我们的目标是冲着更牛逼的单位而去的，如果你的姿态就是一个来打酱油的，上班踩点儿到，下班踩点儿走，分给自己的事情，点到为止，那你不要期望别人会对你付出很多，也不要期望你自己会学到很多知识，当然如果你属于课后自学型的那另当别论的，但是如果你能够在上班的时候多付出一些，课后自己再学一些，你不就应该变得更牛逼一些了吗？当然如果你没有实习过，毕业之后找到了很好的单位，恰好做的事情又是你真正喜欢做的事情，那我也真心的祝贺你。

 

        谈英语

        IT行业接触英语几乎是每天都在发生的事情，不管是看官方的document，还是在Google上搜索东西，大部分最终解决问题的资料都是英文的，如果你恰巧又在伪外企或者外企工作过，那还要经常写写英文文档，读读别人写的英文文档，尤其是新进一个项目组的时候，看到前辈们写就的几百页的蹩脚的英文，真的会有一种望洋兴叹的感觉，痛不欲生。曾经遇到一个同事，每次用Google搜索的时候都会去过滤中文结果，只看中文，但是在国内真的是有太多的咸猪手喜欢copy-paste了，于是乎在搜索结果的第一页有时竟然都是一篇帖子的翻印版，没办法，真的是解决不了问题，所以只能打道回府说自己解决不了这个问题。其实作为新一代的有为青年，估计都被英语蹂躏过，但是经过大学的洗涤之后，基本上算是漂白的差不多了，但是生活还得继续不是，所以英文的帖子，英文的文档还是要去看的，其实根本用不着去死记硬背那些单词，因为几乎所有不认识的单词在事后都被证明属于专业词库，所以一天见八遍的单词，不用背也就记住了，慢慢看，慢慢适应，慢慢的改为使用Google.com搜索，输入英文关键字，看英文帖子里的解决方案，如果你恰好闲的慌的话，把人家的翻译翻译总结总结，自己发篇中文版的帖子，以佑后人，但是咸猪手党们，还是多回复原帖，收藏的好，不要咔嚓一转就成了你的帖子了，这样只会导致无用信息冗余，有用信息石沉大海。

 

        谈加班

        万恶的资本家！！！估计这句话被念叨过不知道多少遍了，但是还是那句话，生活还得继续，加班还得继续。曾经有很长的时间，每天都要加班，每天都是跟哥们一起赶最后一班东川专线，好像是10点50的，day by day。有一段时间骑自行上班，晚上11点多，一个人骑着自行车回家，呃，那时候好像住在唐镇，还真是有点儿害怕，黑天半夜的，虽然有路灯，但是路上是万籁俱寂，有点儿吓人。有时候项目紧的时候加班到凌晨那是很普通很平常的事情，09年欧冠半决赛的那天加班到3点半，直接没回家，在公司看完了比赛，趴了一下会儿，继续上班，想想真的挺牛逼的。但是目前国内软件行业还处于起步阶段，虽然起步了很多年了，但是还是有太多不规范的地方，或者说我们自己都还没有摸到门道，所以在milestone release的时候，或者online的时候，不加班，几乎是不可能的事情，所以后来在加班的时候总是会去思考一个问题，为什么需要加班才能完成？为什么每次在release之前总需要加班6个小时才能完成？为什么这些需要加班6小时才能解决的问题不能在之前一个月的时间里解决？为什么项目总是前紧中松后抓狂？想的多了，对软件开发的理解也就多了，会去关注一些管理方式，会去体验一下TDD的开发模式，等等，总之遇到的负面的东西越多，反而需要学习的东西更多，日积月累，应该会有收获吧，总之一句话：多看，多学，多想，多做。

 

        谈Coding Style

        Coding Style是我经常谈的问题，几乎每过一段时间就要找人掐一顿，乐此不疲，中国有句古话：字如其人。我想对于终日以敲代码为生的程序猿而言，Coding Style也应当恰如其人。正如字如其人一样，不是说字写的不好，你就不能成大事立大业，coding style差的也不是说你就写不好代码，完成不了活，一个好的编码规范就像一个爱美的人打扮自己一样，总是把美的一面展示给别人，如果你是在家蜗居，那你光着屁股满屋跑也没人管的着你，但是如果你邋邋遢遢的上街出门，那就会有人在你背后指指点点了。开始写程序的时候，要注意培养，并且要坚持一种有效的编码规范。

        1. 命名规范： 包命名，类命名，方法命名，变量命名等。诸如包名类名变量名是名词，方法名是动词或者动词性短语，这些应该都是基本的常识了，至于CHnglish式的命名应该坚决杜绝，尤其以拼音首字母缩写最为恶劣，诸如submitQQ()此类的方法名，大家以为是和QQ通信，原来你的意思是“submitQingQiu()提交请求”，估计敲破了脑袋也想不出来。

        2. 注释：如果你不能保证你的方法能够让别人一看就知道是做什么，怎么用，那你最好还是加上comment，包括代码段里的一些单行注释有时候也是必要的，在任何情况下写代码的时候都要考虑的一个问题就是别人能不能看懂，如果别人看不懂你就要解决两个问题：第一，你的代码是不是可以优化，使别人能看懂；第二，如果不能优化，你需要添加必要的comment告诉别人你要表达的意思。之前有一段时间我是崇尚不写注释的，这里的不写注释指的是把程序优化到别人一看方法名和参数列表就知道这个方法是做什么的，怎么用，但是最近我打算放弃这种想法，从UE的角度来讲，我们需要站在用户的角度去考虑，但是不要完全把自己当成是用户，因为真正的用户和我们的context是不一样的，所以也不要让别人“被理解”，而且为了生成比较漂亮的java doc，注释也是必不可少的。

        3. 缩进/排版：当你看到一个层次分明的代码的时候会有什么感觉？很爽，我是这种感觉。既然看着很爽，那为什么不让自己指下的代码也层次分明一点呢？看过以前同事写的代码，真的是痛苦的要命，完全随性而为，他的代码要说完全没有缩进也不是，他是一块一块的缩进，估计他写代码的时候从来不关心整体，只关心眼前看到的这一屏吧，否则真的很难产生如此效果。有时当朋友或者同事传过来一段代码让我解决问题的时候，我一看到那满屏乱七八糟的排版，真的是火冒三丈，本来挺想帮的，结果弄得一点儿心思都没有，为了看懂他究竟写的是什么，我就要在那儿颠颠儿先替他缩进了，IDE支持的还好，格式化一下就好了，没有IDE的情况我只能是怒火攻心了。如果你的老板一个心血来潮review一下你的code，估计你会很痛苦的，当然了，如果你是及其牛逼的，项目组的顶梁柱，那老板可能敢怒不敢言了，先忍着你，但是既然你已经是顶梁柱了，那你的代码就要给很多其他同事去参考学习膜拜，他们会诅咒你的，放心吧。

        当然关于coding style的细节问题还有很多，这里简单的举上述例子说明，有时候跟别人讨论这个问题的时候，有些人会说这有点儿浪费时间，当然这么说的人不多，但是这些事情真的浪费时间吗？它不但不会浪费你的时间，反而会为你节省很多时间，创造一个很好的编码氛围，如果你写的恶心的代码要交到code freeze之前去来个通盘大整理，那你可能真的会死的很惨，一是你不能保证重构之后能否通过所有测试用例，二是这本身就是时间的巨大消耗。当然你可以不整理你的代码，但是如果你的客户也是业内人士，那估计这也是你从这个客户手里拿到的最后一个项目了。为什么说不浪费反而是节省时间呢，当你下意识的要定义那个方法名为submitQingQiu()或者submitQQ()的时候，如果你能在这一瞬间将名字命名为submitRequest()，那应该是没有任何时间损耗的； 如果你在敲下一行的代码的时候能跟上一行代码对齐，那顶多就是多敲4个空格或者一个Tab键（提前定义好1 tab = 4 white space）的时间损耗的；如果你在写完代码，保证它能正常work的时候加上注释，那应该比你回过头来，绞尽脑汁的想当初为什么要这么写，当初是怎么想的消耗的时间要短。其实coding style是你的一种习惯而已，就像写一手好字和一手烂字一样，写一个字的时间是没有太大差别的，差别就是，如果有一天你不得不把你写的一纸烂字扔掉，重新用一手好字重写的时候，你会灰常灰常痛苦。

 

        《未完待续 .... 》