ACM通信
软件学习:设计遗憾的艺术
“如果……会怎样?”是人类学习的一个如此基本的问题，它让几代科幻小说爱好者充满了通过时间旅行来纠正错误的可能性，就像19世纪作家h·g·威尔斯(H.G. Wells)的《时间机器》(the Time Machine)和《星际迷航》(Star Trek)的《城市在永远的边缘》(City on the Edge of Forever)那一集让人想起的那样。鉴于这种机器短期内不会出现，我们能做的最好的事情就是回顾过去，从中汲取教训，并将其应用于未来。这并不像听起来那么容易，因为有两个同样无益的极端:第一个是从不回顾过去，质疑哪些地方可以改进;第二个是不断地反思过去。我们的目标是生活在两者之间。但是软件工程师应该如何对他们的反射进行分类呢?
回顾长期以来一直是软件工程实践的一部分，如果不符合一个人的特殊敏感性，那么回顾以前的工作并将每个决策标记为“缺陷”或“bug”是很诱人的。这不是一种建设性的态度，因为理解决策的背景是至关重要的，因为没有任何努力存在于真空中。诸如可用预算、资源(数量、质量、经验和个性)、技术选项和目标进度等因素都相互作用，影响决策过程。只有通过理解设计背景，我们才能区分可预防的和不可避免的，同样地，我们也能够理解我们应该合理地惩罚自己什么是我们需要放弃的。
过时的遗憾
这种情况是在设计决策时框架或技术选项不存在，但因为没有这些选项而感到遗憾。虽然这可能导致一些有趣的假设讨论，比如个人电脑可能在20世纪60年代的太空竞赛中产生的影响，但它也可能走得太远，比如思考亚伯拉罕·林肯(Abraham Lincoln)作为总统，如果他在他的政府期间只有火箭和电脑，他将如何彻底改变太空旅行。因为当时没有有效的选择，所以无法做出决定。
实际的错误后悔
它会发生。“它”可以是任何东西，从胖手指，代码恐怖，或熊陷阱，许多书都写了这个主题，从代码完成(McConnell)到重构(Fowler)。我经历过的一个例子是，我的一个同事迷恋控制反转和嘲笑对象模式。有单元测试，但单元测试只测试模拟对象，而不是实际的代码库。当这个代码库被部署到现场时，它是一场灾难，我不得不清理它。这个例子中的问题不在于控制反转和模拟对象不是合法的模式;他们走得太远了，因为遵循模式成为了目标，而不是整个软件工作的功能。这只是一个例子;还有很多其他的可能性。
的决定后悔
这是“没有走的路”的遗憾。在软件工作中，设计选择似乎总是相互对立的，例如数据库设计的自然键与合成键。但是还有很多其他的情况，在这种情况下可能存在多种合理的选择，而不是在理论上被指控，每一个都是有效的和“足够适当”的。只要对每个选项的优缺点进行了诚实和彻底的评估——并且有理想的文档记录——这就是我们可以期望任何软件工程师在这种情况下做出最佳选择的最好结果。决策后悔是实际做决定时不可避免的结果，取得进展并带着一些决策后悔生活要比因不作为而瘫痪要好得多。
未知的后果后悔
这就是“我希望我当时就知道这一点”的令人头疼的情况，当人们体验到设计的意外副作用或边缘情况时，通常会在最糟糕的时候出现。这些并不一定会使整体设计失效，但会暴露出一两个需要解决的额外条件。Java编程语言充满了这些，特别是在内存管理和垃圾收集方面。Java已经在很多情况下证明了自己是一种有效的语言，但对于需要在高内存负载下运行的设计来说，Java也包含了一些令人惊讶的东西，在这些情况下，软件解决方案往往会工作，直到它们不工作。这就需要深入到晦涩的Java虚拟机设置中，有时还需要重新设计一些软件元素。公平地说，每一种编程语言和技术框架都有隐藏在某个地方的锋利的边缘，找到这些边缘是做有趣工作的经常结果。
错过的机会后悔
谁没有感叹过:“我怎么没想到呢?”嗯,你没有。,这就是生活。同样，一个人能做的最好的事情就是不断努力扩大自己的知识面，并寻找机会在未来应用这些经验教训。幸运总是眷顾那些勇敢和有准备的人。迭代同样重要，因为一个人练习得越多，他在模式识别方面就越好。
Doug Meil是一名软件架构师Ontada．他还创立了克利夫兰大数据聚会在2010年。
没有发现记录