实际代码与支持代码的比率

Question

我发现只有大约30％的代码实际上解决了问题，剩下的就是记录，测试，参数检查，异常，错误处理等等。您是否在代码中找到了，并且是否有一个IDE /编辑器可以隐藏不感兴趣的代码？

OTOH是否有语言使支持代码更易于管理和更小？

编辑 - 我想我们都知道业务逻辑和其他代码之间的区别。我不是说伐木等并不重要。事情是，当我编码时，我要么实现业务逻辑，要么我确保事情不会破坏。对我而言，这是两种不同的思维方式，其他人是否会像这样开发，是否有支持这种开发方式的IDE？

Answer 1

支持代码与“真实代码”同样重要。您可以通过支持代码来确定产品的质量。

考虑一辆汽车。就从A点到B点而言，这只需要一个推车：一个车架，一个座椅，一个发动机，一些轮胎。但现代汽车不仅仅是基础知识。使用电子发动机正时的高效发动机。自动变速箱。斗式座椅。加热和A / C.齿轮齿条转向。动力制动器。防抱死制动器。安静，舒适的小屋免受天气影响。气囊。褶皱区域和其他先进的安全功能。等等。

即使在软件中，细节和执行也很重要。如果你发现你的“支持代码”看起来更像是kludges和hacks，那么是时候重新思考你的基本方法了。但最终，合身和完成决定了最终产品的质量。

编辑：您应该问自己的问题：

是您的“支持代码”：

• 用杆子或金属和玻璃舱框架固定的伞管？
• 一条绑在汽车前部的管道或一个集成在防撞区的吸能保险杠？
• 绑在车架上的绳子上的抓钩或4轮防抱死动力制动器？
• 一副护目镜和一件厚外套或挡风玻璃和加热系统？

这些问题的答案可能会影响您对“支持代码”的关注程度。

编辑：回复Dave Turvey的评论：

我鼓励重新阅读原始问题，其中一个列出的“支持代码”是“错误处理”。考虑一下这一点。想象一下，在汽车，微波炉甚至操作系统的背景下。错误处理是否应该降级为二等公民身份，因为它在某种抽象意义上提供了“支持”功能？在汽车中，安全特征是车辆基本设计的一部分，并且包括汽车价值的很大一部分。微波炉的安全功能和“错误处理”（实际上，微波炉的嵌入式软件）也是其价值的重要组成部分。在适当的情况下，不正确屏蔽的微波炉可以很好地烹饪食物，但这会给操作员带来危险。

每个工具（软件或其他）的隐含功能集包括以下列表：

• 的鲁棒性
• 的可用性
• 的效果

任何人曾经构建或使用的所有东西都具有这些功能。不理解这将导致未能很好地执行这些功能，这将导致低价值和低商业利益的低质量产品。没有“支持代码”这样的东西，只有对功能完成意味着什么的误解。仅在实验室条件下以抽象方式起作用的“特征”是实验，而不是产品的一部分。

纯粹，原始特征漂浮在肮脏，丑陋的支持代码的bog上的想法是软件开发的错误形象。相反，可以考虑优雅，高度集成的机器，这些机器构造精良，使用直观，功能强大。

Answer 2

支持代码很重要，但是当你不想这样做时，你不要被它分散注意力。有两种技术可以提供帮助。

• 具有一流功能的语言将帮助您模块化代码，以便日志记录，计时等可以实现一次，然后与许多其他模块结合使用。它还可以帮助您编写单元测试。学习这些技巧的一些好方法是阅读论文Why Functional Programming Matters并了解QuickCheck工具。 （不，我不是约翰休斯的先例，但他确实做了很棒的工作。）

• 如果您不能使用具有强大功能的编程语言进行模块化和重用，或者您不想使用，Don Knuth的Literate Programming技术将帮助您组织代码，以便您可以分割以你想要的方式分开，只关注你想要的东西。 Noweb文字编程工具支持任何可以用ASCII编写的语言，以及这些语言的组合。

Answer 3

如果我的IDE可以隐藏“不感兴趣的代码”，我肯定会关掉这个功能。你不希望发生这种情况，我打赌：）

当然有一些语言可以最大限度地减少支持代码的数量，但我认为你不能简单地从Java切换到简单的JavaScript，因为在JavaScript中你不必声明每个异常...我认为它是相当的必要时将支持代码放在原处。

