后端程序员都做些什么？

笨死的猪

刚开始做Web开发的时候，根本没有前端，后端之说。
原因很简单，那个时候服务器端的代码就是一切：接受浏览器的请求，实现业务逻辑，访问数据库，用JSP生成HTML，然后发送给浏览器。
从事嵌入式开发多年，最近在做后台相关相关的开发，现在很多程序员在学校或者入行之前都会考虑是选择前端开发还后台研发，很多女生或者基础不是很好的学生一般会选择前端开发，现在的前端算是比较火，也是很多培训机构比较喜欢的，目前培训机构喜欢三种编程方向，python，前端，php这三种都属于入门相对比较简单，但市场需求非常巨大，目前市场实际的需求前端相对python更多一些。
即使后来Javascript在浏览器中添加了一些AJAX的效果，那也是锦上添花，绝对不敢造次。因为页面的HTML主要还是用所谓“套模板”的方式生成：美工生成HTML模板，程序员用JSP,Veloctiy,FreeMaker等技术把动态的内容添加上去，仅此而已。

那个时候最流行的图是这个样子：



在最初的J2EE体系中，这个表示层可不仅仅是浏览器中运行的页面，还包括Java写的桌面端，只是Java在桌面端太不争气， 没有发展起来。


每个程序员都是所谓“全栈”工程师，不仅要搞定HTML, JavaScript, CSS，还要实现业务逻辑，编写访问数据库的代码。等到部署的时候，就把所有的代码打成一个WAR包，往Tomcat指定的目录一扔，测试一下没问题，收工回家！

不差钱的公司会把程序部署到Weblogic，Websphere这样的应用服务器中，还会用上高大上的EJB。

虽然看起来生活“简单”又“惬意”，但实际上也需要实现那些多变的、不讲逻辑的业务需求，苦逼的本质并没有改变。
从性质上讲后台开发编程语言的种类比较多，java，python，php，C#等等都可以作为后端开发语言。前端开发主要分成三块，html，css，javascript，前两个相对比较容易学，javascript复杂不少，javascript脚本相对来讲入门容易成为高手比较难。后端开发在平时设计开发过程中需要考虑的问题多一些，而且后端主要注重数据的安全性以及结构的稳定性，前端主要讲求用户体验，两者本质的出发点不太一样，但在实际开发过程中，开发后端的程序员基本上也会懂一些前端页面，毕竟有些很简单的功能界面基本上后端的技术人员直接就操作了，最主要的原因是前端的代码都是在服务器端。

1前后端的分离
随着大家对浏览器页面的视觉和交互要求越来越高，“套模板”的方式渐渐无法满足要求，这个所谓的表示层慢慢地迁移到浏览器当中去了，一大批像Angular, ReactJS之类的框架崛起，前后端分离了！


后端的工程师只负责提供接口和数据，专注于业务逻辑的实现，前端取到数据后在浏览器中展示，各司其职。

像Java这样的语言很适合去实现复杂的业务逻辑，尤其是一些MIS系统，行业软件如税务、电力、烟草、金融，通信等等。  所以剥离表示层，只做后端挺合适的。

但是如果仅仅是实现业务逻辑，那后端也不会需要这么多技术了，搞定SSH/SSM就行了。

2后端技术
互联网，尤其是移动互联网开始兴起以后，海量的用户呼啸而来，一个单机部署的小小War包肯定是撑不住了，必须得做分布式。


原来的单个Tomcat得变成Tomcat的集群，前边弄个Web服务器做请求的负载均衡，不仅如此，还得考虑状态问题，session的一致性。

（老刘注：参见文章《小白科普：分布式和集群》）

业务越来越复杂，我们不得不把某些业务放到一个机器（或集群）上，把另外一部分业务放到另外一个机器（或集群）上，虽然系统的计算能力，处理能力大大增强，但是这些系统之间的通信就变成了头疼的问题，消息队列（MQ)，RPC框架（如Dubbo）应运而生，为了提高通信效率，各种序列化的工具(如Protobuf)也争先空后地问世。

