• 包含许多级别的嵌套块 ， 如if-else语句、循环： 开发人员经常使用像if-else语句、循环这样的嵌套块来快速获得想要的结果 。 而当程序编译成功后 ， 开发人员却忘了优化程序 。

示例：

anchors foreach{ anchor => if(anchor.hasAttr( "href")) {val href = https://www.sohu.com/a/anchor.attr("href")val next= completeUrl(href)println( next)if(next.contains(domain) && !roadMap.contains(url) && !next.contains( "/email-protection#")) {roadMap.add( next)if(process( next)) {println(f "processed $next")Thread.sleep( sleep)} else{println(f "skip $next")} } else{println(f "skip $next")} } }

• 命名不当的方法和变量：为了节省时间 ， 开发人员经常会使用变量/方法名 ， 如X、Y、Z或ABC 。 这种做法很不好 ， 因为开发者当下可能记得它们的作用 ， 说不定过几天更新相同一段代码时就忘了 。 如果换做其他人 ， 那就更不懂它们的含义了 。

示例：

x= "abdon" y= 314 z= 151 r= f(x).f2(y).f3(z)

• 不必要的代码注释： 写注释是一个很好的习惯 ， 但写的时候要分得清主次 。 如果添加太多 ， 很容易会让读者跳过每一条注释 ， 这就会造成重要注释被忽略的情况 。

示例：

// 注释 classFoo{// yun xing cheng xu publicvoidrun( ) {// 调用 foo foo(args); // 调用 abc(args); // 判断返回值 if(exists(efg(c))){foo(x); } else{// 打折 dazhe(efg(d)); } } } 以上示例代码由刘鑫提供
烂代码的危害
“代码写的太烂怎么办？” ， “没关系 ， 程序和人有一个能跑就行 。 ”有人说 ， 写代码是为了交差 ， 在需求着急上线的时候 ， 代码的质量就无法保证了 。 那事实真的是如此吗？答案肯定是：“No”
要知道 ， 程序员写代码是为了解决问题 ， 而不是单纯为了完成任务 。 低质量的代码就像是有问题的车 ， 虽然还可以跑 ， 但是需要不断维护 ， 不然随时有可能无法启动 。 想必很多程序员面对自己的代码时都觉得 ， 世界上最简洁易懂的 ， 是自己刚写出来的代码；而世界上最烂的代码 ， 则是自己一年前写出来的 。
烂代码表面上看可以满足实际操作 ， 但从长远的角度来看 ， 它们很有可能成为一颗“定时炸弹” 。 因为烂代码一旦出现问题 ， 面临的就是：
1.需要大量的时间和金钱来修改 ， 成本会随着时间的推移而增加；
2.很难或无法增加新功能；
3.无法预测哪里以及何时会停止工作；
4.对开发人员的积极性有负面影响……
最坏的结果就是 ， 烂代码可能导致项目报废 。
专家分享解决之道
针对这个问题 ， 微博认证为前微软Asp.Net最有价值专家、互联网科技博主的网友@宝玉xp ， 发布了一条长微博 ， 分享了他在解决团队烂代码问题上的干货内容 。

文章图片

截图自@宝玉xp微博
他认为 ， 当系统到处都是烂代码时 ， 那就要思考更深层次的原因了 。 是不是需求太奇葩？进度太赶？没有设计？或者多个因素在一起？
关于这些问题 ， 他和团队做了以下的努力：

• 代码审查 。 所有更新的代码都先在分支开发 ， 合并到主干前要代码审查 。 审查的部分工作要靠工具配合 ， 运用自动化测试 。
  • 上一页
  • 1
  • 2
  • 3
  • 下一页

  特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。