`
zhang_xzhi_xjtu
  • 浏览: 538505 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

开发故事

 
阅读更多
故事1:
这段代码我没有找到被引用的地方,是不是有什么隐秘的用法?
哦,没有的,这段代码没有用了。
没有用了怎么不删掉?
删掉干什么?
不删干什么,你还要改,我还要code review,测试还没有办法对这个改动进行测试。
恩,还是放在那里吧,谁知道那天又会用到了。

那天基本不会到来的,即使到来了,谁又能保证这段代码没有问题呢,到那时,技术变了,业务变了,不是还得一样分析,编码,测试的老一套走完软件开发的流程,才敢上线。由于是存在老代码,反而使人容易放松警惕,产生以前就是这个样子,所以现在也不会错的想法。殊不知,时过境迁,无用的代码其实是躲在系统的阴暗角落中苟延残喘,鬼才知道当下该段代码的质量如何。
退一步讲,代码其实是删不掉的。我们不是有版本控制吗,可以在历史记录里面查找啊。实在你爱惜这段代码,觉得以后可以用到,可以保存在本地做备份啊。
放一堆不用的代码在系统中,要占地方吧,要编译吧,要维护吧,要干扰看代码的程序员的思路吧,要和每个有疑惑的人解释吧,百害而无一利吧。有那么多的时间和精力要浪费在这些无用的东西上,还是干脆点,删了吧。
当然,系统中有时会存在一些大家都不知道用途的代码,也没有人可以肯定该代码不再使用。可以打打日志,钻研一下这些代码,或者在集成环境删掉看看有什么影响。总之,系统中不应该有没有人知道用途的代码存在,如果当下不知道,就要想办法了解该代码的用途,最终结果有二,一是搞清楚了代码的用途,一是代码无用,可以删掉。
故事2:
我做了一个重构,合并了功能相似的两端代码。
你为什么要改啊,代码不是运行的好好的吗?
恩,功能是正常的,但是系统代码有重复,所以合并了代码。
不要没事找事,好好的代码不要乱改,改错了怎么办,还要浪费我的测试时间。

软件质量大致可以划分为两个方面,外在质量和内在质量。
用户可以直接观察到的系统功能是否正常,响应速度是否满意等等,属于外在质量。
冰山之下,用户看不到的,开发关注的,除了外在质量,也关注系统本身内在的质量,如架构是否合理,代码是否优雅等等,既然重复代码是软件质量公认的大敌,能改的还是要改的。勿以善小而不为!
故事3
我感觉这个代码不好。
怎么不好,全部遵守代码规范。

软件开发的光环早已褪去,昔日的荣耀我们没有机会体会到,但是至少我们还是想传承其精神一二。软件开发已经产业化了,但是软件开发仍然是介于工程和艺术之间的一个存在。如果一个简单的代码规范就可以解决一切,那么作为软件行业从业者岂不是太悲哀了。
代码规范只是软件开发最基本的一个要求,某种意义上说,是用来规范不合格的程序员的一个工具。因为要划一条线,必然会错杀一二,请把代码规范作为自己的基本要求,并深刻理解为什么有这些代码规范和其使用场景,而不是把遵守代码规范作为最终目标。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics