首页   注册   登录

ibegyourpardon

V2EX 第 158321 号会员,加入于 2016-02-07 20:12:56 +08:00
今日活跃度排名 12492
听说有人证明了黎曼猜想……
数学  •  ibegyourpardon  •  23 天前  •  最后回复来自 frylkrttj
8
好多人喜欢用 iV2EX 的梗
V2EX  •  ibegyourpardon  •  2017-08-07 18:07:49 PM  •  最后回复来自 66beta
4
最近的 ofo 感觉变的少多了……
互联网  •  ibegyourpardon  •  2017-05-05 09:19:23 AM  •  最后回复来自 BearD01001
51
同事即将离开长沙去深圳,给做个推荐, PHP
职场话题  •  ibegyourpardon  •  2017-03-30 15:36:10 PM  •  最后回复来自 vingc723
6
才发现这个节点,这其实不就是个临时的 gist 么……
问与答  •  ibegyourpardon  •  2017-03-22 17:01:33 PM  •  最后回复来自 ibegyourpardon
1
ibegyourpardon 最近回复了
买,不要犹豫。
家里又不是没有这个条件。
5 天前
回复了 chaleaochexist 创建的主题 程序员 请教,rest api 的设计问题,关于粒度.
@guijianshi01 哈哈哈,理解理解,我就这么过来的。我的做法不敢说是完美,也是一个一个坑才过来的血泪史。

最核心的,我称为核心功能接口,我是尽最大可能划分到最细的粒度,比如一个 auth,这类接口我设计的时候原则上是不直接暴露给前端调用的,因为直接暴露意味着给前端需要请求太多的内容,无论性能还是开发流程上都不可接受,前后端会打架的。

但这类接口也不绝对,某些高频,无法也无需改动的,比如授权,这种模式下我会适当直接传给前端。

然后核心功能接口写出来其实是为了给后端调用的,用来做各种业务接口组合。这里面也是血泪史,差点和后端打疯,后端说我几个 import 的事你非要我调网络请求的形式来(我们目前的能力只能以 RESTful API 的形式互相调用),包括业务接口不一次写完,而是写完再组合… 但最后后端发现,在不同的项目中,熬过前期后,往往重新组合包装一个接口提供给前端,会变的异常轻松。

当然这里也有 API 网关这个我 18 年年初才学到的概念的支援。包括我上面讲的模式里,其实在包装组合接口提供给业务用这件事上,前端突然发现他们也有能力直接调用以及做组合了,所以业务上其实突然变的相对好一些了。

但一个系统的总体复杂度是不变的,对应的,压力放到了我这边,我自己做的这个设计和决策,现在我要为统筹管理和理清这么多接口、模式进行负责,这个压力也大。可总比和大家一起开会分析那绕来绕去的业务逻辑还是要轻松一些的。

所以我写了这么多,其实也没有直接回答你的问题。全部写一起肯定是弊大于利,畏手畏脚,甚至逼不得已要重新写一个新的大的单体出来。拆开的不合理的话,又会东改西改,并且接口功能重复,模糊,界限不清。

但就我自己的经验而言,还是要拆,拆的时候优先提炼出核心的不变的东西,尽可能在少增加额外开发的情况下将接口复用组合提供出业务接口来。而且业务接口尽量不要由核心系统直接提供,一定要有个 API gateway 层,让这个层来承担接口的分发工作。 我们用的也不好,业务中有大量冗余接口,也有很多沉没的存在安全隐患的东西,这个以后早晚要慢慢解决。但小公司,四五个人的团队,只能先到这样了。
6 天前
回复了 0xxf 创建的主题 程序员 请教一下各位关于前端多项目的问题
也是老生常谈的话题了,讲的其实挺没意思的。

说到底啊,这行业的业务变化啊,太快了。。唉,做的累。
6 天前
回复了 0xxf 创建的主题 程序员 请教一下各位关于前端多项目的问题
这个我有话要说。

我就干过类似楼主领导的事,要求别人(最后因能力问题搁浅,后来重新慢慢尝试,小步慢跑)。

中间不同的项目里反反复复很多次。

目前我仍然持有和楼主领导接近的想法,但不再那么激进,会根据实际情况进行调整和妥协。

但从一个系统架构设计的角度来看,我仍然认为拆分利大于弊,包括这种有人认为的过度设计的部分。首先过度设计就是个并没有绝对标准的东西,怎样算是过度的设计?