单个数据库也撑不住了，那就做数据库的读写分离，如果还不行，就做分库和分表，把原有的数据库垂直地切一切，或者水平地切一切， 但不管怎么切，都会让应用程序的访问非常麻烦，因为数据要跨库做Join/排序，还需要事务，为了解决这个问题，又有各种各样“数据访问中间件”的工具和产品诞生。

为了最大程度地提高性能，缓存肯定少不了，可以在本机做缓存(如Ehcache)，也可以做分布式缓存(如Redis)，如何搞数据分片，数据迁移，失效转移，这又是一个超级大的主题了。

互联网用户喜欢上传图片和文件，还得搞一个分布式的文件系统（如FastDFS），要求高可用，高可靠。

数据量大了，搜索的需求就自然而然地浮出水面，你得弄一个支持全文索引的搜索引擎(如Elasticsearch ,Solr)出来。

林子大了，什么鸟都有，必须得考虑安全，数据的加密/解密，签名、证书，防止SQL注入，XSS/CSRF等各种攻击。

3“大后端”
前面提到了这么多的系统，还都是分布式的，每次上线，运维的同学说：把这么多系统协调好，把老子都累死了。


得把持续集成做好，能自动化地部署，自动化测试（其实前端也是如此），后来出现了一个革命化的技术docker， 能够让开发、测试、生成环境保持一致，系统原来只是在环境（如Ngnix, JVM,Tomcat,MySQL等）上部署代码，现在把代码和环境一并打包， 运维的工作一下子就简化了。

公司自己购买服务器比较贵，维护也很麻烦，又难于弹性地增长，那就搞点虚拟的服务器吧，硬盘、内存都可以动态扩展（反正是虚拟的）， 访问量大的时候多用点，没啥访问量了就释放一点，按需分配，很方便，这就是云计算的一个场景。

随着时间的推移，各个公司和系统收集的数据越来越多，都堆成一座大山了，难道就放在那里白白地浪费硬盘空间吗？

有人就惊奇地发现，咦，我们利用这些数据搞点事情啊， 比如把数据好好分析一下，预测一下这个用户的购买/阅读/浏览习惯，给他推荐一点东西嘛。

可是这么多数据，用传统的方式计算好几天甚至好几个月才能出个结果，到时候黄花菜都凉了，所以也得利用分布式的技术，想办法把计算分到各个计算机去，然后再把计算结果收回来， 时势造英雄，Hadoop及其生态系统就应运而生了。

之前听说过一个大前端的概念，把移动端和网页端都归结为“前端”，我这里造个词“大后端”


把那些用户直接接触不到的、发生在服务器端的都归结进来。
如何选择前端还是后端选择的最大依据是兴趣爱好，如果喜欢研究一些底层的东西，
想着探究一些问题的本质，如果具备这种性格适合做后台的开发，
后台的研发开始阶段相对来讲入门难点，因为需要掌握一些框架，随着时间的推移越做越有感觉。前端一般入门比较快，因为一个网页效果很快就能展示出来，
前端能做的人很多，能做好的人不多主要javascript这种脚本语言博大精深，想要掌握精通是一件非常难得事情，
很多编程语言都有一种特性，越是入门容易的后面越难成为高手，越是看似入门非常难反而容易做的非常好。
所以如何选择还是根据自己的兴趣走，有了兴趣可能更加容易干的长久，毕竟兴趣是第一老师，现在很多程序员开始对于编程并不感兴趣，有的人做的时间长了慢慢积累成兴趣了，有的人做了很长时间还是咬牙顶着，不感兴趣想办法培养出兴趣来，有了兴趣至于从事前端还是后台都不是多大的事情，做了几年程序之后再想切换到别的岗位也不是多大的事情，编程的套路大同小异。

