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

大家好我是五阳

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

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

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

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

公司的系统非常烂

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

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

重构的挑战

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

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

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

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

开源系统呢?

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

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

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

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

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

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

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

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

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

gitee: gitee.com/juejinwuyan...

相关推荐
weixin_4196583142 分钟前
Spring 的统一功能
java·后端·spring
小许学java1 小时前
Spring AI-流式编程
java·后端·spring·sse·spring ai
canonical_entropy1 小时前
对《DDD本质论》一文的解读
后端·架构·领域驱动设计
码事漫谈2 小时前
我用亲身经历告诉你,为什么程序员千万别不把英语当回事
后端
码事漫谈2 小时前
C++ const 用法全面总结与深度解析
后端
间彧2 小时前
分布式单例模式在微服务架构中的实际应用案例
后端
间彧2 小时前
分布式系统中保证单例唯一性的Java解决方案
后端
间彧2 小时前
为什么避免在单例中保存上下文状态
后端
间彧2 小时前
单例模式防御反射与序列化攻击的意义与实践
后端
@大迁世界2 小时前
Vue 设计模式 实战指南
前端·javascript·vue.js·设计模式·ecmascript