代码,写的复杂点还是简单点?
2023-03-20 15:33:27 时间
先说下个人”暴论“,肯定是简单好。
为什么这么说,我们先从事物的本质来看。任何学术研究,科普文章,都是试图将一件复杂或困难的事情简单化。复杂的知识点通俗易懂得讲给学生听,你就是一位好老师了。同样复杂的系统功能,用浅显易懂的代码实现,你就是一位好的程序员。
这会儿肯定有同学会问了,“我司有个老员工,整个项目只有他一个人能看懂,能修改,别人根本没办法下手”。 这种已经发生的,不在咱们的讨论范围内。不过我们可以讨论一下,为什么项目会变得这么复杂。大概有以下几种原因
1、可能项目人员参差不齐,可能从需求侧就是有问题的。毕竟很多产品经理,在设计功能的时候,并不会考虑功能以后的扩展性。甚至,是直接借鉴友商的升级,稍加改改。
2、程序员的能力有限,或者说,在写代码的时候,并不会考虑扩展性,功能上线了,能跑就行,后续有问题,直接在代码上打补丁。函数的入参由一两个,变成多个,执行逻辑,变成if,else 各种堆叠。
代码之所以写成这样,是因为从代码层面来说,没有一个即时的负反馈,刚开始没人会意识到,这是一个问题,但是随着产品功能的迭代,慢慢才会被人发现,可能是已经无法维护了,或出现bug无法修复了,拆东墙补西墙。这个时候,可能最初开发功能的程序员都已经跑路了。他们没有意识到“防微杜渐”才是解决这类问题的根本手段。所以为了防范这类问题,市面上有很多软件工程,设计模式,代码规范之类的基础思想(这块咱们后面也可以展开聊一下)。
3、在有限的工期下,为了快速迭代,只能保交付,牺牲一部分质量。但如果一直牺牲质量,慢慢技术债会越积越多,代码腐坏,最终形成不可维护的项目。
但是,”代码的生命力“是一个不可控的伪命题。很多年头很长的项目,最终的归宿是彻底重制,而不是迭代更新。可能从公司层面来说,高层决定换一个产品或者系统。
复杂度不会消失只会转移
说回程序员本身。个人认为优秀的实用型程序员的职业素养之一,就是不断在有限的开发时间和优雅的代码实现之间找到一个平衡点。你可以用各种设计模式,基础思想,但你得找好平衡点。三天后有个功能需紧急交付,你给我整DDD,六边形架构,那人家可能觉得你不靠谱。
相关文章
- 在 Podman 中运行一个 Linux 虚拟机
- 使用Windows 11系统,磁盘管理调整分区怎么操作?Windows 11磁盘分区方法
- Linux设备树的传递以及Kernel中对设备树的解析
- 微软自家的Linux发行版开源了!
- Linux基础之查看、添加、修改、删除用户
- 微软Windows 10 Build 19043.1151(KB5004296)发布:修复游戏模式负优化等Bug
- Windows系统中,如何读写临时文件
- 如何开机自动登录Windows 8系统
- Linux 内核终于可以 Debug 了!
- Windows 11微软商店大进化:全新UI&性能提升
- 系统小技巧:解密Windows 10图标上的相对蓝箭头
- Linux 上的六大安卓模拟器
- 7个改变我生活的Git小技巧
- 苹果 iOS/iPadOS 15、macOS 12、watchOS 8 公测版 Beta 4 更新发布
- HarmonyOS《鸿蒙操作系统开发入门经典》|线程管理|剪贴板
- 服务器该选择Windows系统还是Linux系统?
- Windows 10总强制更新?教你简单4步彻底关闭!几分钟就能搞定
- 谈一谈Windows中的堆
- 因为 Windows 原生不好用,我给你找了这些第三方软件
- Windows 11将沿用Windows 10升级模式 并会有LTSC版本