最代码官方的gravatar头像
最代码官方 2014-10-14 22:15:42
最代码10月第2周回顾(10.6-10.12@2014)

最代码10月第2周回顾(10.6-10.12@2014)

网站总结

    请关注最代码公众账号zuidaima,每周推送精彩内容.

    另外广告点击很少,也希望大家可以多点击下和自己相关的广告以帮助网站得到一部分运营费用。

资讯精选

如果 40 岁了还在写代码,是一种幸福,还是一种悲哀?

马上就40了,依然在写代码,写各种代码,从C/C++写到object-c,从java写到lua,乐在其中,享受得很。
当然,我现在基本不是依靠写代码挣钱谋生,事实上,我也几乎也没有纯粹依赖过写代码谋生过。写代码只是一种乐趣,一种爱好

当然,难道是写代码谋生就一定是痛苦的吗?也未必。

公司有两个同事,都是非常棒的程序员,也是成熟的架构师,一位是77年的,一位是78年的,他们主要的工作内容都是写代码,他们也都乐在其中,事实上,如果不出意外,他们能够在公司里继续留下一起合作,我想他们会一直写代码写到40岁。他们都是非常非常出色的技术方向的专才,不写代码,浪费了他们的才华。他们现在写代码也写得很happy。

顺便说一句,我,包括上面说的这两位同事,都是有家庭,有小孩,上有老,下有小哦。
其实,40岁写不写代码,不是问题,40岁是不是还依靠写代码挣钱,也不是问题。
关键在于你热不热爱写代码这件事情,以及你写的是什么代码?

如果你在写代码中没有收获任何乐趣,不用40岁,20来岁写代码就是一个悲剧。
一个人被迫在做着他不喜欢的事情难道不悲剧么?
更如果你写的都是一些为了交差的垃圾代码,无法收获任何成就感,那么更是悲剧中的悲剧

写代码也不意味着低收入,(其实关键看你写的是什么代码)。我们上面这两个同事的薪水就不低。收入超过项目经理,部门经理,且没有业绩考核压力。
另举一个例子,一个朋友,50岁出头了,专门写大机代码的,这样的人现在很难找,月薪数万,随便出个场,大家都得哈着供着,NB啊。曾经和我聊天,说大机消亡的时间节点,和他的职业生涯长短正好吻合,写了一辈子大机代码,还顺便给这门技术这个领域送终,感慨并幸福着。

以上案例,全在中国大陆。

其实现在这个年景,对于这个问题,我们可以逐渐少谈中国国情了。经历了这么多年的发展,中国的软件业也逐渐成熟起来了,有时候,有些地方,已经不那么“中国”了。
对于以后的将来,我更为看好,国外那些著名的“老年程序员”的经典案例,在中国经常出现的话,一点不用意外

一个人的离职引发的一些感想

前言:今天一个刚来的同事离职了,说的一部分原因是由于“他问我一些问题,我总是草草了事,没有认真作答”,虽然说的话给我留了很多情面,但是一个刚来的同事就这样在项目紧要的时候离开了,无论怎么样,对项目的进度都是一个损失,我先反思一下自己的原因:

第一点:个人管理经验欠缺

        虽然自己在两年前就在江苏富士通担任了Team Leader,从11年7月毕业到现在已经有了3年多的时间,但是自己还是偏重技术的开发,在如何调度每个成员的情绪,如何管理项目的进度,如何分配自己的时间穿梭于不同项目之间的任务上还欠缺太多实践的经验。

第二点:个人业务能力欠缺

        回到洛阳已经有了将近8个月的时间了,在交易平台项目上经历了很多锻炼,有很多遇到的业务问题,都是自己经过很多很多的探索才完成了一些业务开发,但是期间领导和同事帮助了我很多,自己一个人扛起一个项目的努力还很欠缺,针对这次开发的项目,自己没有独立去认真思考过其中深入的业务层面问题和细节实现,导致自己在向成员分配任务和讲解业务时没有让成员有清晰的代码编写思路。

第三点:个人参与度不够

         对于这次开发的项目,客户要求的时间非常紧迫,而自己又频于去忙碌另外一个项目,导致自己对于本次开发的参与度不够,很多任务自己都放手交给成员去做,对于其中存在的问题,自己并没有发现,而自己犯的一个重大错误就是一直在等待成员发现问题后和我沟通交流,而没有自己没有去研究每个业务细节和实现方式,自己只是搭建了一个DWZ和postgre的整合环境,然后做了权限验证、session管理、列表的增删改查以及webservice的业务实现,而成员但当的任务自己没有思考的细节。

