我最近写了一个小工具,为我手写的每一层生成一个类,用于枯燥的“数据表格”工作,我花了将近 90% 的时间(我知道很沮丧)......随着经济的改善,更多关于这个; )
我的问题是——使用这个工具而不是每天手工输入所有这些代码真的会伤害我作为开发人员吗?我觉得我将始终对这个工具进行更改,因此我“应该”保持在使用的模式/做出的选择/等之上......但我的一小部分感觉我可能会失去我的优势......我我错了吗?
我最近写了一个小工具,为我手写的每一层生成一个类,用于枯燥的“数据表格”工作,我花了将近 90% 的时间(我知道很沮丧)......随着经济的改善,更多关于这个; )
我的问题是——使用这个工具而不是每天手工输入所有这些代码真的会伤害我作为开发人员吗?我觉得我将始终对这个工具进行更改,因此我“应该”保持在使用的模式/做出的选择/等之上......但我的一小部分感觉我可能会失去我的优势......我我错了吗?
如果该工具可以不假思索地吐出代码,那么它可能会为您节省大量不经意的打字。
首先编写工具需要思考,所以我猜你会更“处于边缘”维护和编写工具。
那挺好的!当然,编写一个工具来为你完成所有工作是不可能的,也是错误的。
但是自动化可重复的任务总是好的——有时编写特定类型的代码是可重复的。
《实用程序员》一书中甚至鼓励它。
确保在源代码管理中检查了代码生成器而不是其输出(除非您以后必须手动修改代码)!
你绝对没有错。我可以在任何地方使用代码生成器——我目前使用 CodeSmith 通过查看数据库来创建我的 DAO。
你害怕失去什么优势?在我看来,代码生成实际上给了你一个优势。
Larry Wall(以 Perl 闻名)将编程的三个主要优点描述为懒惰、不耐烦和狂妄自大。
恭喜!你已经表现出很好的懒惰,因为你已经确定了一些可以传递给自动化流程的工作并完成了。(糟糕的懒惰会导致偷工减料、拖延,并且通常会推迟而不是消除工作。)如果你能成功地将一些工作转移到另一个程序上,你就可以减少花在烦人的琐事上的时间,而将更多的时间花在完成事情和学习上。
生成你能做的。代码生成是我在过去 2 或 3 年中使用的最好的工具之一。一遍又一遍地输入相同的代码(或复制并粘贴)很容易出错。
通过让某事/别人做某事来花更少的时间做某事,而更多的时间研究更好的方法来做这件事通常会导致以更好的方式去做。
这不仅仅适用于编程......
您的代码生成器(至少在原则上——我自己没有看过)是正确的,至少就目前而言。
下一步是看看您是否可以创建一个功能与生成的代码匹配的基类,而不是生成所有这些冗余代码,然后从中派生您的应用程序代码。使用继承而不是生成将使您从改进中受益,而无需在所有项目上重新运行生成器。也许更重要的是,如果您自定义生成的代码,如果您重新运行生成器,自定义将会丢失,但是当基类更改时,派生类中的自定义将被保留。
不。为什么你认为 IDE 如此受欢迎。想象一下,如果所有使用 Visual Studio 的人都必须在没有 IDE 帮助的情况下以编程方式创建 GUI,那将是可怕的。我敢打赌,大多数使用 VisualStudio 的人都不知道如何手动创建他们在 IDE 中创建的表单。但这并没有错。
我相信代码生成会尽可能地消除编程的死记硬背的任务。你不会失去优势,你可能会成为一个更好的程序员,因为你会花更多的时间在重要和有趣的事情上。
顺便说一句,你的工具听起来很有趣。你有没有在任何地方发布它?
只要您了解您正在生成的内容,代码生成就可以了。物理学家使用计算器是因为他们了解他们正在自动化的公式,并意识到他们宝贵的时间最好花在重要的任务上。
代码生成是The Pragmatic Programmer 提倡的宝贵DO:s之一。我真心推荐那本书。这是一个实用的程序员快速参考。
不生成代码几乎是虚伪的。在这里,我们将所有这些传统上由手工完成的任务自动化......然而,我们中的许多人仍然手摇我们所有的代码,即使它可以很容易地生成。
我唯一的代码生成经验是 Common Lisp 的宏。它们一直在使用。使重复性任务自动化的一切都是有益的;这就是编程的意义所在。
阅读Mac 的故事。
想象一下,每次您对工具进行更改并重新生成代码时,您都会在所有模块上手动更改设计。
自从我开始生成代码并加快速度以来,我发现我很少在生成的代码中遇到错误。
我发现编写代码生成确实有助于我了解良好架构的细微差别。您开始看到常见的模式,而不是狭隘的设计视图。也就是说,不要使用代码生成来替代好的面向对象的代码,也不要太喜欢你的代码生成,你会忽略新技术。例如,如果您在 .NET 中并且正在编写代码生成以进行数据访问,那么您最好有一个不使用 Linq to SQL 或 NHibernate 的好借口。同样,动态数据可以在许多表单数据场景中提供帮助。所以,我的建议是:根据需要增加新的东西和代码生成。
我对代码生成的 2cents 是它对于重构的使用也很重要。我发现部分类和良好的文件比较实用程序(Araxis 或 BeyondCompare)是必不可少的。
将您生成的代码保存在一个文件中,并将您为该类所做的自定义调整保存在另一个文件中。
这种做法将使您能够快速实施这些全面的框架更改,还将帮助您迁移到新的范例,同时轻松地保存您的自定义逻辑。
CodeSmith FTW!
虽然构建服务器可以很好地确保所有代码都能编译,但它并不能解决签名与存储过程等的差异。如果您定期运行代码生成器,您可以更轻松地识别这些更改何时发生。单元测试会告诉你 SP 是错误的,代码生成会告诉你如何使它正确。