关于代码可维护性的通信

Question

我正在寻找良好的语言或隐喻，与非技术人员(PM、业务发起人和c)讨论代码的可维护性。

特别是，我最近创建了一些一次性的，今晚完成的代码。每个人，包括内部赞助商，都知道我们节省了几个小时，前提是代码将被使用一次，满足即时需要，而不是再次使用。

然后不可避免的是：“嘿，还记得我们做过的那件事吗?让我们再做一次，但是这些微小的变化。”当然，这些微小的更改并不是那么小，尤其是因为代码是以对环境的假设为基础编写的一个很大的程序错误。是的，是的，我知道，首先要避免这个问题。不要写坏代码。把每件事都写下来，就好像它将由别人来维护，或者说，从现在起，我也会这样做。不过，这是个不同的问题。这是在事情发生之后。

那么，对于内部发起人(非技术的)来说，有什么好的比喻可以快速解释为什么代码不是维护或小改动友好的呢？电影背景上的墙壁:那里没有车库，只是一扇门。-或者-门是焊接在这辆车上的。

你怎么描述这个连续体？

我想为我们的团队找到一些条款，这些条款将有助于讨论在前面付出了多少努力，以及这将如何提高可维护性:在“您今晚想要这个还是想要可维护的？”中给出权衡？

(在总结这一点时，我意识到这可能与为非技术涉众定义“可维护性”一样。似乎向非技术类型解释松耦合并不是最好的解决方法。如果你成功地做到了，怎么做到的？)

编辑的答案:就目前而言，我将继续使用建筑建筑隐喻。这将转化为地基的大小和强度：“是的，我们可以在此基础上建造这座建筑，但我们需要对地基进行改造，使其更大，并覆盖正确的区域。”

Answer 1

在向非技术人员解释软件概念时，构造隐喻通常是有用的。

例如，你可以说，“这个代码被陪审团操纵，就像用2x4来支持打开车库门，而不是安装一个合适的车库开门器。”

结构隐喻很好地提供了连续的解释。

Answer 2

在这里尝试这个，一直为我的学生工作:)

带上一包意大利面(未煮熟)，让他们取出一根或多条面条。很简单。

现在拿一个煮熟的，或者只是‘把未煮过的东西倒在桌子上’，让他们在不干扰周围环境的情况下挑选一些东西(或者，如果是煮熟的，跟踪它的开始/结束)。

这通常是最重要的:未煮熟的意大利面结构很好，关注点分离，干净，并且需要努力训练才能做到(想想制造过程)。

后者，只要倒在平底锅里做饭或放在桌子上，很快就会做完，不过是一场噩梦，以后再筛过去。

因此，“意大利面代码”一词:)

Answer 3

想想那些有着清晰定义的界面的日常物品，它们可以很容易地更换，比如灯泡或电池。请解释爱迪生制造的第一批电灯没有很好的螺丝灯泡，因为在设计灯泡时直接用电线连接比花额外的时间设计螺丝插座要快得多。插座是后来发展起来的，因为灯泡必须经常更换。

软件是一样的。有一些方法可以“直接连接”其中的一些东西，使它的发展更快，但也使它的部分更难更换。如果你以后想做很多改变，首先你必须设计“螺丝插槽”，那么剩下的就会更快更容易改变。