我的2015下半年总结

  随着工作年限的上升，花在写博客上的时间越来越少了，14年写了一篇，15年写了两篇。并不是由于没有在继续写代码，没在研究新的技术，可能是心态问题，有些事情一旦没有继续坚持就容易变成一种惯性,如下图：

    
 
  06年到15年，完整的十年。

  十年老兵，算算已经过30几年了，刚开始工作时不断的听人说在中国程序员超过30如果还在做程序员，那么就会被后面的年轻人淘汰掉。这句话说的倒是有半分道理：如果老兵五年之后每年都在在吃老本，一直凭借五年前的经验混饭吃，那么五年后的确非常容易被淘汰，因为五年后的技术已经天翻地覆，对程序员的技能会有新的需求，此时不思进取的老兵在纯技术上跟刚工作一两年的年轻人的起点基本是相同的，而且年纪还是一大劣势：不光是人的学习精力没有年轻人旺盛而且时间上也不会有年轻人那个集中，我们会花很多时间在家庭上面。这也是很多人说过了30要转管理的原因，因为大部分人认为做了管理手上的事就少了，毕竟具体的活吩咐小兵做就可以了。但如果是一个一直对技术保有激情保有憧憬的程序员来讲，他每年也会吸收学习新的技术的话，那么在30+之后没有理由被淘汰。可能是时代变了，其实我周边也有不少像我一样30+的人也还是在写代码，国外更多例子了，好多老头也在写代码，而且写的很好。

  

  我暂时不总结2015上半年的所得所失，先总结2015下半年的种种情况：

•   .net转JAVA过程中，这里我列表的是几个JAVA新兵做过的事：

      

• • 设计文档中将hashMap写成set，比如Set<int,int>,在技术评审时立马就被JAVA老鸟纠正过来。刚开始只做设计，没编码，所以出现此类事件。
  • 不知道JAVA基础数据类型与.net不一样，比如Long与long是不同的，Long是个引用类型，允许为空。.net中的Int32与int都是值类型，不可能为空。 这里还有个小问题一直没有研究，JPA工具生成的数据库类对象，将不可为空的自增主键也映射成Long，而不是long，其实我希望是long。

• • JAVA中的decimal很不适应，.net中，它可以直接像使用int一样直接使用，但java中没有这个类型，只有一个对象BigDecimal，无论是初始化还是做操作都是基于类的，很不爽，所以很容易出现直接用+-*/直接操作BigDecimal的想法。
  • 字符串判等，直接会写if(companyName=="FB")，结果发现功能不正常，仔细看代码也未发现哪逻辑有问题，不得已只能调试，第一轮基本都不会将断点打在if里面，最后才发现不能使用==号判断字符串。
•   几件可能让老板比较着急的事情：

             

• • 项目关键时期，我电脑固态硬盘坏了。这事也真巧，当时买的质量上乘的INTEL固态硬盘在我手上居然真坏了，也就意味着短时间内无法工作，老板非常热心的想开车送我去电脑城，我当然不敢了，老板的时间比我宝贵多了，最后灰溜溜的跑了一下午先将系统安装在机械硬盘上，然后又是好一阵的各类软件安装，令人头疼的JAVA各种环境配置，终于跑起来了，浪费了整个大半天。颇有一种此人关键时刻容易出状态的情景，但此事我只能认载，只能祈祷我后续更换的不会出同样的问题。
  • eclipse运行spring mvc项目起不来。之前是正常的，突然有一天，debug时网站怎么也运行不起来，日志停留在初始化Spring MVC的信息中，具体的提示语这里就不贴了，最后就是报超时错误。刚开始我以为是家里VPN网络问题，第二天到了公司还是一样，赶巧的是正好线上有个问题需要解决，而我本地又无法正常调试，当时我能感觉到老板有多失望，估计心里在打鼓：怎么招了一个连eclipse配置都搞不定的人呢，耽误事呀。当时呢没有好的办法，尝试使用史上最智能的JAVA开发工具IDEA，配置后发现居然能正常调试，心里窃喜，于时先用IDEA解决了线上问题。但总要搞明白为什么这个eclipse不行呢，于时将日志的级别降低到DEBUG，此时出现了不少信息，比较有用的是在调试时一直有信息在输出，于是先将eclipse超时时间设置长一些，它默认是20S，我设置成60S，还是相同的超时问题，最后尝试几次设置到800S，系统神迹般的起来了，当时的兴奋劲不亚于当时玩足彩任9时中奖的喜悦之情。这个情况告诉我应该是某个环境消耗的时间过长导致的，于时想到我们的日志用到了logstash,它是需要连接redis的，于时将日志中的logstash关闭掉，网站再debug，飞一样的跑起来了。可能时当时我们本地连接redis有异常，导致消耗非常多的时间。但为什么相同的网络环境下idea能运行而eclipse不行，我未做深入研究，推测可能是idea做了某些优化。此事虽然并非真正是由于我不懂eclipse配置的原因，但经过这件事情也让我明白一个道理：不是程序员无能，是eclipse太恶心。这也是我们团队90%的人都改使用IDEA的原因之一。
  • 不熟悉kibana被批。之前有说过我们日志是通过logstash采集的，那么日志上哪看呢，就是这个kibana。当天项目上线后，有个系统功能显示不正常，于时排查，测试环境是正常的，看代码也没有看出逻辑问题，  我的直觉应该不是代码问题，随口说了句不专业的话：代码应该没有问题，要不重新部署下试试？顿时被批不专业，推荐我查查日志，由于当时我对这个kibana不熟悉，又说了句招人骂的话：还不太熟悉，不知道怎么查。顿时领导怒了，估计在想：你这样的老兵还需要我来教如此基本的东西，太不值了吧。于时亲自让SA在服务器上查看日志，并发现了一个重要线索，我根据此线索得以将问题解决。此后我火速找人补习了下如何使用kibana查询日志。

