实际代码与支持代码的比率 [英] Ratio of real code to supporting code

问题描述

我发现我的代码中只有大约30％实际上解决了问题，其余的由日志记录，测试，参数检查，异常，错误处理等等。你发现在你的代码中，是否有一个IDE /编辑器，允许你隐藏不感兴趣的代码？

OTOH有哪些语言使支持代码更多可管理的和更小的？

编辑 - 我想我们都知道业务逻辑和其他代码之间的区别。我不是说日志等不重要。事情是，当我编程时，我要么实现业务逻辑，要么确保事情不会中断。对我来说，这是两种不同的思维方式，其他人是如何发展的，是否有支持这种开发方式的IDE？

解决方案

p>支持代码和真正的代码一样重要。

考虑一辆汽车，你的产品的质量是通过支持代码确定的。在从点A到点B的方面，这只需要一个推车：框架，座椅，发动机，几个轮胎。但现代汽车有很多不仅仅是基础。使用电子发动机正时的高效发动机。自动变速箱。铲斗座。加热和空调。齿条和小齿轮转向。动力制动器。防抱死制动器。安静，舒适的小屋保护免受天气。气囊。折皱区和其他先进的安全特性。等等。

即使在软件中，细节和执行也很重要。如果你发现你的支持代码往往更像是kludges和黑客，那么是时候重新考虑你的基本方法。

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

/ p>

您的支持代码：

• 连接到汽车前部的一根管子或集成在折叠区域中的能量吸收保险杠？
li>

• 绑在车架上的绳索上的卡钩或四轮防抱死制动器。


• 一副护目镜和厚外套或挡风玻璃和加热系统？

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

修改：回应Dave Turvey的评论：

原来的问题，列出的支持代码的例子之一是错误处理。考虑这一会儿。想象一下，在汽车，微波炉或甚至操作系统的上下文中。应该将错误处理降级为二等公民，因为它在某种抽象意义上服务于支持功能吗？在汽车中，安全特征是车辆的基本设计的一部分，并且包括汽车价值的主要部分。微波炉（实际上，微波炉的嵌入式软件的）的安全特征和错误处理也是其价值的重要部分。被正确屏蔽的微波炉可以在正确的情况下烹饪食物，但这会对操作者造成危害。

每个工具的隐式特征集软件或其他）包括此列表：

• 鲁棒性


• strong>可用性 任何人已经建立或使用已经有这些功能。不理解这一点将转化为对这些功能的执行失败，这将导致低价值和低商业利益的低质量产品。没有像支持代码这样的东西，只有一个误解的性质是什么意味着一个功能是完整的。仅在实验室条件下在抽象中工作的特征是实验，而不是产品的一部分。
  
  
  

  纯粹的，原始特征漂浮在沼泽上的想法的脏，丑陋的支持代码是软件开发的错误形象。相反，想想优雅，超级整合的机械，是精心打造，直观的使用，强大。

  
  

  I'm finding only about 30% of my code actually solves problems, the rest is taken up by logging, tests, parameter checking, exceptions, error handling and so on. Do you find that in your code, and is there an IDE/Editor that allows you to hide code that's not interesting?

  OTOH are there languages which make the support code more manageable and smaller in size?

  Edit - I think we're all aware of the difference between business logic and other code. I'm not saying that the logging etc is not important. The things is, when I'm coding I'm either implementing business logic, or I'm making sure things don't break. For me that's two different ways of thinking, do others develop like that, and is there an IDE that supports that way of developing?

  解决方案

  Supporting code is just as important as the "real code". The quality of your product is determined as much by supporting code as anything else.

  Consider an automobile. In terms of just getting from point A to point B, that requires nothing more than a go-cart: a frame, a seat, an engine, a few tires. But modern cars have a lot more than just the basics. Highly efficient engines using electronic engine timing. Automatic transmissions. Bucket seats. Heating and A/C. Rack and pinion steering. Power brakes. Anti-lock brakes. Quiet, comfortable cabins protected from the weather. Air bags. Crumple zones and other advanced safety features. Etc. Etc.

  Details and execution are important, even in software. If you find that your "supporting code" tends to look more like kludges and hacks, then it's time to rethink your fundamental approach. But ultimately the fit and finish determines quality of the end product as much as anything else.

  Edit: The questions you should ask yourself:

  Is your "supporting code":

  • An umbrella duct taped to a pole or a metal and glass cabin frame?
  • A piece of pipe tied to the front of the car or an energy absorbing bumper integrated into a crumple zone?
  • A grappling hook on a rope tied to the frame or 4-wheel anti-lock power brakes?
  • A pair of goggles and a thick coat or a windshield and a heating system?

  Answers to these questions will probably affect how much you care about your "supporting code".

  Edit: Response to Dave Turvey's comment:

  I'd encourage rereading the original question, one of the examples of "support code" listed is "error handling". Consider this for a moment. Imagine it in the context of, say, an automobile, a microwave oven, or even an operating system. Should error handling be relegated to second class citizenship because it serves a "support" function in some abstract sense? In an automobile the safety features are part of the fundamental design of the vehicle and comprise a substantial part of the value of the car. The safety features and "error handling" of a microwave oven (indeed, of the microwave oven's embedded software as well) are an important part of its value as well. A microwave oven that was improperly shielded could cook food just fine, under the right circumstances, but it would pose a hazard to the operator.

  The implicit featureset of every tool (software or otherwise) includes this list:

  • Robustness
  • Usability
  • Performance

  Everything anyone has ever built or used has had these features. Failure to understand this will translate to failure to execute well on these features which will make for a poor quality product of low value and low commercial interest. There is no such thing as "support code", there is only a misunderstanding of the nature of what it means for a feature to be complete. A "feature" that works in the abstract only under laboratory conditions is an experiment, not a part of a product.

  The idea of pure, pristine features floating on a bog of dirty, ugly support code is the wrong image of software development. Instead, think of elegant, superbly-integrated machinery that is well-built, intuitive to use, and powerful.

  这篇关于实际代码与支持代码的比率的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！