第四点:个人沟通技巧不够

          虽然自己苦口婆心的向成员展示了很多自己的业务认知,并且每次都“低声下气”的求着成员的进度,但是自己的认知并没有被这位离职的同事认可,也许在他看来,我没有去认真研究每个业务,没有认真去研究每个细节,然后去告诉他该怎么去编码,就是所谓的coding,而不要让他去思考那些业务,和实现方式。这使得自己出力而不讨好,并且还惹恼了这位离职同事,使他对项目失去了信心,对我失去了信心。

第五点:其他原因

         也许这位同事做惯了以前在外包项目中的那种业务完全清晰下的代码编写工作,也许这位同事缺乏抗压能力,也许这位同事压根就没有在我们团队做出自己贡献的准备,也许这位同事觉得IT只是coding,而没有业务架构construction。

总结:首先,我得向团队和领导说一声抱歉,是自己的原因造成了成员的离开,而成员的离开也影响到了项目在接下来的任务进展。

        其次,自己需要好好的反思,总结,为什么自己辛苦的付出了,反而会对团队造成消极的影响。

        再次,是什么让现在的软件开发者如此的浮躁,没有去征服这些困难,而是去逃避自己的责任,为什么不想着经过自己的努力创造出属于自己的价值,而是遇到一些挫折就转身离开。

        再者,是什么使上司在拼命的为项目着想,而属下却在不断抱怨自己没办法开展工作。上司不仅仅要照顾这些人员的生活情绪,还要去承担后果。

        最后,也许这位同事的离开是对我们的团队质量是一种保证,如果一个成员没有一个积极向上的心态,没有迎难而上的动力,那么他永远不会为团队带来成长。

希望:做个挨踢人,我们需要梦想,需要通过自己的努力,为团队带来自己的价值,如果你是有价值的,公司自己会给你应有的回报,如果你努力了,没有得到回报,那么你值得离开,寻找重视你价值的公司。

做Java开发这一年

