《学霸的较量》八足

4、4.大神的脾气

　　小江的建议得到了谢联航的认可和采纳，第二天打算继续嘚瑟嘚瑟，尾巴刚翘起来，就被冻得缩了回去。

　　谢联航来了几天，虽算不上笑容晏晏热情待人，脸上一直没什么表情，但也算不上冷淡，没什么架子，比想象中好相处，做事一丝不苟，只要对工作有事说事，他还是容易沟通的，当然，一句多余的话也是没有的。

　　但是今天，技术一部的人都感觉整个办公区域气压特别低，每个人都收到一份邮件，是谢联航针对每个人工作的指导意见。内容直白得让所有人哑口无言，每个人工作中会出现的问题和工作方式的不当之处都被无情地点了出来，什么委婉的职场术语一点都没加，就是特别直接地列出123几点，逻辑清楚地说明哪里做的不好，哪里总是出错，要求怎么改。

　　一开始这群随便拉一个出去都是大牛的技术男们都很是不服气，但是互相看看其他人收到的邮件，不禁乐了：
　　“嘿，你丫就是这样，老是脱离构架设计，每次都得老子给你善后！”
　　“你TM才是，几种参数老是搞不清，英文26个字母认得不？老大说你一点都没错！”
　　“老大才来几天就看出来你小子的问题不在编译器上，编译器总算是沉冤得雪了！”
　　“我早就想说你对版本管理太混乱了，别说我们搞不清，你自己到后面也都分不清了吧？”
　　“你看不懂了吧，我帮你翻一下老大的意思，你的思路太钻牛角尖了，老想在你擅长的编程语言上做到极致，卡住了吧？换个方向马上就容易解决了。”
　　……

　　互相揭发完同伴们的缺点，然后自己冷静下来，再仔细看一遍谢联航的邮件，大都都服气地闭了嘴，除了一个人。

　　给小江的邮件是最详细的(见作者有话)，而且是最不客气的，让咱们来概括一下：

　　不爱写注释和文档，这都已经是老生常谈了——写你MB，三部的人不会自己看吗？老子又不是文案策划。
　　不想做测试？就要求你以后在编程之前就先写测试——我就是不爱做测试，怎么滴！
　　代码结构、功能算法过于臃肿，必须精简——前两天不是说让我完善吗？我写得全了又嫌我胖了？
　　即使客户是SB，你也得按他的需求和产品设计做——我给他写个SB自爆的功能，要不？
　　要和其他同事好好沟通、协作，你就是太独了——沟通？我说的他们听得懂吗！协作？其他人跟得上我吗！
　　命名可是门艺术，这我也不擅长，咱得准备一本词典——老子就是取名废！生个孩子取名字都没这么费劲的！
　　哈哈最后一条是拼写错误，小江同学请准备好词典并养成检查作业的好习惯——滚你妈个蛋！！！

　　当然，谢联航的邮件可没这么生动，语言刻板得让小江越看越火大，字里行间的严谨让他有些反驳无力。前面是同事们一边调侃一边概括的，后面就是小江死爱面子一句句给顶了回去。他觉得谢联航就是故意针对他，昨天差点就上当了。

　　“有本事你上老大桌前理论去。”小胖怂恿着。

　　“去就去！”

　　谢联航的办公室不像其他部门主管那样随时关着门进入需敲门得到允许，所以小江刚转身离开工作位，就能远远看到敞着门的主管办公室里坐在办公桌后的谢联航。

　　刚才同事们都在讨论，谢联航今天是不是心情不好，一早就群发了批、斗邮件，小江越走近越觉得大家分析得对，今天谢联航的气场的确不大寻常。

　　在会议上被小江公开呛声都淡然处之的谢联航，这时候和往常一样专注地伏案工作，但是双眉紧促，脸色……有点黑。平时的谢联航就像个机器人，冰冷、严谨，完全看不出喜怒和其他情绪，但是今天他的脸上就明晃晃地挂着大写的两个字：不、爽。

