本文目录一览：
北大青鸟设计培训：开发项目都有哪些常见问题？
一般来说，软件编程开发项目都是需要很多部门与开发程序员配合来实现的，下面我们就一起来了解一下，目前常见的互联网软件开发项目都有哪些问题。
一、信息同步尤其是跟外部团队合作时，信息同步是重中之重。
明确整体项目的目标，清楚自己所在的细分项目在整体项目中所处的环节和作用，以及同其他团队的协同依赖关系。
在这里需要向对外的接口人了解整体项目的完整流程，而且一定要跟对方项目的接口人完全对一遍项目整体流程，让对方明白我知道整体项目流程目标和自己所在环节和作用。
沟通项目流程时要保证产品、技术(前端、后端)、内外接口人都在场，这可以避免出现缺失某个环节导致的实现问题。
二、明确需求明确需求在项目正式开始之前是非常必要的一步。
开发以及测试需要对产品功能有一个全面的了解和时间上的风险评估。
这一方面需要产品同学给出一个详细的产品流程、原型图以及需求文档，同时需要拉上相关团队负责人、以及技术同学进行需求评审。
碰到过几次产品的需求不明确结果项目进行中出现问题，需要产品重新梳理相关模块逻辑，有很大的项目延期风险。
同时产品的需求受到多方面的因素影响，比如时间、历史包袱等因素，肯定会存在初期有部分细节不明确等问题。
这也是项目的渐进明细原则，遇到这种问题要及时反馈，在各方博弈中找到一个相对适用的平衡点。
三、技术选型对于从0到1的项目，技术选型是非常关键的一步。
做技术选型一定要从业务角度思考而不是做技术炫技，要考虑整体业务时间、团队成员的基本水平、团队成员对某些技术的熟练程度、技术工具框架的成熟程度、社区的活跃性、业界是否有成功的案例、生态的完善程度以及背后的支撑团队。
有技术追求的同学在初期技术选型时容易盲目追求新技术工具和框架，从而带来项目风险。
早在上一家公司做项目时，业界成熟的框架是React和Angular2，不知为什么负责选型的同学选了还在beta版本的angular2，导致后期升级迭代出现重大问题。
同时在技术选型确定后，在开发之前一定要规划技术架构。
做架构的基本思路是分层，层内分模块，模块要做到单一职责。
电脑培训发现各模块之前尽量降低耦合，保持架构的可扩展性。
做架构时可以问自己两点：这个架构能够允许多少人同时参与这个架构能够支撑业务发展多长时间
销售策略——不同类型的客户关键人的应对技巧
在我们的销售过程中，会遇到不同角色类型的关键人，我们按照角色将他们分为最终决策者、技术选型、应用选型与内部倡导者。顾名思义，最终决策者是最后拍板的人；技术选型是指标准的把关与制定；应用选型是指直接使用产品并获取利益的人；倡导者是指支持我们的产品，并且可以告知我们项目有效信息的指导人。
如何应对不同角色的关键人呢？
1.技术选型者
技术选型者不能直接决策，但是有直接说“NO”的权限。可能在部分的技术选型者会有一个小小的误区，就是将否定和建议的权利当成了决策权。 那对于技术选型者来说，一定不要忽视他的存在，必须尊重他，否则项目可能会受到阻力。 同时在项目推进过程中，除了考虑公司项目上线的有价值的结果外，需要了解到对于技术选型者个人的工作有无影响，能否让他个人也得到相关的利益的提升。
2.应用选型者
应用选型者是项目上线的需求者，因为只有业务提出需求，才能根据标准采购。所以对于应用选型者的应用成功和使用人员的评价非常重要。 在对接应用选型者，我们一定要关注并理解应用选型的感受。 他们更加关注系统使用后的场景，所以我们也可以针对性的讨论如何使用而非产品本身，更加关注他们的处境和动机。但是对于如何获取应用选型者的直观感受和使用感受是我们需要攻克的难题。
3.内部倡导者
内部倡导者在我们的项目过程中取到决定性作用。他是我们销售的指导者和领路人。首先他能给我们有效信息，并且能够帮我们核实某些消息的准确性，同时能我们在制定战略的时候可以和我们的内部倡导者进行商议，与他确认战略的有效性和可执行性。 所以我们在执行项目过程中，一定要发展一名内部指导者。 但是需要我们区别的是关系好的，喜欢我们的不一定是倡导者，信息提供或许是他本身的职责 。在与内部倡导者确认的过程中，一定要有三个原则，互相信任，他被决策者信任和他对我们有十足的信心。 最后呢，内部倡导者可以说是我们项目中的一枚暗牌，一定不要让他为我们出面。
4.最终决策者
在与最终决策者沟通的过程中，我们 必须先确认到最终决策者对于我们项目的态度和支持度 。（可以和内部倡导者确认）。在不同的态度和支持度下，我们的应对措施也是不一样的。
如果最终决策者觉得目前阶段已经是不错的，没有必要改变什么的情况。那就是他本身对于项目没有期望。这时候我们一定要和最终决策者建立起新的期望，用事实和第三方展现远景。有些销售会深挖痛点，但是值得注意的是我们制造问题的时候一定要讲策略，不要让最终决策者跳脚。
如果最终决策者认为目前阶段已经比别人好太多了，改变说不定还不如现在。这种情况下我们一定要用柔和的方式去交流，满足最终决策者“自满”的情绪的释放需要。这时候的等待也许就是上策。
如果最终决策人已经意识到了现在的情况是有问题的，需要解决的。这种情况下我们在谈技术优势、产品优势往往都不会奏效，我们最需要的是能够提供出解决目前他的问题的方案。
每一个关键人在项目的不同阶段的参与度也会不同。通常是应用选型、技术选型、最终决策。所以忌讳就是在某一个阶段做某个关键人的商务公关工作，而忽略了其他关键人。针对性的去完成销售战略性的工作。
前后端分离方案以及技术选型
作者：关开发
一.什么是前后端分离？
理解前后端分离大概可以从3个方面理解：
1. 交互形式
2. 代码组织形式
3. 开发模式与流程
1.1 交互形式
前后端不分离
后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。
前后端分离
后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。
1.2 代码组织形式
前后端不分离
在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。
前后端分离
前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。
1.3 开发模式与流程
前后端不分离
在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。
具体开发流程如下：图略
前后端分离
实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行，或者前端先行于后端开发了。
具体开发流程如下：图略
二、前后端分离的好处与坏处。
从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。
从目前应用软件开发的发展趋势来看，主要有两方面需要注意：
· 越来越注重用户体验，随着互联网的发展，开始多终端化。
· 大型应用架构模式正在向云化、微服务化发展。
我们主要通过前后端分离架构，为我们带来以下四个方面的提升：
· 为优质产品打造精益团队
通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。
· 提升开发效率
前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。
· 完美应对复杂多变的前端需求
如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。
· 增强代码可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。
那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。
二、前后端分离架构方案。
实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。
对于目前用于前后端分离方案的前端技术架构主要有两种：
· 传统SPA
· 服务端渲染SSR
2.1 传统SPA
传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。
单页面应用的运行流程
1.用户通过浏览器访问网站url
2.单页面的html文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。
3.css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。
4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。
2.2 服务端渲染
服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。
它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。
服务端渲染应用的运行流程：
1.用户通过浏览器访问网站url
2.NodeJS服务端接收到请求，读取到对应的前端html，css，js。
3.NodeJS解析执行js向后端API异步请求数据。
4.NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。
5.NodeJs向浏览器输出html，浏览器进行展示。
PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。
看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？
2.3 SPA与服务端渲染方案对比
SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。
so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：
与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：
· 更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。
请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。
· 更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。
无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。
使用服务器端渲染 (SSR) 时还需要有一些权衡之处：
· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。
· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。
· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。
以vue为例，实施服务端渲染可以查看官方指南： ，或选择Nuxt.js
2.4 预渲染技术
如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。
如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。
prerender-spa-plugin:
三、前后端分离技术选型
- artTemplate + bootstrap（不推荐， 不算完全前后端分离）
- vue全家桶（推荐）
- react全家桶 （推荐，生态全）
产品选型是什么意思？
产品选型的意思如下：
所谓的产品选型其实指的是公司因为技术实力、资质、市场环境等，对市场上的商业软件产品进行功能、性能、价格、运维等方面进行综合考量，并输出相应的选型报告进行对选型结果进行总结汇报。其目标就是输出调研过程分析、给出分析结果供管理层进行选型决策。
产品选购的注意事项：
1、不做囚犯式的采购。
作为采购，当你跟供应商谈判的时候，你不仅要多听，多问，少说，而且还要注意，不仅仅要听声音，而且要听内容。
2、善于反问。
当你的供应商很善于提问时，对你来说未必是一件坏事。有的时候供应商先提问你，你再反问他，他反而没有办法再问你了，他没有问到你的问题，你反而问到他的问题了。
3、善于果断地回答问题。
当别人提出问题，需要你回答时，为了提高你回复的可信度，你一定要记住回答时心里不要犹豫。也就是说，回答问题要果断，如果你犹豫后再回答，给出在好的答复别人都很难相信的。
