Java背后的故事与初心

编程规范对于团队协作和代码质量至关重要,然而实践中常被忽视,导致沟通效率低下和系统维护困难。文章通过讨论缩进、大括号等编码风格的争议,强调了一致性和可读性的必要性。程序员应避免陷入琐碎的争论,关注系统架构和算法效率的提升,以提高整体效能。
摘要由CSDN通过智能技术生成

别人都说我们是搬砖的码农,但我们知道自己是追求个性的艺术家。也许我们不会过多在意自己的外表和穿着,但在我们不羁的外表下,骨子里追求着代码的美、系统的美,代码规范其实就是一个对程序美的定义。

但是这种美离程序员的生活有些遥远,尽管编码规范的价值在业内有着广泛的共识,在现实中却被否定得一塌糊涂。工程师曾经最引以为豪的代码,因为编码规范的缺失、命名的草率而全面地摧毁了彼此的信任,并严重地制约了相互的高效协同。工程师一边吐槽别人的代码,一边写着被吐槽的代码,频繁的系统重构和心惊胆战的维护似乎成了工作的主旋律。

那么如何走出这种怪圈呢?众所周知,互联网公司的优势在于效率,它是企业核心竞争力。体现在产品开发领域,就是沟通效率和研发效率。对于沟通效率的重要性,可以从程序员三大“编程理念之争”说起:

1.缩进采用空格键,还是Tab键。

  1. if单行语句需要大括号,还是不需要大括号。

3.左大括号不换行,还是单独另起一行。

在美剧《硅谷》中,你也许会记得这样一个经典镜头:主人公Richard与同为程序员的女友分手,理由是两人对缩进方式有着不同的习惯,互相拧巴地鄙视着对方的cody style。Tab键和空格键的争议在现实编程工作中确实存在。《阿里巴巴Java开发手册》(以下简称“《手册》”)明确地支持了4个空格的做法,如果一定要问理由,没有理由,因为能够想出来的理由,就像最坚固的盾一样,总有更加锋利的矛会戳破它。只想说,一致性很重要,无边无际争论的时间成本与最后的收益是成反比的。

if单语句是否需要换行,也是争论不休的话题。相对来说,写过格式缩进类编程语言的开发者,更加习惯于不加大括号。《手册》中明确if/for单行语句必须加大括号,因为单行语句的写法,容易在添加逻辑时引起视觉上的错误判断。此外,if不加大括号还会有局部变量作用域的问题。

左大括号是否单独另起一行?因为Go语言的强制不换行,在这点上,“编程理念之争”的销烟味没有那么浓。如果一定要给一个理由,那么换行的代码可以增加一行,对于按代码行数考核工作量的公司员工,肯定倾向于左大括号前换行。《手册》明确左大括号不换行。

这些理念之争的本质就是自己多年代码习惯生的茧,不愿意对不一样的风格妥协,不愿意为了团队的整体效能提升而委屈自己。其实,很多编程方式客观上没有对错之分,一致性很重要,可读性很重要,团队沟通效率很重要。

有一个理论叫帕金森琐碎定律:一个组织中的成员往往会把过多的精力花费在一些琐碎的争论上。程序员天生需要团队协作,而协作的正能量要放在问题的有效沟通上。个性化应尽量表现在系统架构和算法效率的提升上,而不是在合作规范上进行纠缠不休的讨论、争论,最后没有结论。规范不一,就像下图中的小鸭子和小鸡对话一样,言语不通,一脸囧相。

鸡同鸭讲也恰恰形容了人与人之间沟通的痛点,自说自话,无法达成一致意见。再举个生活中的例子,交通规则靠左行还是靠右行,两者孰好孰坏并不重要,重要的是必须要在统一的方向上通行,表面上限制了自由,但实际上是保障了公众的人身安全。试想,如果没有规定靠右行驶,那样的路况肯定拥堵不堪,险象环生。同样,过分自由随意、天马行空的代码会严重地伤害系统的健康,影响到可扩展性及可维护性。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值