上海web技术培训

Web前端开发和web后端开发的区别？

想从事软件业的毕业生们大多要从基础的程序员做起。相较于其他的职位，Web软件开发工程师是一个技术要求较高、前景较好的工作。Web软件开发工程师可以分为Web前端和后端开发。那什么是Web前端，什么是Web后端呢?它们的差异在哪里?在工作中又分别会遇到怎么样的问题呢?乔布小编浏览了大量的资源，为童鞋们整理了这样一份资料，主要分为前端和后端的 差异 和它们各自所 面临的挑战 。希望对你有所帮助!

Web前端和后端的差异

职能上的差异

首先，我们要分清Web designer(网页设计师)和Web developer(网页开发者，也称程序员)的差异。两者之间的差异主要表现在：一个是有关网站的视觉或美学方面，被称为“前端”;另一个则是看不见的编码方面的设计，被称为“后端”。简而言之，漂亮的网站界面都是出自网页设计师之手，而牛逼强大的功能则是网页开发者的杰作。

除了职能上的差异之外，两者还有其他许多差异。国外设计网站Downgraf特意制作了一张图表来展示——网页设计师和网页开发者(程序员)都留胡茬，一个没钱，一个没时间;两者都喜欢内涵T恤，一个走字体设计路线，一个走代码风;两者都配自家设备，一个必带MacBook Pro，一个只挑小键盘……除了以上种种差异，他们还有一个共同点：害怕MM，看来都是“宅”惹的祸。

技术上的差异

我们再从技术的方面，瞧瞧在实际的招聘中，各大企业要求前端人员与后端人员分别具备怎样的能力。

Web前端：

1. 精通HTML，能够书写语义合理，结构清晰，易维护的HTML结构。

2. 精通CSS，能够还原视觉设计，并兼容业界承认的主流浏览器。

3. 熟悉JavaScript，了解ECMAScript基础内容，掌握1~2种js框架，如JQuery。

4. 对常见的浏览器兼容问题有清晰的理解，并有可靠的解决方案。

5. 对性能有一定的要求，了解yahoo的性能优化建议，并可以在项目中有效实施。

Web后端：

1. 精通jsp，servlet，java bean，JMS，EJB，Jdbc，Flex开发，或者对相关的工具、类库以及框架非常熟悉，如Velocity，Spring，Hibernate，iBatis，OSGI等，对Web开发的模式有较深的理解。

2. 熟练使用oracle、sqlserver、mysql等常用的数据库系统，对数据库有较强的设计能力。

3. 熟悉maven项目配置管理工具，熟悉tomcat、jboss等应用服务器，同时对在高并发处理情况下的负载调优有相关经验者优先考虑。

4. 精通面向对象分析和设计技术，包括设计模式、UML建模等。

5. 熟悉网络编程，具有设计和开发对外API接口经验和能力，同时具备跨平台的API规范设计以及API高效调用设计能力。

总而言之，两者的差异在于

职能上，前端主要负责界面的设计;后端主要是制作界面后的功能。

形象上，前端注重形式、美观;后端注重功能、实用性(为此，小编还特地去了乔布堂的研发部做了实地考察，发现我们的前端工程师买了2台Macbook，而后端工程师买了2个键盘。惊人的符合!)

企业招聘中，前端工程师需要精通JS，能熟练应用JQuery，懂CSS，能熟练运用这些知识，进行交互效果的开发;后端开发人员需要会写Java代码，会写SQL语句，能做简单的数据库设计，会Spring和iBatis，懂一些设计模式等。

要成为一名高效的Web开发者，需要做很多工作，来提高工作方式并改善劳动成果。而在开发中难免会遇到一些困难。那么，前端与后端分别面临的挑战主要有哪些呢?来和小编一起看一看吧!

Web前端开发面临的挑战

前端开发的五大挑战

第一大挑战：兼容性

浏览器种类非常多，IE、Firefox、Chrome、Opera、还有众多的IE加壳浏览器，类似搜狗、傲游、360，再加上这些浏览器的移动终端版本。需要有Web标准，前端的知识大部分通用于各个浏览器，但还是会有历史遗留问题，不同版本的浏览器有不同的问题。特别是市场占有率最高的IE系，虽然IE 9/10看起来相当标准，但向之前版本间各有各的问题，向前兼容非常头疼。如果不积累点经验，面对疑难杂症那是一头雾水。

第二大挑战：交互的复杂度

CSS和DOM提供的接口水平过低，而BOM提供的控件只有input、select、textarea这几种最基本的，稍复杂一点的UI效果，都要前端自己利用CSS和DOM去组合创造。看到一个需求，脑子里第一步要想如何利用CSS、DOM这些基本的零件组合成最终的效果，实现最终效果其实是一个“创造”的过程，比如说tabView,treeView,richEditor,colorPicker这种看起来常见的组件，其实在前端里都是没有现成可用的，需要自己去实现。

前端语言的 胶水性需求 太强。CSS、DOM、JS是三种不同的技术，这也是前端知识系统中要掌握的最重要的三个基本功。前端的效果是通过CSS、DOM、JS三者配合起来最终呈现出来的，脱了任何一个技术都寸步难行，时刻要同时考虑多个方向的知识点。前端编程像是开了三个线程同时在跑，复杂度成倍增长。