4怎么学？
现在无论是前端还是后端，技术领域多如牛毛，都严重地细分了，所以我认为真正的全栈工程师根本不存在，因为一个人精力有限，不可能搞定这么多技术领域，太难了。


培训机构所说的“全栈”，我认为就是前后端还在拉拉扯扯，藕断丝连，没有彻底分离的时候的“全栈”工程师。

那么问题来了， 后端这么多东西，我该怎么学？

现在无论是前端还是后端，技术领域多如牛毛，都严重地细分了，真正的全栈工程师根本不存在，因为一个人精力有限，不可能搞定这么多技术领域，太难了。
往深度挖掘，可以成为某个技术领域的专家，如搜索方面的专家、安全方面的专家，分布式文件的专家等等，不管是哪个领域，重点都不是学会使用某个工具和框架， 而是保证你可以自己的知识和技术去搞定这个领域的顶尖问题。

往广度发展，各个技术领域都要了解，对于某种需求，能够选取合适的软件和技术架构来实现它，把需求转化成合适的技术组件，让这些组件以合适的方式连接、部署、运行，这也需要持续地学习和不断的经验积累。

当然也有很多程序员前后端都做的非常好，这样在实现业务逻辑上占据非常大的优势，这样在内部任务划分上也会更加的合理化，如果觉得自己都能做没有必要划分的那么仔细，可以先以一个方向为切入点，然后慢慢渗透进去，特别是编程的入门阶段不要把自己的界限设置的那么清楚，反而限制了自己的发挥。
软件产品团队的角色划分
简单地说，软件开发的工作是编写程序为用户服务。如下图所示，在这个领域，一端是用户，另一端是技术、设备等资源，中间是产品团队负责连接。用户想满足自己的需求，就需要产品团队，把资源加工成可用的软件或者服务，递交给用户，甚至负责运维，满足用户持续的使用。



我们在上图中间画一条分割线，把软件产品团队除了管理人员，一分为二，靠近用户一端的这组角色，包括产品经理、业务分析师、业务运营等职位，作用是确保产品功能体现客户价值，也就是“做正确的事”，这组角色是业务角色；而靠近技术资源一端的这组角色，包括架构师、开发、测试和系统运维人员等，负责高效高质地做出产品，也就是“正确地做事”，这组角色是技术角色。另外，在这两组角色之外，还有一组管理角色，包括项目经理、部门经理等职位，负责业务战略、项目执行、团队管理等。这样一来，我们就把软件产品团队的角色分为三类：业务角色、技术角色、管理角色。
虽然这三类角色的目标都是为用户递交高质量、高价值的产品服务，但各自有明显不同的关注点，他们的思维模式也不一样。为了让你更清楚地了解他们的不同，我举个例子。比如我们让这三类人分别解释一下“圆”这个图形：

• 技术人会说：拿一条绳子，按住一头不动，另一头转一圈，画出的轨迹，就是圆。（他在强调用什么工具技术来画圆。）
  
• 搞业务的人则会说：这个图形就像十五的月亮，每段线条都很光滑，很完美，生活中有很多地方用到它。（ 他在用形象化的语言解释圆的外观、属性，以及应用价值。）
  
• 搞管理的人则会把技术和业务两人叫到一起，对技术人说：“你要用什么样的绳子？这么做费不费劲？”对业务的人说：“你的说法倒是可以验证他画得好不好，可是，十五那天要是阴天你就没法验证了。” （他不关注怎么画圆，但是关注画圆的资源，最终的质量、验证方法，还有风险。）
  

你看到了么，技术角色关注的是设计实现，业务角色关注的是功能价值，而管理角色关注的是质量、过程控制和风险。下面我们一起详细讲讲这三类角色。
1. 技术角色

