好的编程实践与临时编程速度相比如何取舍?

5
我知道好的编程实践总是有助于项目的“长远”发展,但有时它们似乎只是浪费了很多时间。例如,建议我为每个类维护一个头文件和一个cpp文件,在头文件中只保留声明,而在cpp中保留定义。即使有10-12个类,这个过程也变得非常麻烦。每次添加新类时更新makefile所需的依赖关系和其他内容需要很长时间...
当我忙于做所有这些事情时,其他人会将所有内容都写在一个文件中,发布单一的编译命令并运行他们的程序...为什么我也不应该这样做呢?这很快而且有效吗?
即使试图为变量和函数想出简短而有意义的名称也需要很长时间,否则您最终会输入30个字符长的名称,完全无法管理,没有自动完成功能。
编辑:
好的,让我换种方式表达:假设我正在开发一个中小型项目,永远不需要由其他开发人员(甚至是我自己)进行维护。它基本上是一次性开发。在这种情况下,遵循编程实践是否值得?我的问题是,好的编程实践在开发过程中是否真的有帮助,还是只有在维护期间才会产生回报?

6
你有什么问题?你承认好的实践对“长远来看”有帮助。那肯定就是问题的结局了吧? - Oliver Charlesworth
你所谓的“临时编程”只对非常小的项目更快。对于任何真正有价值或复杂的软件,良好的编程实践实际上可以通过第一次正确地完成工作来使您更快地完成工作,因为在后期发现的错误需要指数级的时间来修复。 - Joel Coehoorn
1
这个问题比较主观,可能更适合在programmers.stackexchange.com上提问。 - David Thornley
被Slashdot上的一些好东西分心了,但这是我无法添加到原始评论中的必要链接:http://slashdot.org/comments.pl?sid=229755&cid=18634033 - Kendrick
我认为有两个开发层面需要考虑。框架和工具包,它们的设计和结构应该非常小心地处理。应用层代码,连接框架和工具包以构建可用程序的代码应该着眼于让其平稳、直观地运行。 - epatel
有没有同时做两件事的空间?先走捷径,然后重构。不要浪费时间写完美的代码,因为下周它就得被重写。对于你的10-12个类,你有多少是确定的?有多少会留下来?很可能,你定义的一半类别会在一两天内被其他东西替换,所以在你确定要保留它们之前,不要浪费太多时间让它们变得漂亮。 - jalf
6个回答

5

虽然我在这个领域工作的时间不长,但是我一直努力工作并随时记录下来,为变量定义有用的名称等等...这些措施在长期来看绝对可以节省时间。当其他开发人员/我自己回到代码进行维护时,这可以节省时间。

不会陷入困境,想知道这个变量是什么意思,为什么要这样做等等! :)


我只能再次表示同意。其实,我只写过最多两年的程序(如果算上批处理文件……如果不算的话,大约是一年到一年半),但我已经感受到了糟糕编程带来的痛苦后果(“后果”可以是“一周没碰它之后”)。 - user395760

4
懒惰现在可能会有回报,但只有一次。花时间做到完美并不会立即得到回报,但它将多次并且持续地得到回报。
而且,变量和方法名非常长并没有什么错,除非你认为编程的大部分时间都用于打字而不是解决问题。
附录:如果很难简洁地命名,那么它可能需要分解成更模块化的单元。难以命名的方法或变量是明显的代码异味。

有时候变量的名称很长,只是因为组成该名称的单词有许多字母和音节(即使变量名只有两个单词)。通常人们会省略元音字母以使输入更容易,但这样看起来就像是无法发音的乱码。:( - FrustratedWithFormsDesigner
3
代码异味并非普适规则,它们只是可能会指示出问题的事物。刻意删除变量和方法名称中的元音字母没有任何有用的作用,应该避免这样做。 - JohnFx
懒惰本身并不是坏事。一位经验丰富而又懒惰的程序员会考虑到他面前的工作,并避免任何会增加未来工作量的做法。 - ninjalj

3

这一切都关乎长期的可维护性。显然,你要么没有在团队中编写过代码,要么没有看过自己几年前编写的代码。如果我使用了有意义的变量名,我可以打开15年前编写的代码并进行修改,而且只需要很少的重新学习,但如果我没有使用有意义的变量名,那么就需要一些时间来弄清楚我当时在处理什么X和H以及为什么T不应该超过4。

试着与10个团队成员共享代码,并让每个人随意放置代码...我曾经和那样的人一起工作过。如果私刑仍然得到公众支持,我会带头发动很多次行动。想象一下...我知道我需要修改Foo.SetFoos(int FoosInFooVille)的签名,但我找不到Foo.h这个文件,那么现在我只需要找Foo.cpp对吧?哎呀,为了节省时间,他们把Foo.cpp塞进了Chew.cpp里...所以我去找那个文件...它不在文件顶部!我在那个文件中找到Foo并查看是否在上面...好吧...没找到...它在Chew.h里。现在我准备检查SVN日志并瞄准我的USB动力导弹发射器对付那个混蛋下次经过时。


这些情况下,svn blame 优于 svn annotate - ninjalj

2

临时的缺点在于长期维护(特别是当维护编码人员不是您自己时)。这种技术可能适用于快速概念验证,但如果不正确重建,将在未来造成更多问题。


2
是的,做好它是值得的,因为基本上这是现在付出还是以后付出的问题,而且你不是唯一一个会看到代码的人。 如果现在花15分钟来做好它,那么6个月(或更长时间)后要花多长时间才能弄清楚自己代码中的意思呢!
现在,你可以使用Martin Fowler的3次重构理念。 第一次修复代码时,注意到它可以重构,但你太忙了,就把它放过了。第二次回到同样的代码,同样的问题。第三次:重构代码。

你可能会喜欢阅读这篇文章:http://aegisknight.livejournal.com/138346.html - Joe

2

在这里,编程实践的有效性似乎不是你的问题。你需要关注的是你用来开发的工具。例如,有许多集成开发环境和其他选项可以自动更新你的make文件。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接