　　这倒让小江有点好奇了，本来理直气壮的脚步慢了下来，昨天谢联航刚把大家在新方案上像光荣榜一样点名挂了一遍，今天怎么就不高兴了？难道真是因为我们组工作太随性散漫了？还是想上任三把火？这什么脾气，原来木头一样的气质都是装出来的吗？还没琢磨出什么来，不知不觉已经走到谢联航的办公桌前了，本来也就十米不到的距离。

　　谢联航感觉眼前突然出现一片阴影，抬起头见是小江，眯了眯眼问：“什么事？”

　　“呃……”小江看谢联航的脸色不仅黑，而且脸部线条和嘴角都绷得可紧，不自觉的自己的神经也跟着绷紧了，而且在他看到自己的一瞬，眼里闪过一抹阴郁，让小江认定谢联航就是在针对自己，莫名有些心虚，话都堵在喉咙里，说不出来。

　　谢联航等了一分钟见他也没说出什么，眉头拧得更紧了，开口丢下一句话：“一点去销售市场部提案。”而后径自低下头继续工作，不再搭理小江。

　　站在办公桌前的小江一脸的尴尬，明明是来质问的，可是对方气场太强大，而且一副“别惹我”又公事公办的模样，硬是让他一句话也问不出了。

　　“不应将个人的感情因素带到工作中”到底是谁写在邮件里的！？摔！就因为自己是他前任的师弟，就因为他刚来的时候我给他脸色看了？——小江重新将原因归结在两个人的私人恩怨上，才不承认是自己的工作问题。

　　下午的提案很顺利，销售市场部和产品设计部门对技术部新提出来的技术提案很满意，不顺利的是小江。

　　谢联航带了两个人去，一个人负责阐述后台清算系统的新技术点，提出引入移动支付，如支付宝和微信等第三方合作服务，还提出一个公共交通移动app的想法，不仅是地铁，还将整合公交和出租车，将公共交通的实时信息、路线路况查询、充值、支付等全都整合在一个系统里，对大数据统计也很有帮助。这点让产品部门很兴奋，但是需要重新估算项目周期和预算。

　　另一个人就是小江，谢联航让他阐述关于前台系统的改进时，小江一脸懵逼，他以为谢联航带他来只是为了充场面或是为了让他见识谢联航作为领导的能力的，完全不相信午饭时同事们开玩笑说谢联航要重用他的玩笑，这哪是重用，尼玛完全是故意让他当众出丑来的！

　　在场七八个人都等着他，小江急得在空调会议室里直冒汗，狠狠地瞪着谢联航，对方也沉着脸看着他，其他人一看就知道两人似是有仇，只得呆坐在位置上不好言语，就看两人四目之间闪着火花。

　　怎么！看不起老子么！？

　　“呃……那个……什么……”小江张张嘴，脑袋里一片空白。

　　“先从你的提议开始吧。”谢联航垂眸收回目光，大方地给指了一条路，小江见他错开了目光，也松了口气，转头看向Andy他们，紧张的感觉压下一半，说到底还是最怕在谢联航面前丢脸，其他人给他的压力其实还好。

　　“哦对！我的提议……就是……多从人性化角度考虑，简化操作流程，改善人机交互。比如针对残……残疾人士，增设几台降低操作台和屏幕高度的售票机，这个适用于轮椅使用者和侏儒症患者，也适用于中小学生使用；在售票机增……还有检票机增加语音操作提示和说明、在检票机增加语音提醒，适用于盲人和对操作不熟练的生手，还可以加入简单的语音操作互动；……”

　　“还有就是……刚才说过的移动支付和售检票机的结合应用，甚至可以直接脱离售检票机，移动设备直接购票，从专有通道检票入站，网络化电子票可以逐渐替代磁卡车票，除了环保，减轻票卡调配的问题，几乎可以解决磁卡介质的其他所有缺点……移动端还可以有即时的换乘提醒，提供跟踪导航的无缝换乘服务……这样终端会越来越多元化，就需要系统高度集成化，互相兼容、联、联程优惠、还有……跨系统结算都需要改进……”

