五年.net程序员转型Java之路

大学毕业后笔者进入一家外企，做企业CRM系统开发，那时候开发效率最高的高级程序语言，毫无疑问是C#。恰逢公司也在扩张，招聘了不少.net程序员，笔者作为应届生，也乐呵呵的加入到.net程序员行列中。

C#.net非常容易上手，之前在大学里，做过winform和webform开发，也曾经在老师那里承接过小项目，赚点外快。于是在工作岗位上驾轻就熟，很容易就上手了企业开发框架，仅一年多，笔者就成为公司的开(jia)发(ban)骨(feng)干(xian)。

C#.net的网评比Java要差，笔者曾经在知乎上看到一个国外华裔程序员的文章，内容主要是国外的悠闲不加班的生活，文末一句：“忘了说 我是做.net的”引发了讨论的高潮。知乎程序员中，写Java、python、go、JavaScript几乎成了政治正确，作为.net程序员的笔者很少在相关讨论中活跃，但对java的印象已经有了改变。那时笔者所在的外企仍在大规模使用C#.net，笔者也就拒绝去接受网上的喧闹的声音，专心写好代码，学习设计模式和前端技术等等。

恰逢互联网行业发展势头正劲，笔者自然顺势而为，加入了一家规模稍大的互联网公司，当然还是写C#。由于之前在外企任劳任怨，什么活都愿意揽过来干，积累到不少很有用的研发知识和经验，于是在跳槽过程中顺风顺水，基本人家问什么，我都能答出来，于是相对轻松地加入了新公司，开启了互联网研发之路。正是亲眼鉴证了互联网研发模式，才让笔者确定了转型Java的决定。

新公司的框架很老旧，那时还在用.net framework2.0，业务代码非常复杂庞大，某个十年业务的项目里的一个方法，居然有一千多行，单是阅读代码，就让笔者心累，更心累的是，这一千行代码的方法名，居然被叫作“外观模式”（facade）……很难想象公司最核心的业务，跑在这么臃肿烦复的代码里。性能和效率都被看重的互联网研发模式，终于开始和C#.net产生了矛盾：.net framework和iis不开源。系统在运行过程中遇到了如下几个问题：

1、接口服务项目的访问效率遇到瓶颈，基本只能上负载均衡加机器。

2、某些大项目要数十台机器去承载日常访问，运维难度加大（后续上了持续集成和平滑发布，运维方便了很多）。

3、较少数情况，系统会出现一些疑难杂症，当产生问题的代码在闭源工具包里，调试人员几乎束手无策。（反编译的代码真难看囧……）

4、不断增加机器，成本增加，这可不只是机器成本，人家不开源，收费也不便宜……

5、可定制化较差。某些极端场景下，我们希望程序能够更大程度的消耗服务器硬件资源，而服务器程序都是别人的，人家为了安全都设定好“最佳阈值”了，很难更进一步压榨服务器资源。

6、缺乏开源社区支撑、大数据相关研发乏力……

7、国内部分互联网公司提供的开放平台工具，居然不提供C#的SDK……

诸如此类，不胜枚举。

转Java吧。

技术转型的阵痛在所难免。公司内的接口研发和后台管理系统研发是分开由不同人员负责，能够同时开发接口和后台系统的人并不多。笔者技术体系相对完善，在团队中获得不少尊重。也曾亲自带团队做研发，写完接口又带兄弟研究ckeditor源码并做定制化修改，忙的不亦乐乎。然而转Java成了笔者当时的心病：本职工作做得很好，团队不会允许贸然改用Java技术栈这种冒险行为。笔者已经私下学习了许久，却不能直接上项目实际操练，非常可惜。

精诚所至金石为开，笔者终于等来了一个机会：成为公司新项目的主程序员，负责整个项目的后端架构、设计和研发。新项目人员不多，但都是各类技术中的优秀人才，包含ios、Android和H5研发人员，笔者为他们提供接口，并开发后台管理系统提供给产品和运营同事。

独立负责设计和研发，工作量虽大，自由度却大了不少，于是笔者决定用Java来完成整个开发任务。项目leader对笔者的技术功底很是信任，不过仍希望团队用C#.net追求稳健，但看在笔者执着坚持，也就同意了。为了降低技术转型对新项目带来的风险和进度影响，笔者还是做了一定妥协：用Java研发接口服务，后台管理系统仍用C#.net。

接口研发期间笔者着实吃了不少苦头，项目框架搭建问题层出不穷，spring的运用不纯熟，导致经常在框架层面报错。新项目的座位与公司Java开发团队座位不在同一楼层，笔者几乎每天都要爬几次楼梯去Java研发团队取经。好几次遇到问题解决不了，都想放弃然后用回C#.net。项目leader多次看到此情景曾多次施压，笔者跟项目经理坦(zhuang)言(bi)：“如果Java搞不定，我会在两天内用C#.net把活干完，不拖项目进度。”靠着这份坚持和韧劲，还有多次对Java研发团队的叨扰，项目框架终于搭建完成，笔者也借着多次的取经，弄清楚框架的原理，完成了对spring的实践。拥有依赖倒置、控制反转的编程思想和设计模式的运用经验，理解Java框架的设计思路是很简单的，在框架搭建结束后，业务代码的输出几乎是行云流水，在项目完成之际，笔者都忘记自己曾是个.net程序员。项目最终顺利上线，并且仅用两台机器就抗住了较高的并发，笔者对Java有了更多的信任和喜爱。

有.net的编程基础，学习Java会相对容易，但必须逃离几个陷进：

1、对基础知识务必要重视：C#是一门非常出色的语言，它提供的语法糖让复杂的业务表达起来也十分优雅，搭配伶俐的lambda表达式和linq，数据结构的基本原理在大部分场景下都被弱化，而数据结构和算法正是编程的精髓。

2、对原理的渴望和求知欲：用C#编程，无法查看大部分程序集内的方法，只能自己上论坛找或反编译，求知欲可能会逐渐弱化。而写Java后，经常会自己ctrl+鼠标进入方法查看源码。这一点Java真是非常性感。

3、懒人思维不可取：C#.net对于链表数组等数据结构的排序和查询都做了高度封装，几个表达式就能得到想要的结果，而Java的表达式则没这么伶俐。在Java世界里，自己弄明白原理，自己写是更高效、更对得起自己的方案。

使用Java完成商用项目的开发，只是技术转型的开始，只能算踏进门，算不得转型成功。笔者仍花了很多时间学习Java的数据结构；学习Apache的公共工具包，偶尔点进去看看实现源码；继续学习设计模式及其应用。在一些评估用C#研发更容易的项目，笔者仍然坚持用Java去完成。为了能有更多Java项目练手，笔者申请进入了搜索引擎研发部门，通过了Java团队架构师的技术面试，加入了渴望已久的团队，最终能专职写Java做搜索引擎服务。当然，离开了当初的部门，也就抛弃了在老团队中的地位和荣誉，但笔者觉得很值。

在多年开发经历中，笔者确实感悟 语言是互通的，万变不离其宗。学习新语言只要下决心并付出努力，基本都能办到。然而后续的挑战则是更大规模的项目的设计思路，设计模式的运用，架构设计策略，代码堆叠方案，甚至是不同功能模块的技术选型。这些都需要仰仗厚重的经验、扎实的功底和日积月累的技术实力。

未来大数据和机器学习的热潮已经如火如荼的展开，手握Java这一门利器，运用storm、elasticsearch、Hadoop、lucene等绝技的Java程序员，必然能更好的适应潮流。