首先说技术角色，它包括开发、测试、架构、系统运维等职位。这些职位有什么共同点呢？
技术人员的任务，是把定义好的功能做出来。因为长时间跟计算机打交道，而计算机按照算法逻辑运行程序，所以技术人员讲求逻辑，追求细节，探究问题的根源，有追根寻底的好奇心。优秀的技术人员，除了爱钻研深度，还爱探索广度。当对某个领域的技术深入理解之后，他们能抽象出方法和模型，用于掌握日新月异的技术本源，和变化的思想模式，从而在广度上对技术有更快更好的理解。这就是“T”型人才：纵向有技术深度，横向有技术广度，他们对新技术有敏锐的嗅觉，关注、掌握甚至引领技术发展的动态和趋势。
我理解技术角色有以下的四个发展阶段：

• 初级的程序员，拿到小的开发任务，能够运用团队中已经选型的技术和工具，编码实现功能，通过调试代码，理解技术的原理，训练自己的思路以便和计算机的运行逻辑同频，灵活运用编程模式，驽驾程序解决技术问题，也就是形成算法思维，这时他关注的是代码质量和技术问题。
  
• 随着开发任务的多样化，程序员解决的问题越来越深入和复杂，逐渐接触和掌握了完整的框架和技术，通过总结，对该问题域形成模块化、体系化的认知，可以独立设计和开发，也就是形成系统思维。这时他关注的是某一类系统的运行效率。
  
• 解决问题能力越来越强的程序员，把问题域不断拓展到新的领域，利用已经掌握的系统化知识和思考方法，能快速学习新领域的知识，掌握新领域的技术和框架，这是进行“T”型技术中广度的积累。每个技术模块都形成他知识体系中的一个节点，随着这个知识体系越长越大，他可以根据用户的需求，选择合适的技术模块，进行分拆组合，考虑成本和收益的均衡，来提供解决方案，也就是形成架构思维，我们称为架构师。这时架构师的他，关注的是业务和架构的最优匹配。
  
• 再以后，就是对技术前瞻性的把握了，结合市场的需求变化和研究人员的成果，依托整个软件生态的发展，引入或创造新的技术，提高应用效率，满足用户需求。IBM有很多技术大神级的人物，我很希望能有机会跟他们深度协作，这样有了体会，就能补充完善这段了。
  

技术是可以一直做下去的，当然，这点取决于公司的技术成长空间和个人能力素质。如果条件具备，并非像某些人说的那样，35岁以后就要转做管理。和年轻的开发者相比，你资深在对技术本质和广度的理解，以及技术和业务的融合上。
怎么衡量你适不适合走技术路线呢？我觉得，能不能做好技术，不在于你是不是计算机科班出身，不在于你是不是现在还处理琐碎的小任务，而在于你对底层细节的好奇心，以及是否愿意尝鲜钻研，扩充自己的知识体系。
比如，你在饭馆第一次看到“煤球炒饭”，有研究它的欲望么？这道菜上来的时候，还蹿着火苗，你能快速搞清其原理么？你是要自己先研究一番呢，还是去“朋友圈”问别人呢？乘坐电梯，你会不会纳闷电梯用的什么调度算法？你有没有折腾出过一些小程序，被别人“把玩”？你的技术博客，曾经被人称赞或引用过么？如果是，那你可以考虑一下技术路线。
2. 业务角色

业务就是用户遇到的问题和要做的需求。业务角色，包括业务分析师、产品经理、客户支持、业务运维等人员。这些人一方面跟用户打交道，另一方面跟技术人员打交道，把用户不明确的需求、痛点、问题，加工转化为技术人员可理解的、高确定性的需求说明和功能定义。进一步讲，业务角色把用户价值翻译成产品功能，保证产品团队做正确的事。
用户是多种多样的，其原始需求和痛点也是多样的、多变的，很多时候，甚至用户自己也不清楚需求是什么，到底痛在哪里。假如用户想要一种更快的交通工具，但是他没见过汽车，就只能指着满街的马车，说想要一匹更快的马了，然后还说最好不要拉臭臭，因为他的痛点之一是现在街上马粪太多太臭。产品经理如果只理解字面意思，最后的产品也许就是穿着纸尿裤的赤兔马了。
所以，优秀的业务角色能够换位思考，就是有同理心，能站在用户角度考虑问题，也能站在技术人员的角度理解问题。但这并不是说，业务人员是在用户和技术人员中间摇摆，他们要有很强的主导意识，否则在用户指明要赤兔马的情况下，就不会有汽车的诞生了。这正是业务人员关注价值的表现，这也是业务难做的地方。
我觉得业务人员的发展有如下几个阶段：

