怎样读一份烂代码

当看过一份杂乱无章的代码后,才知道代码有条理是多么重要,阅读一份条理清晰的代码是多么赏心悦目的事。

最近接手了一份代码,看到后惊呆了,300个使用 ASIHTTPRequest 发起请求的方法散落在 100 个 ViewController 文件中,最大的一个类竟然有一万行代码!变量名有拼音缩写,有的像 btn1 bnt2 这样,不知作用,资源文件随意放置于各个模块的文件夹里,三方库没有标明版本,也没有标明有没有修改过,我想,大概只有神才可能驾驭这样一份代码吧。

以上是牢骚。

看过这份代码后,想了下怎样才能写出这样的代码?整个项目透露着一股随意而为的气息,开发者在写代码的时候大概从没有想过以后怎样维护吧。一谓的赶进度,最后进度赶上了,出现了各种各样的 Bug,进度又越来越慢,问题越来越多,维护成本高到天际,这就是当初想的「快」吗?问题是,当时写的是挺快的,想发一个请求,随手写一个方法,业务逻辑中调用一下,多简单,最后呢,如果这个库出问题了,需要升级或者替换成其他的库,还快得起来吗?

最近还有一个事,Yep iOS App 完全开源了,对比一下 Yep 中对以上几个槽点的处理,明显的感觉到,一个正常的代码结构看起来是多么的好看,多么的舒服。对一网络请求的简单封装,对后续可能的升级提供了很大的方便,把复杂的类拆分,功能单一,不臃肿,对看代码的人也没有什么负担。三方库统一用 CocoaPods 管理,有修改过或者自定义的三方库换手动配置。变量名文件名命名风格统一,缩进风格统一,这些简简单单的事放到一起,成就一个正常的项目的顺利开发和低成本维护,多好。

愿这样写代码的同行们在写代码的时候三思,考虑一下后续维护的成本,愿天下没有烂代码。

– EOF –

Built with Hugo
Theme Stack designed by Jimmy