我应该提前计划，还是在写程序的时候想出办法？

Question

今天我在想保罗·格雷厄姆的“黑客和画家”一书。更具体地说，这两段：

“我在大学里被教导说，在接近电脑之前，就应该把程序完全写在纸上。”我发现我不是这样编程的。我发现我喜欢坐在电脑前编程，而不是一张纸。更糟糕的是，我并没有耐心地写出一个完整的程序，并向自己保证它是正确的，我倾向于只吐出那些被无可救药破坏的代码，并逐渐地把它打成形状。调试是一种最后的通过，在那里你发现了打字和疏忽.它似乎是由调试组成的编程。..。据我所知，他们教我在大学里编程的方式都是错误的。你应该像作家、画家和建筑师那样，在写程序的时候想出办法。“

我的大学就是这么教的，我敢肯定大多数其他大学也是这样。您知道您的程序将做什么，然后您知道如何做，然后您键入和调试。有时，您可以创建一个基本版本并添加功能，但是您需要仔细考虑，然后键入。

这让人想起费曼书中的那一章：“他通过思考解决收音机问题！”在那里，他四处走动，思考如何打破收音机，然后修复它。对我来说，这就是编程的意义--思考然后找到解决方案。

这是目前流行的编码方法吗？如果是这样的话，为什么不让更多的人黑掉，把一个程序放在一起，而不对它的外观有先入为主的想法呢？

思考和类型的优点和缺点是什么？

Answer 1

这是一个被排除的中间谬论的完美例子。是的，在你触摸实际键盘之前把整个程序写在纸上是个坏主意。但这并不意味着相反的极端--立即跳入编码并开始黑客攻击--是个好主意。事实上，情况更糟。

在开始写之前，理解你想写的东西是非常重要的。当我有一个新的特性要在工作中实现时，我要确保我已经有了一个规范，它描述了在我开始之前所做的事情。我仔细看了一下，如果上面有什么不合理的地方，我会和编写规范的人交谈，并在我们达成一致意见之前对这个问题进行研究。有时，我不理解需求，他们可以让我明白；其他时候，PM人员不理解技术细节，他们最终修改了规范。

几乎所有这样做过的人都可以告诉您，从个人经验来看，在规范中修复问题比在实现的中途发现代码中的问题要容易得多，将其全部取出，然后用其他东西替换它。因此，在开始编写代码之前，为您编写的代码制定一个计划是非常非常重要的。

Answer 2

你觉得米开朗基罗刚爬到西斯廷教堂的顶端就开始画画了吗？绘制了测试图。需要得到教皇的批准。有脚手架要建。为指导其他艺术家群体而制作的模板。修复工作甚至更加复杂。

如果我想构建一个应用程序，并且不需要考虑其他人的设计偏好，我可以开始编写代码。如果你走错了路，就改变主意吧。反正我也不想要那个功能。

让画家或作家参加委员会。“哦，那就把主角变成女性吧。如果我们稍后改变主意，我们会告诉你的。WTF，让我们把它改成20‘长，而不是30。你能在明天揭幕前加上一个西班牙帆船50名独特的赛艇手吗？”

Answer 3

这种类比的前提是错误的:许多作家在开始写作之前概述或至少想出他们要写什么，而许多画家和建筑师在开始实际的“作品”之前会做几十项研究和草图。

既然这个类比是错误的，答案是肯定的--程序员应该像作家、画家和建筑师一样工作。