IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

十种更好的表达“你的代码写的很烂”的方法

外刊IT评论 2013-11-19 23:20:30 累计浏览 4,065 次
本机暂存

   如果你有一个同事,他写的程序与其说是代码,不如说更像希腊神话中女妖美杜莎的头发,你当然不能熟视无睹,你应该做出一些反应,但你可选的合适的反应方式并没有多少:自己默默的帮他整理清楚、向上级抱怨、向其他同事背后唠叨此事、闷在心里直到憋不住,或者这最大胆的方法:走上去直接对烂程序员说他的代码很烂。

   working1

   事实上,这最大胆的方法其实也是最好的方法。大多时候,你可以做的巧妙些,从而避免由此引起的感情伤害或引发咆哮比赛。就像一句古话:只要方式正确,你可以向一个人说任何话。

   当然,找到这正确的方式并不是轻而易举的事情。为了方法大家行事,下面是10种让你的表达更具技巧性的好方法。

  • 开门见山:告诉他你看不懂他写的代码,并追加一些像这样的话:“我需要你帮我理解这块代码”——这是“硅谷iOS程序员研讨会”组织者、软件程序员Tim Burks的话。

  • 推心置腹:约他出去喝两瓶啤酒,麻痹他的抵抗情绪,先从讨论编码风格说起。你会发现,他之所以这样写代码是因为这样他很方便——而不是方便开发团队。通过讨论代码不仅仅是人和机器交流的工具,更重要的是通过代码的人和人的交流,你可以让他用一种全新的思维来认识代码。

  • 高山仰止:如果你的同事敬重你,想必他也会敬仰或效仿你所敬仰的著名程序员。所以,跟他讲那些杰出程序员的故事。或者向他转述Burks的观察所得:杰出的程序员总能把自己的编码风格融入到他人的风格中。

  • 一针见血:Adobe System研究实验室的领袖人物Tom Jacobs说,“为了格式而格式化代码毫无意义,但将调整代码格式作为重构工作的一部分,增加新功能、修改bug工作的一部分,那是很正常的,因为这样做本质的增加了代码的质量。”

  • 反馈问题,而不是批评:心理学家Leon Seltzer在“当代心理学”上的一篇博客中说,“人们更喜欢接受反馈信息而不是批评——即使是负面反馈”。所以,以反馈问题的形式诉说问题。

  • 以后改进:不要苛求当前的工作,而是要求日后对此改进提高。按这种思路,你可以说:“嗨,下一次,如果你能把每个方法的行数减到10行以下,那会更好。”这比说“你的代码一塌糊涂”要中听的多。

  • 糖衣炮弹:封装你的批评,在表达“你的代码很烂”的意思前和后先恭维一番。

  • 偷换概念:如果交谈中总是说你、你、你,这很容易引起敌意,就好象你在指控罪名。所以,不如换种方式,与其说“每次都让我为你写的代码擦屁股”,不如说“有时候我真感到很沮丧,因为需要重你的代码。”

  • 引蛇出洞:这种办法稍微有些麻烦,但不失为一种以守为攻的好办法。组织一些编程大赛之类的活动。如果顺利的话,它能引出一场安全的、没有猜疑的关于如何提高你的同事的代码质量的讨论。

同分类推荐文章

  1. 科技爱好者周刊(第 401 期):如何赚到10亿美元 (2026-06-26 08:05:38)
  2. 如何做决策 - 从 Go 的一个 issue 说起 (2026-06-26 08:00:00)
  3. Seven Player:Windows上播放115网盘视频的增强工具 (2026-06-09 00:06:47)

查看更多 开发者 文章 →

建议继续学习

  1. 面向“接口”编程和面向“实现”编程 (累计阅读 13,909)
  2. 谷歌是如何做代码审查的 (累计阅读 6,664)
  3. 我自己研究开源项目源代码的两个重要习惯 (累计阅读 5,972)
  4. 抵制代码重写 (累计阅读 5,528)
  5. 从Code Review 谈如何做技术 (累计阅读 5,216)
  6. 设计模式原则总结 (累计阅读 5,178)
  7. 如何避免重构带来的危险 (累计阅读 4,637)
  8. 什么是重构,什么不是重构 (累计阅读 4,614)
  9. 代码审查:ThoughtBot官方给出的代码审查指导原则 (累计阅读 4,532)
  10. 面向对象设计模式的核心法则 (累计阅读 4,519)