哦，你可以让你的程序正式指定并经过数学证明，那么你就不需要太多支持你的代码了; D

Answer 4

您所指的实际代码通常称为“业务逻辑”。

在一个好的单元测试系统中，你的单元测试应该在他们自己的类中（可能是他们自己的程序集），所以这不应该是一个问题。

其余部分基于语言。语言越高级，就越能够避免在某种程度上编写支持代码。此外，一个目标明确的开发系统可以帮助您避免编写大量代码（Visual Basic的屏幕构建器，Ruby on Rails，...），但这些抽象可能会崩溃并导致您编写与其他任何代码一样多的代码你用它来开发目标类型的应用程序之外的目标。 （如果计算素数，VB和Ruby并没有那么多帮助）

除了语言/平台之外，您还可以进行重构 - 消除所有支持代码的技巧（以及业务逻辑中的冗余），以保持代码库的清洁和小巧。

在练习高级重构时，您可能最终会为自己编写工具。

有时将数据从代码中抽象出来并转换成某种形式的结构化文件可以消除大量支持代码并将其余部分转移到“业务逻辑”中，因为现在解析数据并将其设置为“业务”的一部分你的程序呢。

这是一个很好的权衡，因为这种类型的业务逻辑往往更易读，更容易考虑因素。这种抽象的另一个优点是，所有的“配置”现在都是在数据中完成的，这往往会使它成为别人的问题。

作为这种工具的一个例子：Rails本身！它需要大量的Web开发样板，并将其从代码和数据和简单代码驱动的库中分解出来（Ruby模糊了代码和数据之间的界限 - 它们的数据文件实际上循环回到Ruby代码中指定的！ ）

Answer 5

就像你想去Pike's Peak的顶峰一样。您可以乘坐Winnebago，乘坐​​SUV或摩托车，或骑自行车。

某些方式或多或少都是昂贵的，更快的等等。有时候你最终会带来很多东西而不是严格来说是为了实现垂直进展;在凉爽的啤酒中喝啤酒真好。但要记住，你应该对与你同行的所有事情负责。

Answer 6

Aspect Oriented Programming部分解决了这个问题。它允许您将代码注入现有的源/字节码。通过这种方式，您可以将日志记录等任务显示在自己的模块中，而不是编入业务逻辑。

Answer 7

工作扩展以填充它的容器。这听起来像是一个经济学问题。 （即，使用昂贵的输入（编写功能所花费的时间，编写管道代码所花费的时间）来优化输出 - 用户的功能和开发人员的功能。）

您必须包含用户可见功能，或者您没有可行的产品或工作。一旦部分完成，您的剩余预算时间将在具有可见的工作回报的活动和不可见（但积极！）的工作回报之间分配，例如异常记录，内存管理等。

什么语言使实现功能更便宜可能会增加您的功能/管道代码比率。同样，无论使用哪种语言使得管道代码更便宜，都可能会增加管道代码的功能，因为您可以腾出更多时间来编写功能。

像所有优化问题一样，你有2个效果 - 支持代码的大小增加（因为你使用廉价的代码生成）和功能相关代码的大小增加（因为你有剩下更多的时间来写功能），所以最终的比例可能很难预测。

我不吝惜90％的代码是数据访问管道，因为与10％的手写域特定代码相比，它是可测试的，代码生成且非常便宜。

Answer 8

我不会试图让所有例程变得万无一失，只有那些暴露在外面世界的例行公事。

http://en.wikipedia.org/wiki/Folding_editor

更高和更动态的语言通常不那么冗长。弱打字也节省了大量代码。当然还有权衡取舍。

Answer 9

我在Visual Studio中使用#region指令来折叠不是主要焦点的代码块，例如单元测试。使用log4net日志记录语句只有一行。我没有找到任何减少参数检查代码的方法，尽管听起来像C＃4有某种合同框架可以帮助那里。

Answer 10

我有一些同事，曾经被一个客户因为过期和错误的项目而被咀嚼，向客户吹嘘他们写的测试代码是操作代码的5倍。

客户不高兴，“不开心”我的意思是他们的皮肤变成绿色，他们长到正常尺码的5倍，衣服脱落。

Answer 11

您可以在实用程序程序集中创建一个静态类来检查您的参数和事物。例如在Spring Framework中（我得到了这个想法）它有一个Assert类，它确保字符串参数不为空或对象参数不为空它非常快。它可以清理验证代码并减少重复代码，这是双赢。