最近在面试工作中，遇到了一些和我一样在业务线摸爬滚打多年的程序员，很遗憾他们没有达到公司的标准通过初试。由于看到的不是个例，就想着总结一篇文章出来，写给和我一样“奋战”在业务线上的程序员(开发人员），一起鞭策一起进步。
一、如果你是业务线的程序员
1、业务线程序员的工作内容和挑战
【图1】
我觉得概括一句话：“把甲方的业务需求用代码变为现实”。之所以用“甲方”而没有用“产品经理”这个词，是因为需求的提出者并不一定像互联网公司一样是产品经理，在传统软件行业可能是项目经理甚至客户，还有可能就是老板。
抛开可能面对的高并发带来的技术高可用、分布式一致性等等技术难点，有时候我们业务线的程序员(开发人员）自己也承认，工作的挑战往往是来自于“容易变化的需求和不容易的适应变化的代码之间的矛盾”。需求的变化，表现为不确定的持续变化的需求，来源于外界环境的变化和甲方的决策。代码的适应性，表现为已有的代码在面对变化后的需求时实现的难易程度。
2、面对现实
曾经有过的把老板的口头需求转化为产品文档的经历让我意识到：作为一名开发人员，不要幻想能遇到把所有产品逻辑一次想清楚的产品经理（甲方），因为我自己都做不到这点。与其不停的抱怨多变的需求，不如让自己专注于解决问题并拥抱变化，不要去做那个团队中让人讨厌的“事后诸葛亮”。
二、不要成为这样的业务线程序员
面试业务线的程序员，我一般会问至少如下三类问题。
首先让面试者把他做过的一个需求先简单讲一下。候选人如果不能够描述清楚自己实现的需求，表明基本的沟通能力还是需要加强的，业务线上的程序员不止和机器打交道，能把自己掌握的信息清楚准确的传递给他人很重要。
然后会再问一下这个需求的具体实现，目的是考验系统分析设计的能力。如果一个工作超过3年的程序员，依然不能借助uml之类的工具清晰的把需求涉及的模块和领域模型表述出来，那么就不要轻易的给自己的简历写上“有多年系统分析的经验”。面对需求进行系统分析的结果，如果是直接设计的表结构，这样的设计很难面对未来的需求变化，因为抽象的高度不够太容易“只见树木不见森林”。高级的产品经理都能用uml清晰的表达自己的产品逻辑，更何况我们程序员了。
最后一个问题是关于面向对象的思想的，比如oo的原则，设计模式之类的。让我不能接受的是，有的候选人不了解设计模式居然就敢大言不惭的说“我觉得设计模式在业务开发的工作中没什么用”之类的话。面向对象思想，设计模式，领域建模等等，都是一些业内的大牛为了解决业务开发中的问题而总结分享出来的，业务线的程序员更应该比系统开发线的程序员掌握的好。
三、业务线程序员的成长
1、真正做好日常的业务开发工作
（1）完善基本功
如果你学过，如果你也认为“设计模式在业务开发的工作中没什么用”，那么就在学一遍，同时想一想过去的工作中有没有能够重新设计优化的地方。
【图2 关于面向对象的学习路线】
学习掌握oo三大特性、oo六大原则、二十一个设计模式后，再了解一些领域驱动设计的思想，那么不管到了任何公司任何业务场景，我相信你都会很快上手。
（2）锻炼沟通能力
不是滔滔不绝口若悬河才是好的沟通能力，对于程序员来说，能把产品经理（甲方）的需求理解到位，能把自己的技术方案讲给小伙伴听并确保他们理解的没有大偏差就足够了。关于正确理解需求，我的做法是先认真的听并提问，等觉得自己消化以后就拉上产品经理给她讲，进行验证。
2、学习一种建模语言
比如uml，学习掌握后，和产品经理和技术小伙伴，不管是沟通需求还是讲解设计方案，都会效率高很多，大家不都说“一图胜千言”吗。
3、像系统开发的程序员那样持续学习
（1）拓宽写自己的视野
了解些业内出现和发展的技术，没准什么时候你就用上了，即使用不上但了解一下没坏处。比如微服务、大数据、AI、区块链等等，一些大妈都能谈的头头是道，我们作为个技术人了解一下真的不为过，千万不要像有个候选人说出来“微服务？微信的服务”这样的话。
如果你认为自己的好奇心足够而且自我驱动的能力也很强，可以忽略后面这段。如果自我驱动的能力弱些，我建议你通过考个“系统分析师”或者“系统架构师”的证书，来督促自己学习，这个证书不但有现实的意义（比如落户等），而且学习的过程会让你收获并养成一些习惯。
（2）了解些实现细节
这个感悟，来自于自己看了《Redis设计与实现》这本书。我在前东家工作的时候，有个“病历同步”的功能遇到了好多问题，如果当时能了解redis中多机数据库的实现细节，肯定会走不少弯路。
最后，总结一下，如果你和我一样，是业务线的程序员，千万不能只满足于完成眼前的工作，要拥抱变化面对未来。
参考：
混IT，必须理解“甲方乙方”