第三大挑战：代码可维护性

复杂度的提升直接影响代码的维护性。CSS+DOM+JS的组合实在太强大了，同一个效果可以有多种完全不同的实现方式，每一种实现方式都会有不同的开发难度、扩展性、可维护性。解决方案太多，看到一个效果首先会先想到如何用CSS和DOM里那些low level的接口实现，这是一个“创造”的过程，这时脑子里可能冒出好多种不同的实现方法，“创造”完了之后还要“比较”，权衡各种解决方案的优劣，纠结一阵之后，才能选出最适合的方案。当然，并非前端都是完美主义，一定要选一个**的方式出来，而是因为前端是GUI编程，直接面向用户，是最直接的产品呈现的部分，是门面。正因为如此，前端也是最容易被反复修改的部分。反复“修改”有多可怕，是个程序员都懂的，如果可维护性不好，那简直是恶梦。所以前端不得不重视可维护性，不重视可维护性直接等于自虐。

第四大挑战：性能

第五大挑战：个人成长

开发者的思路很重要

前端的开发，如果没有总体的设计思路，会成为一种碎片似地程序，一个效果一堆代码，一个功能一滩脚本，一个需求片逻辑。曾经遇到过，因为ue调整，把整个前端的代码除了核心数据处理函数保留，其余的全部修改的情况。基本上前端的开发，处于DOM操作，数据处理，数据交互三部分，如果合理的分配这三部分的功能，那么前端的代码就很容易扩展和调整。

真正的前端开发挑战，还在于开发者的思路。兼容性，布局，CSS和JS都不是问题，问题在于如何合理地组织语言逻辑;如何正确抽象出需求中的模块;如何用代码处理，清楚地用代码表达出思路、写好注释，给后续维护者一个可阅读的思路。前端的改动量，是后端的数倍，前端没有绝对，只有跟随需求不停的修改。

Web后端开发面临的挑战

后端开发的五大挑战

第一大挑战，后端开发最重要的挑战，来自于规模

规模的扩大，比如访问量扩大，文件存储量扩大，数据量扩大，服务器数量扩大等。一个前端看起来一模一样的网站，某一种指标如果扩大十倍，几乎都会面临一大堆的问题和挑战。另一方面，在规模扩大以后，后端系统架构，一定会复杂化。原来只有一台Server，LAMP都装在一起。然后数据库分出来，反向代理，负载均衡，分库分表，Memcache，Message Queue，事务处理，CDN，NOSQL，种种架构，Server，就逐渐的演化出来了。架构的复杂化，自然会带来更多的问题和更多的挑战。

第二大挑战，来自于安全

安全问题层出不穷，防不胜防。需要技术手段，也需要管理制度。

第三大挑战，来自于效率

能否提供足够的处理速度，能否提供足够的带宽，能否保证响应能力，这些是对外的效率。能否使用更少的服务器，能否使用更加便宜的服务器，能否使用更加节省能源的服务器，这些是对内的效率。

第四大挑战，来自于需求变更

无论前端后端，都会面临需求变更，只要是软件开发，这都是大挑战。但是当一个系统已经稳定的，高效的运行时，需求变更来了，在满足需求之后，原本来没有问题的部分，会不会突然崩溃，一旦崩溃，就是后端工程师的噩梦。

第五大挑战，来自于教条

这个世界上有无数IT大公司，他们都很开放，都愿意分享自己的架构与技术。于是，对于“眼界开阔”的后端工程师而言，困难不在于如何解决，而在于如何从众多的解决方案中做出挑选。框架、实践不断涌现，成功案例也不断涌现。人家都用得好好的，你敢用吗?到底是勇于尝鲜，还是保守要紧呢?这个很难。

后端开发的三大法则

Design for failure

后端相当比例的代码不是为了一般情况下正确而存在，而是为了保证特殊或者极端情况下系统可接受的响应而存在的。这里有非常多的折衷要做：渐进改进还是超前设计?水平扩展、业务优化、前台还是后台处理?大量的折衷都是要根据不断变化的环境和需求去权衡的，所以很容易犯错。

Architecture is about abstract

为什么要抽象?因为抽象的概念有更好的适应性，更易于复用，更能灵活适应变化。但是抽象是很难的，不恰当的抽象更是贻害无穷，要命的是，这些并没有很好的方法论，多数是依靠一组基本的原理，凭经验作出的。而Web后端开发在很长时间里并没有很重视这些，很多网站都是粗放型设计和开发出来的，所以补丁叠补丁的结构就顺理成章的成为了主流。

Architecture is product

为架构本身即产品，一个软件产品包含了不同的视角，其中最重要的包括用户看到的视角、以及软件骨架即架构的视角。但产品就是产品，所有这些视角都是必须统一和一致的，这就要求架构必须理解产品的灵魂，而产品要理解架构的困难所在，否则很容易出现想做的事情做不到或者以巨大的架构代价实现一个边角功能这类悲剧。