在公司写代码是工作,在开源社区写代码是生活

大家好我是五阳

在公司写代码是工作,在开源社区写代码是生活,工作为了糊口,生活是为了快乐。

我相信各位读者一定非常认可这句话:公司里的代码就像是一座又一座的屎山,绵延不绝,一眼望不到头,无论怎么翻也翻不过去。

程序员在面对这些屎山时,优质的想法是我要重构,成熟的做法是继续堆shi,智勇双全者的做法是:在旁边重新建个系统替换它,然而过了一年半载以后又是一座屎山,不断往复循环~ 人员流动越频繁的系统这种现象越严重

你很难从这些狮山代码中找到乐趣,而开源系统的维护相比前者,要幸福的多。

公司的系统非常烂

无论有多少种领域建模方法论,我相信按照经验进行领域建模一定是最有效,也是最为常用的办法论。

在业务初期,系统建设者对于业务理解不足,系统设计经验也不足,设计的系统很难预料到未来的业务发展。然而项目初期,对需求的交付效率又有变态的诉求,产品经理和老板往往要求系统越早上线越好~ 结果是系统架构设计前瞻性不够,代码质量一言难尽。

重构的挑战

在业务需求面前,技术重构永远排在最后面,技术重构的价值很难说清楚~ 但是重构的难度和风险一定巨大。

如果是刚入门的新人,对于技术类重构一定要非常谨慎,它可能不仅仅是你的机会,更是一个火坑。

重构一个系统的难度一定远大于实现同类型的业务需求的难度。对系统的了解不足情况下,重构难于登天。

如果人员流动频繁,重构更是不可能得事情。

开源系统呢?

相比公司内系统,开源系统最大的命门是,连续性不足。公司的系统有老板发钱找程序员维护,它能一直存在,而开源系统绝大部分都是用爱发电,因此很多时候,开源系统没一两年就无人维护了。

我们主要聊长期有人维护的开源系统

开源系统从发起人发起项目到有人在公司内实际应用,再到业界广泛使用,往往需要较长的发酵时间。在这段时间内,发起人对于系统的了解非常熟悉,对于他们来说,重构系统是一件非常容易的事情,大不了推翻重来。

开源系统的维护大部分也没有deadline的要求,维护者可以从容不迫的进行架构设计和代码Review。这就比公司内系统有非常大的优势。

因为时间不足、责任感缺失、不敢担责等因素,公司内系统的维护者往往发现了系统的问题,也不去改进。而开源系统则没有这类困恼。

综合以上因素来看,在业界广泛使用的著名开源系统大部分架构设计和代码质量都要绝对优于公司内系统。

最后,如果欢迎掘友们加入我的开源项目 MemberClub,欢迎关注。

可实现一天时间内搭建一套订单交易系统。 轻量级完全开源的交易引擎,以SDK方式对外提供通用的交易能力,能让开发者像搭积木方式,从0到1,快速构建一个新的电商交易系统!

github: github.com/juejin-wuya...

gitee: gitee.com/juejinwuyan...

相关推荐
代码搬运媛8 小时前
Jest 测试框架详解与实现指南
前端
counterxing9 小时前
我把 Codex 里的 Skills 做成了一个 MCP,还支持分享
前端·agent·ai编程
wangqiaowq9 小时前
windows下nginx的安装
linux·服务器·前端
之歆9 小时前
DAY_12JavaScript DOM 完全指南(二):实战与性能篇
开发语言·前端·javascript·ecmascript
发现一只大呆瓜9 小时前
Vite凭什么这么快?3分钟带你彻底搞懂 Vite 热更新的幕后黑手
前端·面试·vite
Maimai108089 小时前
React如何用 @microsoft/fetch-event-source 落地 SSE:比原生 EventSource 更灵活的实时推送方案
前端·javascript·react.js·microsoft·前端框架·reactjs·webassembly
candyTong10 小时前
Claude Code 的 Edit 工具是怎么工作的
javascript·后端·架构
GetcharZp11 小时前
GitHub 2.4 万 Star!D2 正在重新定义程序员画图方式
后端
kyriewen11 小时前
产品经理把PRD写成“天书”,我用AI半小时重写了一遍,他当场愣住
前端·ai编程·cursor
humcomm12 小时前
元框架的工作原理详解
前端·前端框架