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

大家好我是五阳

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

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

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

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

公司的系统非常烂

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

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

重构的挑战

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

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

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

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

开源系统呢?

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

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

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

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

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

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

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

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

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

gitee: gitee.com/juejinwuyan...

相关推荐
烛阴3 分钟前
自动化测试、前后端mock数据量产利器:Chance.js深度教程
前端·javascript·后端
好好学习O(∩_∩)O8 分钟前
QT6引入QMediaPlaylist类
前端·c++·ffmpeg·前端框架
敲代码的小吉米8 分钟前
前端HTML contenteditable 属性使用指南
前端·html
.生产的驴17 分钟前
SpringCloud 分布式锁Redisson锁的重入性与看门狗机制 高并发 可重入
java·分布式·后端·spring·spring cloud·信息可视化·tomcat
testleaf20 分钟前
React知识点梳理
前端·react.js·typescript
站在风口的猪110820 分钟前
《前端面试题:HTML5、CSS3、ES6新特性》
前端·css3·html5
Xiao_die88821 分钟前
前端八股之CSS
前端·css
攒了一袋星辰33 分钟前
Spring @Autowired自动装配的实现机制
java·后端·spring
我的golang之路果然有问题1 小时前
快速了解GO+ElasticSearch
开发语言·经验分享·笔记·后端·elasticsearch·golang
每天都有好果汁吃1 小时前
基于 react-use 的 useIdle:业务场景下的用户空闲检测解决方案
前端·javascript·react.js