V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lewis89  ›  全部回复第 1 页 / 共 83 页
回复总数  1643
1  2  3  4  5  6  7  8  9  10 ... 83  
@gBurnX HDD 能比 SSD 便宜多少,这点设备开支 占大部分创业公司程序员的工资支出的零头不到.. 别在这里讨论这个了..
怪就怪厨子吧,设计的什么傻逼电脑 要插一堆外设,自家的外设又卖的死贵,

我的 mbp 就烧过 一次,不过我用的扩展坞型号太多 小米 绿联 XXLink 一大堆,就图个便宜,反正我也不知道有哪个口为什么被烧了,只能充电,不能通讯
感觉没啥必要,SpringBoot 本来面向的就是企业级开发,不是做成这种小打小闹的玩具给没有什么运维能力的客户用的。
48 天前
回复了 howtodie 创建的主题 职场话题 51 上班被调休了,还有三倍工资吗?
@efaun 只能在梦中的中国实现了
这个是全资子公司,貌似跟总部的待遇不一样吧..
57 天前
回复了 ccde8259 创建的主题 程序员 看着市面上大量 Go 岗,如何调整心态?
@rpish 拿 Java 写了这么多年的事物脚本,连 oop 长啥样都忘光了
57 天前
回复了 daqin 创建的主题 MySQL 索引重复了?
重复了,联合索引能够满足第一个索引的所有功能
说实话,找 教职 or 考公 吧,没有更多的出路,不建议来 IT 卷

转码写业务的话,基本上 211 985 硕士就到顶了,小公司还不用招这么高学历的,
一般互联网公司 20-30 万 随便能招一堆 既能吃苦又耐操的 996 拼命老哥来,
你这学历中小人公司都不敢招你来写业务。

大公司的业务开发岗位还可以看看,但是又浪费了你这学历,而且大厂也很卷也看年龄,
年纪到了你没升到一定职位也比较难混。

算法的话,说实话 传统的 leetcode 算法题目 其实跟人工智能那些算法是完全两回事,
后者大多都是跟数学以及概率统计学相关,跟传统算法 or 数据结构里面 增删查改 其实没什么太大关系,
以 SVM 为例,你至少要懂函数 导数 以及凸优化 才能做出好的 SVM 分类算法模型,
深度学习相关的算法那就更跟传统的 leetcode 上面的题目的算法是完全两回事了..

如果你数学能力不强的话,那么去了这些做算法的公司 很大可能就是调参当个调包侠,
当然如果你在业务领域有相关专业优势跟领域知识的话,那么还是很有发展前景的,
但是这种工作其实本质上已经更偏向算法应用跟产品经理这样的角色,
对实际编写代码的能力要求不强,对应领域的知识需要很强的理解能力,
这个时候你就要看你的领域知识能不能给你构建强大的专业壁垒,否则做这种偏算法应用的工作还不如做业务开发
69 天前
回复了 Kasumi20 创建的主题 程序员 准备从 Go 和 Rust 二选一,求建议
@cassyfar #38 用还是有场景用的,吃了不少原 C++的市场份额,毕竟 C++历史槽点太多,而且所有权管理机制也保证了小白也能写出内存安全的代码出来,关键是大部分场景并没有实时性需求,除了底层的数据库 高频交易 又或者是嵌入式实时设备之类的这些场景,其余 99.9%的场景 没有实时性需求,没有实时性需求,意味着不用 GC 就是脑子有病,让猿猴去管理内存,还不如相信 GC
69 天前
回复了 Kasumi20 创建的主题 程序员 准备从 Go 和 Rust 二选一,求建议
没有实时性需求的场景一律选带 GC 的语言,Rust 的所有权以及生命周期管理机制太麻烦了..
69 天前
回复了 luwill 创建的主题 职场话题 聊聊大厂面试一次不过,次次不过?
卧槽,你这个头像很像我 美团第四面的面试官,不过我已经挂了
人月神话里面其实早就指出了,软件开发的困难分为两个

1. 非本质性困难
例如 CAP 高并发系统设计 这些都是非本质困难,随着技术进步这些困难早晚都会被解决掉,例如
阿里的 seata 就在解决分布式系统中的分布式事务问题 提供 TCC SAGA 等方案,而这些方案随着技术成熟,未来会越来越对业务层透明,
另外随着一些中间件的成熟,实现可靠消息队列也将不再成为难题,业务层面上不用再需要考虑幂等 消息丢失 异常处理之类的,只要考虑业务上如何设计妥协,因为异步消息系统存在上下文丢失的问题。

在汇编时代,程序员需要自己手动管理栈,在 C 语言时代,程序员需要自己手动管理堆内存,在 C++时代,程序员需要关注 RAII 跟循环引用以及智能指针的引用计数回收模型,在 Java 时代,程序员总算从内存管理中解放出来了,只需要关注业务逻辑了

2. 本质性困难

大型系统的概念完整性以及单个系统模块复杂度失控的问题,如果你的系统只是几十个 CRUD 接口,那么你大可不必 费尽周折来设计系统,因为这样的系统,大概 1-2 年后就会被重写,即使重写损失也不大,所以像 DDD 这种设计哲学跟理念,它只能被用在大型系统中,例如像阿里这样的公司,你很难在上百个业务开发团队 建立一个共通的概念模型,例如一个淘宝用户,在各个业务团队中,它所呈现的概念是完全不一样的,只有这样的大系统才有应用 DDD 的价值跟需求
去看项目代码没有任何意义,领域驱动设计其实都是吸收了现有的软件开发原则例如 SOLID DRY

例如六边形架构 其实就是接口隔离原则,它提倡高层次的业务逻辑不要跟低层次技术细节代码耦合,
两者都要依赖接口,例如发送消息到消息队列,从业务层面上来看应该抽象出一个接口,
至于具体怎么发不应该依赖具体的实现例如 kafka 跟 rabbitMQ,这样以后你更换消息中间件不需要改写业务代码,
但是实际上在 CRUD boy 的眼中,耦合什么的都不是问题.. 反正就是 Controller 捅到 Service 跟 DAO 一把梭

例如共享内核跟界限上下文 其实本质上的核心思想就是单一职责原则跟适配器模式,如果你在大型系统中建模,
总想用一个模型概念去解决所有的领域问题,那么你的模型概念就难以理解,
以我上家为例,我们实践 DDD 做了一套护士教育考试系统,但是有的医院硬是要塞进去一个护士排班系统,
这样在建模的时候 就要应用共享内核,

在考试系统上下文我们关心的是护士的职业级别,因为根据一些公立医院的规则
护士通过考试,应该在批准后得到晋升,这样在这个上下文我们关注的是护士的 职业等级相关的属性

在排班系统上下文,我们关注的是护士的工作时长,护士的请假,医院的排班规则等

如果你想建一个大一统的护士模型,那么对不起,这个护士模型没有任何人能理解透,这还是两个系统,
如果再涉及到医院护士 护士长等审批流程系统之类的,那么这个模型的职责会大到你难以理解。

所以共享内核跟界限上下文的根本思想就是 单一职责原则,做开发如果有多年经验的,一般都会把注意力放在建模跟概念最小完整性,这样的系统会更容易维护,至于填空写 CRUD 的人,招几个 2-3 年的年轻人就行了。
1  2  3  4  5  6  7  8  9  10 ... 83  
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1528 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 00:16 · PVG 08:16 · LAX 17:16 · JFK 20:16
♥ Do have faith in what you're doing.