　　“我的意见主要就是这些，虽然这些从技术上来说，增加这些功能并不难，也算不上什么技术特点，但是却很实用，能帮助更多的人……我就是这么想的，其他……”

　　小江磕磕绊绊说完自己的意见，这些都是根据自己对上海公共交通的见闻和体验想了一夜的想法，之后就掰不出别的了，其他同事的建议虽然一同列在邮件中，但是他没仔细看，小江在桌子地下掐了自己大腿一把，干嘛就不多看两眼呢！

　　有些不甘心地转头看了看谢联航，对方没有看他，而是对着另外两个部门的同事，直接在小江发言的基础上重新整理逻辑，条理清楚地开始补充说明其他前端系统的改进。随后，在做的同事就技术上的难点和实现，向技术部提问，谢联航都游刃有余地耐心一一解答，给出明确回应。

　　谢联航最后还对系统安全方面，给出了自己独到的见解，小江听了讶异地挑起了眉，有些地方的思路竟和[好好学习]大神以前在论坛上发表的一篇《公用设施系统安全浅谈》特别相像，当时大神只是提出一个理念，大家并没有讨论到落地应用，而现在谢联航的见解却比大神的理论更加完善更贴合实际应用。

　　真有两把刷子？还是也混过论坛？不得不说，小江对谢联航的逻辑思维能力确实佩服，不管这些思路是不是他自己的，能这样整合大家的想法，而后条理清晰地阐述重点，应该也是费了不少功夫做功课。不像他，明明在写方案的时候思路挺清楚的，分123几点列下来，头一回碰到在正式场合需要他当众发言的情况，脑子里抓到哪个关键词就说哪个，最后说到哪自己都乱了。

　　所幸另外两个部门的同事对他的发言似乎也挺看重，散会后，Andy还特地过来拍着他的肩说：“小江，以前你跟着你师兄，就知道你嘴贫，没想到你这脑瓜还挺活络，以后还有什么有意思的想法尽管跟Sheldon说。”

　　难道自己以前给别人的印象其实是脑袋空空就剩下嘴巴厉害了？老子明明是实力派好不好！

---

作者有话要说：　　小江对地铁的改进建议是我根据自己的乘车经验想了一夜想出来的，也许有些已经实现，有些还待改进。
－－－－－－－－－－
谢联航写给小江的工作改进邮件，搜了好多关于程序员工作方式的问题，整理出一些符合小江性格、他容易犯的问题，因为是从网上的资料总结的，就不放在正文里凑字数了，整理如下：
－－－－－
1.创建用于解释代码和应用程序的文档，包括独立文档和代码注释。目标人群范围从终端用户乃至其他后续开发人员。
2.编写单元测试，以确保每一部分代码都能正常运作。这些测试不但有助于在开发早期找出bug，还能方便后续的回归测试。根据开发方法论，建议在写代码之前先写好测试程序。
3.根据系列要求，设计可实施方案，包括设计数据和代码结构、功能算法和应用程序流程。确保你设计的解决方案得满足客户的要求，并且按时完成。
4.摒弃个人想法和意见，竭尽全力地实现或支持功能需求。不管什么原因，如果客户或者产品部门同事坚持某个特性和功能，不应将个人的感情因素带到工作中。
5.收集客户需求，提供状态管理报告，配合测试人员，和其他工程师协作。耐心向非技术人士解释技术问题，必要时应无条件接受其他同事交接过来的任务，与QA或其他开发人员出现意见相左情况应理性处理。
6.为变量、过程、函数、类、对象、数据库组件等命名，提高代码可读性，要求一贯、简洁、有内涵，能明确表现功能和用意。
7.杜绝拼写错误和其他低级错误，必要时请做检查。
程序员从菜鸟到大神，分很多等级，小江这时候应该就是老油条吧，技术啥的没大问题但时不时碰到瓶颈，其他就是工作态度问题。