若是你是业务线的程序员

    最近在面试工做中，遇到了一些和我同样在业务线摸爬滚打多年的程序员，很遗憾他们没有达到公司的标准经过初试。因为看到的不是个例，就想着总结一篇文章出来，写给和我同样“奋战”在业务线上的程序员(开发人员），一块儿鞭策一块儿进步。

    1、若是你是业务线的程序员

    一、业务线程序员的工做内容和挑战

 

 

    【图1】

    我以为归纳一句话：“把甲方的业务需求用代码变为现实”。之因此用“甲方”而没有用“产品经理”这个词，是由于需求的提出者并不必定像互联网公司同样是产品经理，在传统软件行业多是项目经理甚至客户，还有可能就是老板。

    抛开可能面对的高并发带来的技术高可用、分布式一致性等等技术难点，有时候咱们业务线的程序员(开发人员）本身也认可，工做的挑战每每是来自于“容易变化的需求和不容易的适应变化的代码之间的矛盾”。需求的变化，表现为不肯定的持续变化的需求，来源于外界环境的变化和甲方的决策。代码的适应性，表现为已有的代码在面对变化后的需求时实现的难易程度。

    二、面对现实

        曾经有过的把老板的口头需求转化为产品文档的经历让我意识到：做为一名开发人员，不要幻想能遇到把全部产品逻辑一次想清楚的产品经理（甲方），由于我本身都作不到这点。与其不停的抱怨多变的需求，不如让本身专一于解决问题并拥抱变化，不要去作那个团队中让人讨厌的“过后诸葛亮”。
　　若是碰见“让你作根据主题根据手机壳变化”的那样的产品经理，解决的问题办法不少种，揍这种智商低下的把本身拉下水，有点不值。不过，哪里有压迫哪里就会有反抗是真的。

    2、不要成为这样的业务线程序员

    面试业务线的程序员，我通常会问至少以下三类问题。

    首先让面试者把他作过的一个需求先简单讲一下。候选人若是不可以描述清楚本身实现的需求，代表基本的沟通能力仍是须要增强的，业务线上的程序员不止和机器打交道，能把本身掌握的信息清楚准确的传递给他人很重要。

    而后会再问一下这个需求的具体实现，目的是考验系统分析设计的能力。若是一个工做超过3年的程序员，依然不能借助uml之类的工具清晰的把需求涉及的模块和领域模型表述出来，那么就不要轻易的给本身的简历写上“有多年系统分析的经验”。面对需求进行系统分析的结果，若是是直接设计的表结构，这样的设计很难面对将来的需求变化，由于抽象的高度不够太容易“只见树木不见森林”。高级的产品经理都能用uml清晰的表达本身的产品逻辑，更况且咱们程序员了。

    最后一个问题是关于面向对象的思想的，好比oo的原则，设计模式之类的。让我不能接受的是，有的候选人不了解设计模式竟然就敢大言不惭的说“我以为设计模式在业务开发的工做中没什么用”之类的话。面向对象思想，设计模式，领域建模等等，都是一些业内的大牛为了解决业务开发中的问题而总结分享出来的，业务线的程序员更应该比系统开发线的程序员掌握的好。

    3、业务线程序员的成长

    一、真正作好平常的业务开发工做

    （1）完善基本功

    若是你学过，若是你也认为“设计模式在业务开发的工做中没什么用”，那么就在学一遍，同时想想过去的工做中有没有可以从新设计优化的地方。

 

 

    【图2 关于面向对象的学习路线】

    学习掌握oo三大特性、oo六大原则、二十一个设计模式后，再了解一些领域驱动设计的思想，那么无论到了任何公司任何业务场景，我相信你都会很快上手。

    （2）锻炼沟通能力

    不是口若悬河滔滔不绝才是好的沟通能力，对于程序员来讲，能把产品经理（甲方）的需求理解到位，能把本身的技术方案讲给小伙伴听并确保他们理解的没有大误差就足够了。关于正确理解需求，个人作法是先认真的听并提问，等以为本身消化之后就拉上产品经理给她讲，进行验证。

    二、学习一种建模语言

    好比uml，学习掌握后，和产品经理和技术小伙伴，不论是沟通需求仍是讲解设计方案，都会效率高不少，你们不都说“一图胜千言”吗。

    三、像系统开发的程序员那样持续学习

    （1）拓宽写本身的视野

    了解些业内出现和发展的技术，没准何时你就用上了，即便用不上但了解一下没坏处。好比微服务、大数据、AI、区块链等等，一些大妈都能谈的头头是道，咱们做为个技术人了解一下真的不为过，千万不要像有个候选人说出来“微服务？微信的服务”这样的话。有些问题不必定是要问你掌握多深，而是要看你做为一名程序员还有没有保持好奇心，保持对技术的敏感度，而不是守着老本一吃到底。

    若是你认为本身的好奇心足够并且自我驱动的能力也很强，能够忽略后面这段。若是自我驱动的能力弱些，我建议你经过考个“系统分析师”或者“系统架构师”的证书，来督促本身学习，这个证书不但有现实的意义（好比落户等），并且学习的过程会让你收获并养成一些习惯。 

  （2）了解些实现细节

    这个感悟，来自于本身看了《Redis设计与实现》这本书。我在前东家工做的时候，有个“病历同步”的功能遇到了好多问题，若是当时能了解redis中多机数据库的实现细节，确定会走很多弯路。

    最后，总结一下，若是你和我同样，是业务线的程序员，千万不能只知足于完成眼前的工做，要拥抱变化面对将来。

 

参考：

混IT，必须理解“甲方乙方”