良好的编程实践与ad-hoc编程的速度

Question

我知道良好的编程习惯总是有助于项目的“长期”，但有时它们似乎花费了大量时间。例如，它建议我为每个类维护一个头文件和一个cpp文件，只保留头文件中的声明，而cpp中的定义。即使有10-12个班级，这个过程也变得非常麻烦。每次添加新类时更新makefile依赖和evthing ..需要花费很多时间......

虽然我正忙着做这一切，但其他人只会在一个fie中编写evthing，发出一个编译命令并运行他们的程序......为什么我也不应该这样做？它速度快，有效吗？

即使尝试为变量和函数提供简短有意义的名称也需要花费大量时间，否则最终会输入30个字符的长名称，完全无法管理而不会自动完成

编辑：

好的，让我说的有点不同：让我说我正在开发一个中小型项目，它永远不会需要不同开发人员（甚至是我）的任何维护。它基本上是一次性开发。在这种情况下，编程实践是否值得遵循。我想我的问题是，良好的编程实践在开发过程中是否真的有用，或者它们只是在维护期间得到回报？

Answer 1

我没有长时间在这个领域工作，但是我没有懈怠和记录，用有用的名字定义变量等等......从长远来看肯定可以节省时间。当其他开发人员/我自己回到代码进行维护时，它可以节省时间。

不知道这个变量意味着什么，为什么我这样做，等等！ ：）

Answer 2

懒惰现在可以得到回报，但只会付出一次。花时间做正确的事并不能立即得到回报，但它会多次这样做并持续更长的时间。

此外，真正长的变量和方法名称没有任何问题，除非您订阅了一个天真的视图，大部分时间用于编程而不是解决问题。

附录：如果很难简洁地命名，可能需要将其细分为更多模块化单元。难以命名的方法或变量是明确的代码气味。

Answer 3

ad-hoc的缺点是长期的，当涉及到维护时（特别是当维护程序员不是你自己的人时）。这些技术可以用于快速概念验证，但如果你不能正确重建，将来会引起更多问题。

Answer 4

是的，值得做的就是“正确”，即好，因为，基本上它现在付我还是付钱给我，而且，你不是唯一能看到代码的人。 如果现在需要15分钟才能做到“好” - 从现在起6个月（或更长时间）需要多长时间才能找出你的意思 - 在你自己的代码中！

现在，您可以使用Martin Fowler的3次罢工来进行重构。 第一次在代码中修复一些东西，注意它可以被重构，但你太忙了，放手吧。第二次回到相同的代码，同样的事情。第三次：重构代码。

Answer 5

在这里，编程实践的有效性似乎不是你的问题。你应该关注的是你用来开发的工具。例如，有许多IDE和其他选项可以让您的make文件自动更新。

Answer 6

这完全取决于长期可支持性。很明显，你要么没有编写团队代码，要么不必查看几年前编写的代码。我可以打开我15年前编写的代码并使用非常小的重新学习曲线修改它，如果我给出了有意义的变量名称，而如果我没有它将需要一些时间来弄清楚我用X和H做了什么，为什么T不应该超过4。

尝试与团队中的10个人共享代码，并让他们每个人只将代码放在他们喜欢的任何地方......我曾与这样的人合作过。如果私刑仍然得到公众的支持，我会带领许多人。想象一下......我知道我需要修改Foo.SetFoos（int FoosInFooVille）上的签名，但我找了Foo.h并且找不到它，现在我只是寻找Foo.cpp吧？哎呀，为了节省......时间？......他们把Foo.cpp塞进Chew.cpp ......所以我看那里......它不在文件的顶部！我是否在该文件中找到了Foo并查看其上方是否...确定...没有，没有找到...它在Chew.h中。现在我准备检查​​SVN日志，并在下次经过时，在那个混蛋中瞄准我的USB供电导弹发射器。