• •  一个系统登录权限认证问题，一个月内不止三次反应问题。根据项目需要我们决定采用shiro+redis来替换spring自带的认证授权模块，测试环境功能都正常，到了线了偶尔有用户反馈权限的判断不正常，明明是有权限的但提示没有权限，而这类情况是不定期发生，有时发生了刷新下页面又恢复正常。由于我从来未遇到过，所以比较难以下手分析。后来通过打印log，以及各种亡羊补牢的方式来试图解决，都以不理想告终。有一阵手上正有一个重要项目在做，临近收尾阶段，我特意请示了领导需要重点解决下登录认证问题，因为此事让我压力特别大，在别人眼中看来这应该是个很简单的功能，怎么到我这就这么多问题，质量太没有保障了，重要是我并不是新兵，而是一个混了10年的老油条，且不是应该是个多么大的NB人物至少也应该是独挡一面的。后来经过调试发现，我们每一次请求，都会操作很多次redis的读和写，这让我很不理解，虽然操作redis性能不是大问题，但一次请求多达几十次的写操作总觉得不太正确。于时尝试放弃远程缓存，改用ehcache的内存缓存，上线后什么事情都没有了，仿佛世界一下子清静了。原因可能是因为我们使用了腾讯云提供的redis，这类产品往往与原生太的有区别。至于腾讯云的redis为什么会有上面的现象，我由于时间问题未做后续追踪，因为我本来就认为权限不适合启用远程缓存，使用本地缓存更可靠。到此，困扰我一个月的问题终于有了结果，心里也踏实了许多，最近一个多月再也没有听到类似的问题反馈了，也因此让我对第三方产品有了更深层次的认识。
•   真的可以变成JAVA专家吗？

        

• • 开发工具,现在团队大部分人都用idea，我还是坚持使用eclipse，因为我想再多熟悉熟悉eclipse。eclipse有很多小问题，让人有时感觉比较头疼，往往需要通过不停的project clean这个一招鲜方法来解决，.net的VS重来不会出现如此低端的问题。
  • 语言，JAVA由于与.net比较相似，转过来比PHP容易一些，但也有很多小问题，在上面已经介绍了一部分。
  • 数据存储，我们比之前的mysql多了mongodb,redis，这些基本的语法也是需要简单学习的。
  • 日志，logstash这套方案也是需要学的。
  • 部署运维，传说中的docker，linux nginx,jenkins等，自从有了jekins这类高端工具后，我再也不用记那些命令了，只需要潇洒的登录网页，愉快的点击部署就好了。
  • 分布式服务，这里我们采用了淘宝的dubbo,简单使用并不难，但要想用好还是需要时间的。比如我们发现dubbo自身有3次重试机制，就不需要在程序中手工去做这件事情了，dubbo自身具备请求日志功能等。
  • 检索系统，我们采用了elasticsearch，用于商品数据的搜索等。
  • 统一配置，我们基于zookeeper自主开发了统一配置中心，用来解决各类项目中的配置集中管理问题。
  • sping相关，做网页要学spring mvc，做切面要懂AOP，做交互要会angularjs

         

        