在项目进度允许,团队成员能力足够的情况下,一个总体复杂度为 10 的东西,而这个复杂度其实是大致可以预见到的,比如 3 个月做出来这个东西,相对可控,但 3 个月后这个项目会变成什么样,怎么发展,我不可预知,不可控,那就不考虑那种做成运行几年,团队扩充到 20 人的事。 但这 3 个月内可能会有的变动,模块和组件的拆分,部署的调整,哪些事情我提前做是可以预留的,这个讲实话,我是觉得需要很深厚的经验积累的。而运用的恰到好处的话,对团队,项目都是有极大的好处。

也就是说,我并不赞同一上来把整体复杂度为 10 的单体应用拆成 10 个 复杂度为 1 的模块,但根据实际情况,拆成一个略小的复杂度为 5 的小单体+ 5 个复杂度为 1 的小模块,是不是会更有利于项目推进、迭代试错、能力培养呢?

而且在开发周期较长的项目里,不考虑因为拆分带来的额外复杂度的情况,就项目本身而言,经常是这么一个转换节奏:

5 +3 + 2
5 + 1 + 1 + 1 + 1 +1
4 + 1 +1 +1 +1 +1 +1
4+ 2 + 2 +1 +1
3 + 1 +1 +2 +1 +1 +1

也就是楼上有人说的那句话,合久必分,分久必合。楼主的领导可能有过度设计的嫌疑,但楼主这种一个大单体的思路其实也有些理想化了——什么项目都经不起变啊,变着变着就要了亲命了,尤其是前端这种没有好的工程化体系的地方(不管 webpack 有多强,vue 多好用,只要还是 js,就注定没有好的工程化的基因)。

当然,我说了也白说,领导最大,木已成舟,估计楼主应该已经吭哧吭哧的做了蛮久了……
8 天前
回复了 chaleaochexist 创建的主题 程序员 请教,rest api 的设计问题,关于粒度.
@chaleaochexist 关于二次封装接口这事,其实对我这样的小团队来说怎么看都是 import 更划得来,大家都用 PHP,为啥想不开要给自己对自己用接口调用,但这事我还是坚持接口化。就我这边来说,接口化不会带来多少性能损失,却给我这样的小团队和外部合作留下了足够好的基础(我们经常有交叉形式的外包),甚至某些接口我们作为收费卖给隔壁同行们……

当然这里面我还有个出发点,是为了三年战略中,逐渐引入 Java 或者 Go 开发人员和目前的 PHP 栈混用,这时候通过接口通信的模块化意义就更大了,这是和我司实际情况有关。
所以你想学的是后端语言对吧?

语言好像不是差别很大,除非还想做单体应用,如果为以后考虑,Java 和 Go 都可以考虑下。
9 天前
回复了 hulei 创建的主题 前端优化 如何检查前端 HTML 与 UI 的效果还原度?
首先,实际页面存在多设备兼容这个问题,除非 UI 全给做到,否则 100% 还原度就没法做到。

我们现在暂时提倡的方法是不追求字面意义的 100%还原,而是由 UI 给出对元素兼具,字体大小等等的要求,详细到 font-size,元素在不同界面尺寸下的不同间距,然后前端只管照这个来堆上去。
9 天前
回复了 zzljzeng 创建的主题 问与答 学习进修
既然是想深造,选个自己有基础有兴趣愿意攻关的,然后放心大胆的学吧。


我自己是大学本科,上一半跑路退学,现在三十多岁,然后现在从成人高考开始重新开始学习,选的不是自己现在做的开发和计算机有关的方向,但有我多年工作经验加成,我也有兴趣,希望四十岁的时候能小有所成。
20 天前
回复了 chaleaochexist 创建的主题 程序员 请教,rest api 的设计问题,关于粒度.
实际操作中我们是这样。

一,有一组粒度极细,原子化的基础接口。

二,一部分常用的业务接口,对基础接口做二次封装。能满足 70% 的调用需求。

三,有 10%左右的需求因为目标简单明确,直接去了第一条里提的那些接口。

四,有一些临时项目需求,临时拼装一些小接口。

所以像你说的问题,我是绝对会拆出一堆各种 API 来的。

业务千变万化,所以我是要什么给什么,能拆分的 API 绝对拆开,不怕接口多,就怕接口改。改起来才是真要命,千丝万缕在一起。

业务 API 因为太多,所以时间久了会有重复功能的接口,我也毫不在意,因为这类接口只直接为一个业务服务,业务哪天变了或者撤了,老的接口也就没用了。
24 天前
回复了 tinyuu 创建的主题 Apple 256G 当 iphon 能不能当移动硬盘或者优盘用
能,有变通方法,但不好用。

而且似乎也没必要这么用。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3868 人在线   最高记录 4385   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 19ms · UTC 05:54 · PVG 13:54 · LAX 21:54 · JFK 00:54
♥ Do have faith in what you're doing.
沪ICP备16043287号-1