如何写出优雅的代码

·  阅读 1932
原文链接: mp.weixin.qq.com

  引言

中秋假期期间刷爆朋友圈的某篇10w+里,标题赫然写着“因代码不规范,码农枪杀...”,其实上周五我就爬墙看了英文原文报道,报道中只是说在软件公司发生枪击案,警方只是宣布作案动机不明,案情还待进一步调查。然后国内技术圈一些自媒体强行蹭热点,纷纷以“代码不规范,码农枪杀...”为题发文,甚至一些主流媒体如CSDN也不要职业操守跟风转发,既然代码规范能引起这么大的共鸣,那么今天我们谈谈一个程序员的自我修养:如何写出优雅的代码?

Martin(Bob大叔)曾在《代码整洁之道》一书中说:当你的代码在做 Code Review 时,审查者要是愤怒地吼道:

“What the fuck, is this shit?”

“Dude, What the fuck!”

等言辞激烈的词语时,那说明你写的代码是 Bad Code,如果审查者只是漫不经心的吐出几个:

“What the fuck?”

那说明你写的是 Good Code。衡量代码质量的唯一标准就是每分钟骂出“WTF” 的频率。

\

  代码不规范会有哪些痛点?

1. 影响团队合作,降低效率:对于共同完成项目的团队而言,如果没有统一的代码规范,最终整合代码时,可能会出现看不懂命名,或者阅读过程不断询问的情况,导致团队效率低下,甚至造成成员之间的矛盾;例如 git push -f,把别人的劳动成果全部覆盖掉,出现一次就会遭到全员围攻,猪队友啊;

2. 提高维护成本:代码不规范导致可读性降低,后期的代码维护会耗费更多人力甚至财力成本;一旦代码越来越多,最后的维护就难以为继,给运维人员造成很大负担;

3. 引发各种 bug:如果输入输出参数、异常处理、日志处理等没有规范,很容易导致大量低级 bug,还很难找到 bug 的原因;

4. 不利于代码审查,甚至造成安全漏洞:代码审查是纠正代码错误,保证开发周期安全顺利进行的重要一步。如果代码不规范,就会加重代码审查的工作量和难度,导致代码审查工作没有根据还浪费时间。某些情况下,代码不规范还会造成安全漏洞,此前 Morpheus 智能合约爆出的重大安全漏洞,就是大小写错误造成的;

5. 不利于程序员自身的成长:有些人可能没有意识到代码规范的重要性,有些人意识到了但由于项目时间紧、流程繁琐等原因而不去遵循。这跟当前开发流程与安全之间的关系很像。很多人为了速度而牺牲前期的必要流程,却给后续的工作带来了更多麻烦。其实,规范的代码有助于理解开发语言、模式和架构,也有利于提升开发水平。

艹,哪个傻逼写的代码,一看注释,author是自己,如漫画穿越回多年前让自己并不现实,如果你发现你之前的代码很low逼,说明你已经进步了,那么如何写出优雅的代码?

  如何写出优雅的代码?

1. 采用规范

每种语言都有自己的推荐风格,如Swfit最近有Google Swift Style Guide。显然OC与Swift有着不同的风格。当我们开始写Swift,首先要注意的就是按照Swift的风格写,而不是沿用OC的风格,组内应该形成一种公认统一风格以便于后期维护。

从规范目标细节的角度,代码规范分为:

注释

命名

缩进空格

语句格式

规模

可靠性

语言特殊项

2.  Code Review

一份优雅、干净、整洁的代码通常自带文档和注释属性,读代码即是读作者的思路。我们在Review的过程中会发现很多不够优雅的代码,命名不规范者or影响性能,甚至存在致命bug。那么如何在团队内推行Code Review呢,老峰分享下我们组内目前采用的形式。我们团队内部采用Gitlab工具,在开始一个新的迭代后,每个同事为自己负责的模块建立一个独立分支,各自在自己独立的分支完成开发,功能开发完成后,在Gitlab提交Merge Request,如果与其他同事模块有依赖,或者业务较为复杂,可分为小的功能点多次提交;负责Code Review同事review的时候应该先让提交者讲一下大概设计的思路,在gitlab中指出存在优化的点,待提交者修完完毕后再将该分支合入主干分支,引入Code Review的机制在一定程度上可以提升团队内代码质量,也可以减少低级bug的出现,对组内交叉熟悉彼此业务也有好处。

3.  Code Lint

可能尽管我们推行了统一的代码规范,也进行了CodeReview,我们会发现只要团队成员足够多,每位成员都有不同的背景,纯靠人肉难免依然有不规范的代码存在,那么这个时候就应该采用Code Lint了,每种语言应该都有自己的编译器对应的插件,以iOS为例有SwiftLint ,ocLint,这里我简单介绍下我们团队内部使用的SwiftLint。

SwiftLint可以看作是一个Xcode插件,基于Sourcekit & Clang AST的应用(Sourcekit & Clang AST这里不做过多介绍),通过语法规范检查,可以在编译期将所有不符合Swift规范的代码全部用warning标注出来,一些严重的违背规则的代码甚至让它无法通过编译(万里江山一片黄)。

SwiftLint安装很方便Homebrew brew install swiftlint即可安装好,然后为Xcode添加Run Script Phase

接下来编译,就可以看到99+ warning(如下图所示),请不要惊慌,我们可以使用swiftlint autocorrect自动解决部分警告,也可以通过.swiftlint.yml配置符合团队规范的规则,通过编译器检查规范比人肉检查更加准确高效细致,团队内部也可以做到高度统一的 Code Style。

4. 阅读学习交流分享

总结绝大多数开发者的日常,对新功能开发的迫切远远大于重构一个旧的功能,导致很多代码都没有很好的版本迭代,慢慢的,破旧/破损的模块让人觉得似乎无人照管,于是别人也不再关心,最终自己也参与破坏活动,走上一条打补丁的不归路。

其实从一开始,我们就应该抱着一种重视自己的代码的态度来写代码,而不是想着先完成功能,以后再来重构优化,代码如生活:稍后就等于永不。如何保持代码整洁,离不开设计模式和代码重构,多阅读开源社区的代码,比如最近微信开源的MMKV就可以读来学习,像世界同行大佬学习交流如何优雅的写代码,也可以读一些经典的书籍如《代码整洁之道》,《重构 改善既有代码的设计》,《重构 改善既有代码的设计》这本书在之前的文章中提过,今天推荐一下《代码整洁之道》。

《代码整洁之道》讲述了一系列行对整洁代码之有效的最佳实践。软件质量,不但依赖于架构及设计,而且与代码质量紧密相关。这一点,无论是敏捷开发流派还是传统开发流派,都有统一的认识。《代码整洁之道》提出一种观念:代码质量与其整洁度成正比。干净的代码,既在质量上较为可靠,也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者,这些实践在《代码整洁之道》中体现为一条条规则(或称“启示”),并辅以项目实例的正、反两面的范例。只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量。

公众号后台回复【编程之道】即可获得电子版,建议读者朋友购买纸质版阅读,支持正版,支持原创。

更多骚操作,尽在iOSTips,关注公众号,第一时间get新姿势

分类:
iOS
标签:
收藏成功!
已添加到「」, 点击更改