V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  dwlovelife  ›  全部回复第 11 页 / 共 13 页
回复总数  248
1 ... 3  4  5  6  7  8  9  10  11  12 ... 13  
2021-11-24 15:01:13 +08:00
回复了 beyoung 创建的主题 程序员 从程序员到经营温泉度假酒店(二)- 项目筹划
老哥 两千万是怎么筹措的?自己投了多少?借了多少?看 LZ 这前女友和现任老婆的背景 感觉 LZ 也是大家大户呀。作为一个屌丝程序员的疑问,一个月薪 1W 的前端怎么能傍上这种富婆
2021-11-17 21:01:37 +08:00
回复了 uSy62nMkdH 创建的主题 职场话题 一线回到二线一年多,有点迷茫,求指点。
@littlemcdull 京东 9 点上班
2021-10-09 09:47:53 +08:00
回复了 liuidetmks 创建的主题 程序员 各位 v 友,帮忙看看这个思路对不?
这样优化是为了提高一点人都感觉不到的效率么,为啥子不是想着优化复用性呢。
2021-09-28 18:24:26 +08:00
回复了 itechnology 创建的主题 程序员 微服务怎么划分才算是正确的?是越细越好吗?
再多说一句百分之 80 的软件公司不需要微服务,因为量根本不是那么容易你想上去就上去的,这玩意很多都是程序员要么脑补 要么为了练手。
2021-09-28 18:21:37 +08:00
回复了 itechnology 创建的主题 程序员 微服务怎么划分才算是正确的?是越细越好吗?
所以你看微服务的出现从来就不是为了拆而拆的,它是业务带动的,按我说就楼主所说的业务场景,说实话用单机就够了,为什么?因为成本。所以说我个人认为你们的架构师很不专业。
2021-09-28 18:19:21 +08:00
回复了 itechnology 创建的主题 程序员 微服务怎么划分才算是正确的?是越细越好吗?
微服务的出现,一开始之所以要拆,从来不是一开始就因为技术原因拆的,是业务的发展的带动,导致从技术场景上而言不拆不行了。我所见到的能称的上所谓微服务的(不是那种自己跟自己玩,把业务模块拆几个 module )。拿电商来说,通常情况下一个服务就基本对应一个部门(这里想表达服务是一个很大的概念不是那么简单的一件事),拿结算提单来说把,最前面的是交易中心(下单的时候跳结算页发起下单流程就是它干的),结算的时候结算页这个页面支付操作一般会有一个支付部门干(提供的就是支付服务),完成支付后,会进行对账(入和出是否平) [财务系统] ,财务系统完成了之后还会有订单中心(订单系统)修改订单状态.........
2021-09-27 19:52:41 +08:00
回复了 JadePenG 创建的主题 程序员 公司选择!求分析
现在 在京东 之前在的两家公司 前东家都说上市 有一家疫情期间有一个月还没发工资 拖了第二个月然后缓过来补发的 上市就是大饼 况且上市跟你没有什么关系 外包就更别去了 建议再找找不行 选正编的
2021-09-27 15:29:52 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@leeg810312 我所说的一直是基于现有的运输能力和算力水平更好的服务用户
2021-09-27 15:27:40 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@leeg810312 可能你觉得站着吃饭和跪着吃饭没什么区别,只要吃到饭就好。是不是互联网产品根本不重要,产品是服务用户的,用户体验好不好都不重要,那就没什么重要的,照你的思路以后火车上有没有位置也不重要能把你送回家就行。
2021-09-27 10:38:40 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@ersic 对啊 每个人都有
2021-09-26 20:50:42 +08:00
回复了 liuidetmks 创建的主题 Java Java 加一个字段很难吗?
楼主你说的这种后台的入参在确实不确定的情况下,完全适应入参,只能采用 map 结构去接收,但是确确实实违法规范,即使使用 map 接受,你每进行一次业务变更添加或者修改一个字段(可能很频繁),后台是一点业务逻辑不需要处理么,那应该不现实,但凡有逻辑要处理用 map 和不用 map 那已经不重要了,因为无非是改一个地方还是改好多地方的问题,但是某些业务场景还是有方案去解决的,单纯的透传后端可能通过使用 map 去兼容你,但是如果大部分字段都和业务紧密相关需要做额外业务操作,那么用 map 和不用 map 没啥大区别
2021-09-26 20:44:25 +08:00
回复了 liuidetmks 创建的主题 Java Java 加一个字段很难吗?
@Macolor21 groovy 也只不过是一种跑在 JVM 之上的语言,简化了语法,算个动态语言,但是像楼主说的这种接口字段从头到尾自适应,不是语言的问题,这是设计方面的问题
2021-09-26 20:13:18 +08:00
回复了 sadfQED2 创建的主题 程序员 有加班处理个保法整改的老哥吗?你们方案是怎样的?
想的太简单了 如果都这样玩 工信部岂不是一点威信没有 你最起码 明面上不能被看出来 也就是前端页面数据埋点和前端请求这一层
2021-09-26 18:29:46 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@dqzcwxb 说你是"正义"你就是了呗,我捉摸不透现有的规则(因为 12306 对我是黑盒对你可能不是),劳烦您给我科普一下所谓现有的规则,我也好学习学习。最早显示说明是可行的,取消了说明,因为各种考量不管是铁路总局的利益还是什么。但是说明从技术角度是可以显示的。能不能回去我不知道,但是说实话我个人从用户体验度而言,最初那版的体验我个人认为更好,虽然 12306 并不会考虑我个人的体验,但是每个人都有发声的权利。
2021-09-26 17:48:03 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@HappyFox s 个产品经理祭天就是个玩笑话 之前搜狐还是暴风的 APP 更新出来的梗
2021-09-26 15:52:27 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@dqzcwxb 你就是用你那一点点所谓的知识,到处宣扬你所谓的正义,所谓的最优方案就是当前方案,别人的意见就是这不行那不行了,我除了想笑就是想笑,要是国家上面要求了显示人数,你信不信能给你改回来,估计到时候又说显示人数真香了
2021-09-26 15:49:39 +08:00
回复了 dwlovelife 创建的主题 程序员 12306 的候补机制感觉越活越回去了
@dqzcwxb 规则并不一定要跟 ip 绑定 OK,我能限制平台不,我能限制每个账户只能在 12306 进行候补操作不,候补人数跟老人小孩有半毛钱关系不,你自己想不到完整的规则,哇这方案就是最好的,哇你这么干有这些问题那些问题,靠人要后续改版了,估计你又是一副嘴脸
1 ... 3  4  5  6  7  8  9  10  11  12 ... 13  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   963 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 20:03 · PVG 04:03 · LAX 12:03 · JFK 15:03
Developed with CodeLauncher
♥ Do have faith in what you're doing.