• 初级的业务人员，参与需求分析和产品功能设计，通过对用户心理和行为的调研，选用恰当的UI/UX元素和设计原则，并和技术人员沟通可行性，构建产品原型，同时满足技术成本要求，又提升用户满意度。这时，他关注的是交互设计和用户体验，即这样的操作设计能多好地实现既定功能。
  
• 产品经理则主导业务分析和负责整个产品设计，推动产品的实现和运营，参与产品Idea的产生过程，对市场分析和产品生命规划有一定的了解。贡献在于甄别真正有价值的问题，定义产品功能和优先级，确保解决用户问题，创造用户价值，并通过产品价值指标来衡量和验证。这要求产品经理具备价值判断能力和很强的沟通能力。
  
• 发展到产品总监级别，要主导市场分析和产品规划，掌握用户群体的属性，负责产品Idea的产生，进行产品全生命周期管理，要求有丰富的行业知识和深刻的市场洞察。此时已经兼具业务和管理职责了。
  
• 再往上就该是公司老总级别了，主抓公司战略，业务方向和市场布局。负责整个公司的运作。
  

这么看，业务角色的发展空间很大。即使你现在只是一个测试人员，你也可以朝着业务方向发展。我之前把测试归并到技术中去了，其实用来验证产品功能的测试工作，是在看界面行为是否符合设计，这是业务人员的职责之一。在积累了大量的功能操作经验之后，可以尝试参与功能设计和用户调研之类的初级业务工作了。
如果你对技术细节总是一头雾水，但是对用户体验倒是很有想法，你更关心别人的感受和使用习惯，有同理心，别人说很难交流的用户，你能轻松搞定。对于某款App，你能体会到某点设计的好处，又能找出不当之处，并知道为什么。那么，说明你比较有产品意识，你真可以尝试一下业务方向。
这里提一下技术人员看待业务代码的问题。有些涉及业务开发的工作，比如前端UI实现、业务数据操作、业务逻辑处理等，某些开发人员，不愿意写这些业务代码，认为这部分更靠近用户，多变、琐碎、只是逻辑控制，没有技术含量，而更愿意编写底层的框架、事务处理机制等模块，这些模块有通用性且可复用，显得很有成就感。殊不知，这些底层技术，正是为了适应业务代码的需求而编写的。如果不了解业务代码的需求，你所理解的底层技术只是代码而已，而不会明白为什么用这种技术，不会明白它和其他模块是出于什么业务目的划分边界，进而不会明白各个产品团队为什么如此组织和协作。
3. 管理角色

