自 2009 年 nodejs,angular 诞生, 前端的发展进入了一个新的纪元。正是从这个时候开始前端独立成为一个工种分支。美工,前端,后端成为软件企业纷纷追求的研发工种配置。
混合移动应用的兴起,一套独立的前端代码可以同时运行在 PC 浏览器,移动 APP 上。让管理者可以砍掉大部分昂贵的原生 APP 开发。
商业利益的驱使,从此以后前端框架和工具层出不穷。
Backbone,Vue,React 等等数十种,而后端程序员喜欢用的传统老牌 javascript dom 框架 JQuery 被大家嗤之以鼻。
一个产品的研发是否成功与以下几点有密切关系
1.技术学习曲线。
2.业务学习曲线。
3.版本迭代周期。
4.人力成本。
5.维护成本。
6.代码复用度。
7.结构扩展度。
衡量一下你们参与的产品研发是否遵循了这几点。
在纯前后端分离的研发组织里,
前端的框架和工具已经到了令人眼花缭乱的程度,太多太杂。
React+Redux+React-Router+Redux-Saga+Immutable
Angularjs controllers services directives filters routes
做大型复杂的云服务控制台应用,一定不是一笔小的投入。如果要做系统变更,换一波前端研发是否能抗住旧系统的锅还待商榷。
因为前端和后端人员在整个研发周期面对的就是产品经理给出的各种接口和实现,至于业务就是那接口中定义的一个一个的参数。后端对于这种盲人开发特别头痛。最了解业务的只有产品经理,而产品经理往往都不是技术出身或者技术底子很薄。在一个比较复杂的业务实现里,没有人知道怎么去优化这个实现。
前后端分离造成了前端和后端的沟通障碍,经常一个 BUG 丢给前端,前端查了很久,然后对照 API 文档(他也不知道这个 API 文档是否是最新)查不出问题,就丢回后端。后端盲人开发,也只能去对接口,查日志数据,靠模拟数据而没有直接 debug 的优势是很难查出问题的。很可能造成这个 bug 的源头是设计错误。前后端互相推诿的情况应该很常见。
两个解决思路,
1 .前端统治的全栈框架。后端采用 nodejs。
2 .后端统治的全栈框架。让前端只专注于 css 和特效。普通开发从前到后整个数据流全部包完。这需要一个对普通 java 程序员友好的 javascript 框架。
混合移动应用的兴起,一套独立的前端代码可以同时运行在 PC 浏览器,移动 APP 上。让管理者可以砍掉大部分昂贵的原生 APP 开发。
商业利益的驱使,从此以后前端框架和工具层出不穷。
Backbone,Vue,React 等等数十种,而后端程序员喜欢用的传统老牌 javascript dom 框架 JQuery 被大家嗤之以鼻。
一个产品的研发是否成功与以下几点有密切关系
1.技术学习曲线。
2.业务学习曲线。
3.版本迭代周期。
4.人力成本。
5.维护成本。
6.代码复用度。
7.结构扩展度。
衡量一下你们参与的产品研发是否遵循了这几点。
在纯前后端分离的研发组织里,
前端的框架和工具已经到了令人眼花缭乱的程度,太多太杂。
React+Redux+React-Router+Redux-Saga+Immutable
Angularjs controllers services directives filters routes
做大型复杂的云服务控制台应用,一定不是一笔小的投入。如果要做系统变更,换一波前端研发是否能抗住旧系统的锅还待商榷。
因为前端和后端人员在整个研发周期面对的就是产品经理给出的各种接口和实现,至于业务就是那接口中定义的一个一个的参数。后端对于这种盲人开发特别头痛。最了解业务的只有产品经理,而产品经理往往都不是技术出身或者技术底子很薄。在一个比较复杂的业务实现里,没有人知道怎么去优化这个实现。
前后端分离造成了前端和后端的沟通障碍,经常一个 BUG 丢给前端,前端查了很久,然后对照 API 文档(他也不知道这个 API 文档是否是最新)查不出问题,就丢回后端。后端盲人开发,也只能去对接口,查日志数据,靠模拟数据而没有直接 debug 的优势是很难查出问题的。很可能造成这个 bug 的源头是设计错误。前后端互相推诿的情况应该很常见。
两个解决思路,
1 .前端统治的全栈框架。后端采用 nodejs。
2 .后端统治的全栈框架。让前端只专注于 css 和特效。普通开发从前到后整个数据流全部包完。这需要一个对普通 java 程序员友好的 javascript 框架。