从去年到现在,从.NET转向Java开发(只是因为项目原因,绝对与平台好坏没有关系)差不多有一年的时间了。通过这一年时间也有些感触,想从几个面比较一下这两个平台。希望能做到客观公正。

  语言

  我原来是使用C#语言的,和现在的Java语言相比,现在的Java语言语法就停留在C# 2.0这个年代。语法结构都非常传统,中规中矩。很突出的一点是,因为缺少对闭包的支持,有些用C#很容易做到的,用Java需要写很多废话代码。

  前几天InfoQ上发表了一篇英国卫报逐步采用Scala替换Java的文章里一句话用的很好:看Java的代码很容易让你只见树木,不见森林。因为为了实现某个功能,你需要太多的支撑代码,而实现功能的关键代码却迷失了。

  举个例子:我需要一个排好序的用户列表,排序的依据是用户名字。很简单的需求对不。自然的代码肯定是这样的:

  IList users = …

  users.OrderBy(user => user.Name);

  而如果用Java实现同样的功能你可能要这样写:

  List users = …

  Collections.sort(users,new Comparator() {

  public int compare(User left, User right) {

  return left.getName().compareTo(right.getName());

  }

  });

  第一:没有扩展方法的支持,只有借助静态的辅助类

  第二:没有闭包的支持,非要写个难看的匿名类

  其实我们只需要一个OrderBy,一看就明白,但现在多了这么多“无用”的代码,反而核心的价值(order by)却显得不那么重要了。这还是一个很简单的例子,在实际的项目中你会为此付出更多的代价,你要写出一堆味同嚼蜡的代码才能实现你想要的那个功能,而那个功能其实是很显而易见。

  所以在语言层面,Java没有任何亮点,只觉得罗里罗嗦。

  关于语言层面的比较,老赵写过很多,而且非常精彩,建议去欣赏一下。

  不过Java也有那么很少几个有点意思的小东西:比如静态导入(脑袋提醒,这东西很早就在VB里出现了)、以及Java对Annotation的特殊支持让我们可以做一个更有意思的事情。

  概念满天飞

  做Java以来,让我感触最深的是在Java世界里概念满天飞。ORM,IOC,AOP,这几个在.NET的世界里也有,但没见过这么浓的,但是如果你做Java应用,你不熟悉这几个你都不好意思出去跟人打招呼,所以除了学习Java本身外还有一大堆开源框架等着你研究。

  还有什么View Model,Presentation Model,Validator,BRO(Business Rule Object),BPO(Business Process Object),BDD。关键是不仅是概念上存在这样的名词,它还大量的出现在代码里。代码里将概念描述得淋漓尽致,还规规矩矩。或许我土老帽了,我开发.NET三年有余,从来没整这些玩意儿。但是我一点也不怀疑我的代码难以阅读,难以维护。

  配置文件,你能再多一点么

  我超级厌恶Spring的配置文件(虽然你说这只是个框架,但貌似Java社区有这个趋向)。虽然Spring现在也增加了注解(Annotation)的支持,但是还有那么一些知道的和不知道的原因,项目中存在大量的配置文件。而且为了“模块性”,一个小小的配置文件又包含有几个配置文件。有配置controller的,有配置DAO的,有配置service的。额,还有那该死的Hibernate的hbm文件。我想,系统的复杂性就是这么一点一点的堆积而来的。

  ASP.NET的配置文件一度也有变得更臃肿的趋势,但最后还是大大瘦身(.NET 4.0里默认的web.config很小了)。而且Attribute在.NET的第一个版本就出现了,很多可配置的东西都提供了Attribute的API和XML的API,所以没有历史遗留包袱。

  开源,这个我喜欢

  Java里的开源软件远远超过.NET的(这可能跟微软有一定的关系吧)。如果你想完成一项工作,总会有一个开源软件适合你。比如我们要做一个定时调度的任务,马上就有Quartz跑到了你的视野,你只需实现几个接口,然后在配置文件里配置一下(又是该死的配置文件),又比如你苦于在Java里没法像C#里那样用Lambda,马上有个跟你一样想法的人开发了一个lambda4j(Java人有个说法是:语言不足类库来补,不过Java这个语言太不足了,所以有的时候类库补也补不好)。你可以在琳琅满目的开源框架和开源类库里寻找一个最合适的,然后打开这个潘多拉魔盒。最主要的是她还是开放的,你不仅可以学习其代码思想,如果你发现有问题你甚至可以提交代码,那种成就感我倒是在开发.NET时没有感觉到。比如你要开发高性能服务器,在.NET里还没见过这类的开源项目,可Java里你可以学习Netty,可以学习Mina,你甚至可以根据自己具体的业务场景,对这些开源软件进行适当的修改。当然,你可以说思想是一样的,这倒是不错。但因为IO模型在Java里和.NET里并不一样,所以还是有很多不同的(当然我觉得.NET的异步IO更容易使用,Java的NIO那是什么狗屎一样的API啊)。

 IDE

  搞开发的肯定离不开IDE。.NET里的IDE当之无愧的是Visual Studio了。不过我却觉得Visual Studio这几年已经离开发人员越来越远了,好像他要搞什么全生命周期的软件开发工具。所以不但臃肿,而且对开发人员并不是很友好(当然,她的可视化设计器是无与伦比的,但我不觉得可视化设计器是什么开发人员的“利器”)。举两个例子:VS里大量使用组合快捷键。这样不仅使得快捷键过长,难以记忆,而且还好难使用啊,你必须按两次,而且时间不能间隔太长。还有VS的重构功能,太弱了。

  在Java里有各种各样的IDE,有免费的,有收费的。我很喜欢的一个就是Intellij Idea。Idea给我的印象就是,她真的是在关注开发人员(写代码的)这个角色。所有的快捷键都很简单,好用好记。比如,大部分东西在Idea里可以使用Alt+Enter这个万能快捷键解决(这个快捷键是上下文感知的,在不同上下文中它知道要干什么)。

  再就是Idea对重构的支持,如果你熟练之后,做一项大的重构你都无需手动的去修改什么代码,直接依靠IDE的支持就可以完成,这在安全的重构里是很重要的一点,手动的去修改代码重构如果在测试不完备的情况下风险是非常高的。

  当然VS也有很多非常好用的插件,可以提高开发效率。比如大名鼎鼎的Resharper就来自于Intellij Idea同一个公司,由这个插件你可以看到Idea是如何关注写代码的人的效率。

  JVM vs CLR

  一般的,Java跑在JVM上,C#跑在CLR上。从技术实现上他们两平分秋色,各有各的优点,我们不能评价他们的好坏。只能说可能JVM在XXX上胜过CLR,CLR在XXX上胜过JVM。而且JVM和CLR有居多相似之处,大多数东西都可以在对方找到相应的东西。

  那么她们就无法比较了么?不是,经过一年的学习我表示我更喜欢JVM一点。

  JVM(在这里只假设是Oracle/Sun Hotspot JVM)暴露了众多的配置参数给开发人员。你可以通过这些参数间接地控制JVM的运行。就比如GC吧,JVM里有各种参数来控制各个代的大小,还可以通过参数让JVM采用什么样的垃圾收集策略。因为不同类型的应用:比如桌面的、服务器端得、内存小的等等不同类型的应用适合不同的垃圾收集策略。而CLR在垃圾收集上只给开发人员提供了Workstation(是否是concurrent GC,.net 4.0是background GC)/Server等很少的控制(不过也几乎很少用到)。当然,如果你想最大化控制CLR你就只有自己Host CLR,然后调用Host API进行控制,但是那样难度高很多。

  我很愿意承认CLR是自适应的,她能自动的智能的识别出你的需求,然后自动的进行调整。不过我在这里主要想到的是,微软在这里扮演着保姆的角色。在你很小的时候,保姆能够在一定程度上保护你,免你受到伤害。但是你不能永远生活在保姆的怀抱里,如果你想变得更强大你需要自己独自一人出去看看。

  注:这一节不是比较JVM和CLR,因为我没有那个能力。只是想从JVM和CLR所表现出来的差异来看看一些“看不见的东西”。

  开发人员

  上面主要谈了技术层面的东西。现在说说软件开发中的人。

  我现在所在的公司面试有个特点:会让面试者做一份家庭作业,然后让公司同事Code Review。在这一年里我看了很多Java的代码,也看了很多C#代码。但是我伤心的发现:

  1、虽然Java的也有烂代码,但是Java代码大多更注意代码的美感。大家都非常注意选择方法名,变量名,类名等。也非常愿意写一些小的,容易理解的方法,小的目的明确的类。可我亲爱的.NET同行们,大多在这方面很随意。一个方法200行不算长,甚至一个功能就放到一个方法里实现了。我看呀看呀,都看不到尽头。更别说类职责单一了。

  2、测试 Java同学的代码大多有测试,虽然有的测试不怎么好,但最起码有那么几个测测核心功能。但是.NET代码呢?很难见到几个有测试的(难道这是因为VS很晚才加入对Unit Test的支持有关?)。我不是说一定要有测试,我只是描述一下这么个现象。

  3、你也太随意了。我见到有那么几份.NET代码,我知道你创建了一个WinForm的项目,然后你却不把VS自动生成的那几个Form1.cs,Form1.resx给删掉。

  4、构建 从构建这个层面就更显出问题了,Java同学提交的代码大多有构建的脚本,无论是Ant还是Maven,所以你只需要敲一个命令行,马上可以看见人家的结果。而.NET同学的基本上都是sln文件。这一点不是说谁好谁坏的,因为我之前做.NET也从来没有自动构建脚本,我只想说两个社区有些不同。

  后记

  我在这里并不是贬低某个社区的开发人员,也不想扯进任何平台的纷争。因为这只是我看到的现象,还有很多是我没看到的,而且这也严重的受到我周围同事的影响,所以难免以偏概全。

  如果有不足地方请不吝指教。

 

    最近发起了最代码的推广活动,希望每个支持zuidaima的都可以帮忙推广下,活动地址:最代码推广活动,有你参与更牛币
    最代码每周都很精彩,有你会更精彩,请访问http://www.zuidaima.com。欢迎转载分享该文章, 欢迎推荐给身边的小伙伴们
    欢迎关注最代码的官方微信账号zuidaima,最代码官方新浪微博:http://weibo.com/zuidaima,最代码官方腾讯微博:http://t.qq.com/zuidaima

    淘宝店铺:http://www.zuidaima.com/taobao.htm


打赏
最近浏览
低调人  LV38 2018年4月22日
笑谈一纸风  LV3 2016年11月2日
39167943  LV4 2015年11月15日
xiaojun257  LV1 2015年8月19日
永远知音  LV18 2015年5月8日
yangjj0520  LV5 2015年4月27日
zuimashi  LV9 2014年12月18日
huaxinwu  LV10 2014年12月3日
yangyuan  LV2 2014年11月26日
qianghuang  LV2 2014年11月17日
顶部 客服 微信二维码 底部
>扫描二维码关注最代码为好友扫描二维码关注最代码为好友