•  公司虽小，但我们的项目的确是一线公司的标准做法，技术团队虽然只有几十人，但做法基本都是按标准互联网模式来做的，虽然规模上是麻雀，但依然能够翱翔于蓝天。

        

• • 严格按模块划分的服务，业界专业叫法是微服务。
  • 分布式服务，dubbo。
  • 基于zookeeper的统一配置中心。
  • 分布式日志，logstash+redis。
  • 检索系统，elasticsearch。
  • 多种数据存储,mysql,redis,mongodb。
  • 信息队列，rabbitmq。
  • 分布式事件总线，我们基于spring以及rebbitmq开发了一套具备持久化功能的分布式事件总线。

        这里只列表了我熟悉的，不包括手机端以及JS前端的内容。从技术上来讲，足以做了一套支持高并发高性能高可用性的电商系统。

•  以往的.net经验有用吗？我的理由是有些技术是相通的，大体原理相同，只不过实现方式不同而已。就像同是WEB站点，无论是JAVA还是.net都是handle以及module，设计模式，算法的理念都是相同的。甚至可以说有丰富的.net经验能够更好的设计出优秀的JAVA系统。
•  我们的老板真心不错，搬新办工楼时，原来的灯光有点暗随后更换了非常敞亮的灯，椅子也是为程序员考虑的，可减少颈椎病；北京第一次发雾霾预警时，老板让我们第二天在家办工；12月25西方人的节日，老板除了微信红包外，因有人说没有抢到老板的微信红包，于时对所有发再发大招红包，红包的内容是第二天不上班；当我报了软考的班，只能晚上回来临时解决任务时，老板很支持并且当月并未扣工资；老板平时会在冰箱放一些小吃，大家工位附近会放各种零食；2015年最后一天，我们下午就放假休息了；还是很人性化的弹性工作，平时晚来一会，早走一会，下午学个车什么的，只要不影响工作老板都会批准。还有好多，不列举了，总之这是我工作10年来遇到的对员工最好的老板了。
•  我身边有一群狼十足的战友。无论是工作能力还是人品都是没得说，在一群狼合作，还是很有意思的。

        

 回顾这半年，再看看哪些是做的不错的哪些是需要改进的：

     

1. 优点
   1. 这半年，基本都能按要求保质保量的完成任务。
   2. 工作情绪进一步得到控制，我是一个性情中人，有时工作中会带着自己的情绪，上半年在公司有同事投诉我态度强硬。下半年在新的团队中很少与同事就工作红脸，争吵或者让其它同事比较不爽的事情了。
2. 缺点
   1. 技术上还应该多花点心思，目前在技术上的贡献来讲还有所欠缺。
   2. 技术前瞻性上还不够，比较局限于当前的情况，需要多多对比业界的其它解决方案，这样才有可能做出一些有突破性的事情来。
   3. 辛苦准备的项目管理师软考失败了，没对的起老板给的假，比较惭愧，今年继续，貌似这个考试好多人都需要考试三次才能通过。

    2015已经过去，为了30+的程序员不被淘汰，总要有些想法呀，这里也列几条吧：    

     

1. 抽点时间再深入学习学习angularjs,之前公司项目使用knockoutjs，我就没有花时间学，两者中还是至少要懂一门的，要不然以后做项目容易被淘汰。
2. 搞一搞项目开发规范，让所有开发类似系统的人都有一个模板可做参考，否则会出现各种聪明的实现方式，难以管理。有时候看似不灵活的方式效果会更好，因为有约束就会有标准。谁要抱怨标准不好，可以讨论修改，谁要抱怨看不懂别人写的代码，那就是因为没有形成标准。
3. 在新的业务中能够起到负责人的作用，或者独立负责某个系统。
4. 程序员除了写代码还应该看看理财的书，尽管看了可能比不看赔钱更多。

    

  下半年是忙碌的，虽然有压力但很充实；有自己才疏学浅的窘境，也有解决问题之后的惊喜；有人说要想成长就需要跟比自己强的人工作，那么显然我下半年的选择是对的。2016年我要为了成为别人心目中的强人而努力。