最后我们看看管理角色，它包括项目经理、业务主管、技术经理、部门经理等等（不同的公司可能用不同的名称，而且可能一人担任多职）。这些管理角色的侧重点有所不同：项目经理，负责项目的成败；业务主管，负责业务开拓和发展；技术经理负责技术开拓、技术培训；部门经理负责人员绩效、部门发展……但他们的共同目标都是优化人、财、物等资源的配置，用最小的投入，获得最大的价值产出。
这里有必要区分一下管理和领导的概念。以上说的是管理（Management），是有具体头衔的职位，管理具体事务或者人；而领导（Leading），是从管理中分离出来的影响他人的行为，不一定有具体头衔。也就是说，即使你是一个技术人员，不是部门经理，也可以在团队中具有领导力（Leadership），你的技术权威，可以影响他人的决定和行动。关于领导力的话题，我在后面的文章中会详谈。
说回到管理。管理的角色很多，我这里单说项目管理。传统项目管理者的关注点是过程和质量控制，从而达到预期的成本、范围和进度要求。在敏捷管理中，项目管理的关注点放到了人上：更注重团队成员的自我管理，项目经理转变为协调者和服务者的角色，产品经理负责价值递交，因而产品交付不再是项目经理一个人的责任，有的团队把产品经理和项目经理合并为一个角色，让同一个人承担；透明化、可视化的沟通手段，也使项目经理的沟通工作变得简单直接；团队的开放性和自主性，使创新意识和主人翁意识得到很好的发挥，项目经理不再做监工；项目经理需要开放思想，承认项目范围是可以按迭代调整的，容忍快速试错，拥抱变化，提醒和促进团队正确地做事。
尽管管理者们的管理风格多种多样，但是有一个基本的特质是：有条理（Organized），也就是善于安排事情的优先级和组织过程，目的是保持秩序，使过程可控。一个Organized团队中，角色分工明确，工作先后有序，大家配合默契，资源随用随取，流程清晰简洁，成功率很高，能够最大限度地降低不确定性。
所以想想自己，即使还没有管理的头衔，就日常的事情来说，你是否趋向“有条理”呢？比如，你习惯把常用的东西放到固定的位置么？你会按照使用场景优化它们的位置么？你正忙的时候接到一个新任务，是否先衡量一下轻重缓急，再决定要不要切换任务呢？如果是，说明你比较有条理，可以发展下管理意识。
角色融合

当我们刚开始工作的时候，会着力在一种角色上发展。但是发展到越高的阶段，越会发现只有一种角色的眼光和技能是不够的。拿架构师来说，如果眼里没有业务和用户，即使采用的技术再好再新，不能解决用户问题，也不是好的架构师。另外，如果架构师没有管理思维，无法在团队中发挥技术影响力，就不能把设计的精华落实到产品中去，也不能带出精兵强将来。
下面这个图，包含技术、业务、管理三个维度，我们每个人都在每个维度上有一定的能力，承担一定的职责。这样，在三个轴上围出一个三角形，这个三角形就代表了你的角色融合程度和角色跨度。尽量按照你的能力和愿景去拓宽这个三角形吧，它展示了你的能力多大、责任多大，以及对公司、对社会的价值多大。



总结

谈到这里，相信你已经了解了软件产品团队的三种角色，以及它们的关注点和特质。

• 技术角色：关注技术和逻辑实现，可发展为“T”型人才，需要有对技术的钻研和敏感性。
  
• 业务角色：关注用户和价值，有同理心。
  
• 管理角色：关注过程质量，有条理。
  

技术、业务和管理的角色，本身没有好坏之分，只是关注点不同，你需要根据自身特点，选择适合的发展方向。
如果你觉得自己是普通人，不相信自己能发展成大牛或者大神，不要紧，先别下结论。让我们先做个有“饥饿感”的普通人吧。保持这种“饥饿感”，一步一个脚印地走下去。
走着走着，你会发现身边多了很多优秀的人；
走着走着，你发现你也可以给别人营养了；
走着走着，你发现别人开始仰视你，跟随你了；
走着走着，你发现头发掉光啦（好无奈呀）……
思考时间

根据上文介绍的技术、业务、管理三种角色的特质和发展阶段，请你想一下自己具有什么特质，适合发展哪类角色，当前处于哪个发展阶段呢？
欢迎在留言区分享你的想法，和大家交流互动，共同进步。

陈国宝

图片的这个视频在哪里可以看呢

客官没问题

挺大的，挺白的，我是说文章的字体

壹周滿八天

培训机构

龙武

写的挺透彻的啊，比较清晰的描述，有一定的干货

作业太多很烦脑

写得很好，尤其是角色分类，和业务人员（产品经理）职业天梯的部分