首页   注册   登录

ibegyourpardon

V2EX 第 158321 号会员,加入于 2016-02-07 20:12:56 +08:00
听说有人证明了黎曼猜想……
数学  •  ibegyourpardon  •  50 天前  •  最后回复来自 frylkrttj
8
对大量前端代码的版本化管理,有啥好思路不
问与答  •  ibegyourpardon  •  2018-02-26 16:42:13 PM  •  最后回复来自 doublleft
3
好多人喜欢用 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 最近回复了
11 天前
回复了 yangyifan 创建的主题 问与答 关于 Nginx 和 PHP -fpm 通讯的选择
我记得还是有差别的。。需不需要走网卡。。。
11 天前
回复了 zhangpeter 创建的主题 问与答 网页如何做到禁止 F12 和右键的?
没啥好嘲笑的,小白这东西,拦一个是一个。

小白如果自己愿意上网查找答案,发现原来可以轻松破解,那也是好事,那意味着小白也多少学到了一点点新东西。

所以其实拦的不是小白,是某种意义上的伸手党,F12 一按就想抄。同样都是小白,能自己找寻破解方法和不愿意找的还是不一样的。
17 天前
回复了 huangdayu 创建的主题 程序员 你的编程启蒙老师是谁?
aveline
17 天前
回复了 hugee 创建的主题 PHP PHP 高并发 统计网页点击次数
朋友,我觉得真的高并发的话,可能你的问题首先不是出在 MySQL 上,而是 php-fpm 上……

当然我不知道你怎么部署的,如果真的若干机器堆住,一般 hold 住也没问题,当然真是这样的话那 Redis 啥的也不算事了。

毕竟不知道你的高并发首先有多高 - -#
25 天前
回复了 iacyl 创建的主题 全球工单系统 豆瓣又又又挂了?
切 CDN 是因为被 D 了么。。。
买,不要犹豫。
家里又不是没有这个条件。
32 天前
回复了 chaleaochexist 创建的主题 程序员 请教,rest api 的设计问题,关于粒度.
@guijianshi01 哈哈哈,理解理解,我就这么过来的。我的做法不敢说是完美,也是一个一个坑才过来的血泪史。

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

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

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

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

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

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

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

说到底啊,这行业的业务变化啊,太快了。。唉,做的累。
33 天前
回复了 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,就注定没有好的工程化的基因)。

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

当然这里面我还有个出发点,是为了三年战略中,逐渐引入 Java 或者 Go 开发人员和目前的 PHP 栈混用,这时候通过接口通信的模块化意义就更大了,这是和我司实际情况有关。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   853 人在线   最高记录 4385   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 15ms · UTC 19:47 · PVG 03:47 · LAX 12:47 · JFK 15:47
♥ Do have faith in what you're doing.
沪ICP备16043287号-1