或许成为技术大神只能算是程序员最简单任务

  目前在新公司已经入职一个多礼拜了,跟之前新加入任何一家新公司一样,有着许多的东西需要去了解和熟悉,而这一过程再次让自己直面了之前所没有正视的问题——其实感觉自己真的比较LOW!
  移卡科技在移动支付业务中算是做的比较成功的企业,而且现在正在围绕支付业务为中心,大力拓展互联网金融、O2O业务,可谓发展形势是一片红火。自己在研运部参与和银行各支付渠道的结算相关业务,和通常的互联网公司业务不一样的是,支付业务并发量、数据流量其实很小,但是对安全性、完整性要求极高,所以业务开发中充斥着加密解密、通信专线、账目校对等东西,数据库也基本都是事务形式提交回滚,大多是幂等性操作(比如INSERT…ON DUPLICATE KEY UPDATE…),对自己来说算是面向一种全新开发风格了。
  说句实话,这部分服务端代码给我,俩小时的时间就看完基本怎么实现的了,一方面经过这一年多时间的打磨,相信自己是看透了后台服务端开发的那么些伎俩和手段了;二来这部分的业务本来就比较简单,主要就是负责和银行对接实现报盘、回盘方面的处理;三来估计这部分代码也出自普通凡人程序员之手笔,实现的比较Plain直白,没有使用什么高级晦涩的技巧和模式。然后接下来几天的工作重心就是熟悉业务知识,但过程中被各种脚本、各种库、各个表折腾的来来去去的,还有些晕头转向的感觉,但是总感觉自己熟悉业务的速度比较慢,所以今天就直面一下程序员的这个问题吧。
  其实感觉这个问题吧,估计不少数程序员对业务熟悉过程也比较慢,而且即使某个行业耕耘打拼了很久的老员工,相当一部分人对业务的整体还是缺乏全面、清晰的了解。我爱人就是做软件测试的,经常跟我抱怨说和研发同事交流的时候感觉很困难,很多时候对于整个业务的整体流程和细节,研发的还不如她一个测试了解的清晰完整,出现问题常常还需要测试部的同时帮助定位跟踪问题。虽然大家明里不说,在中国测试部的地位、技术总会被认为比研发部低三等,但这里看似就出现了研发部和测试部业务水平的倒挂,当然出现这种现象有时候跟客观环境不无关系:
  (1). 程序员往往只负责整个项目中的某个小块,经常也只需要关注业务的上下流接口,而且因为这样或者那样的原因,其他模块部分对其是保密的,所以大部分的程序员常常被动处于管中窥豹的状态,相反测试需要将整个流程走起来,所以可以接触到产品的整体,两者视野的不一样很可能造就上面的问题。
  (2). 开发人员和测试人员的性格还是有差异的,至少测试人员总会跟各个开发者询问、确认各种东西,而大多数程序员都是埋头做自己的事情。不过当今测试部和研发部的男女比例严重失调,这也难说到底是男女性格差异造成的,大家公认的是:女性是乐于交流的动物,男性是乐于实干的动物。
  (3). 现在很多程序员在一定历史或者规模的企业,都扮演者螺丝钉的角色,甚至很多人终其职业生涯都是干着DEBUG、缝缝补补、添加模块feature的工作,这样即使对整体业务和构架不清晰,在一定程度也仍然胜任当前的工作,一般来说公司规模越大、业务相对越传统的话,这种现象便更为的普遍。此时如果程序员不再进取、好学一些,就真的沦为打杂的码农了。
  (4). 还有大多中小型公司都缺少完善的知识库构建,给程序员完善的文档可能很快就熟悉了,但是要靠凭借老员工和新员工口口相传,除非:老员工表达能力清晰+老员工性格好有耐性+新员工虚心请教,这些条件满足的情况下才能得到比较好的效果,但是纵观程序员普遍表达能力较差、心里还有那种不知道哪里来的傲娇,所以如果公司没有完善的设计文档、wiki等知识库的建立和共享,这就是个比较严重的问题了,要知道很多程序员你让他们写注释都恼火,能主动习惯性输出文档估计更是难上加难了。
  正因为程序员有这样的业务熟悉代价,而且通常大多都做的不太好,所以在程序员快速熟悉业务能力比较难以考察情况下,公司就偏向于爱招收具有相关行业背景的人了,从一些招聘的JD上可以看出熟悉相关业务背景很可能是面试结果较大的加分项。
  说来,最近架构师的概念十分的红火,无论是大家的技术博客、各大讲座论坛上、各个招聘网站的职位列表中,这个职能的字眼总是数见不鲜。虽然架构师是很多软件工程师的终极成长目标,但最终必定只有少部分才能达到这个金字塔顶,因为狭义的架构师可能被认为是技术大拿,熟悉各项组件和框架,项目之处可以决定技术选型,项目过程中可以帮组解决各项难题,总是是一种神一般的角色,但是通常来说合格架构师除了要了解业务特性进行技术、架构选型之外,对业务的把持、项目的推动、资源的调配都是十分重要的工作内容,这点在西乔的《架构师成长之路》系列漫画中已经介绍的很详细了,而后面两者恰恰是大多数程序员的技能短板,所以从招聘岗给架构师的薪水就知道好的架构师千金难求啊。
  记得,曾经有一次面试官问我:“如果给你一个项目,涉及到和其他部门的相互协作,你会怎么开展自己的工作?”说实话这种问题还真不知道怎么回答,于是就支支吾吾的说出项目开始的时候要各部门充分沟通,搞清楚项目设计实现的细节信息,开发过程中各部门也要密切接触,需求设计更改要充分论证,不明白的东西大家要主动探讨,防止项目跑偏乃至无用功这类不痛不痒的话,然后面试官给我的评价是:“你比较适合于分配你的事情,能够很好的把任务份内的职责完成的那种类型。”谁能告知我这种情况正确姿势是怎么做?
  倒是这点,我爱人做的就很好。虽然在技术上能力很差且不好学,因而常常比我鄙视瞧不起,但是在项目主管和项目经理方向却有着很大的发展潜力:对自己负责和接触的项目流程清晰,工作内容和重心明确;在多个项目下能够带领组员平衡和推动项目进度;入职没多久就能打通公司绝大多数部门,在项目遇到各种问题的时候总能够找正确的人合理的沟通解决。还有这次的IHE测试,居然在一两天的时间内和十几家参测厂商沟通后达成合作测试共识,这点真是挺厉害的。这些技能远不是看一两本书可以达到的,而是长时间的性格、习惯以及工作中项目经验的历练共同锤炼而来的,要知道在大多数业务驱动的公司这种沟通技能是十分重要的,也就是工作中的软实力,通俗说来就是IT工作者交流的情商。有时候我就开玩笑问她,两人在一起这么多年了,怎么就没能传染点给我呢?有时候真的有种可望不可即的感觉。
  最近撸了本《软技能 代码之外的生存指南》,并不期望自己能够通过这本书彻底盖头换面,但希望自己能够正视自己的问题,IT工作中的软实力能够慢慢得到改善和提升,早日做一个合格的码农吧!有什么新的心得体会,也会积极和大家分享的。

本文完!