blocks|key|2536483|text|相当糟糕(-：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2536484|一个更好的想法是覆盖测试用例，而不是代码。|2536485|想法是这样的:开发人员应该提交失败的测试用例，然后在下一次构建中提交修复，测试用例应该通过……只需测量开发人员添加了多少测试用例。|2536486|作为额外的奖励，收集覆盖率统计数据(这里的分支覆盖率比行覆盖率更好)。|2536487|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Pretty bad (-:

A much better idea would to cover the test cases, rather than code.

The idea is this: a developer should commit a test case that fails, then commit the fix in next build, and the test case should pass ... just measure how many test cases the developer added.

As a bonus collect coverage stats (branch coverage is better than line coverage here).

blocks|key|52469|text|向他们展示以下内容之间的区别：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52470|for(int+i+=+0;+i+<+10;+i%2B%2B)+{
++++print+i;
}|code-block|syntax|javascript|52471|和|52472|print+0;
print+1;
print+2;
...
print+9|52473|问他们10个SLOC和3个SLOC哪个更好。|52474|52475|在回应评论时：|52476|52477|用不了多久就能解释for循环是如何工作的，|ordered-list-item|offset|length|style|CODE|52478|在你给他们看完之后，说“我们现在需要打印最多100的数字--这是你如何改变的。”并显示更改非DRY代码需要多长时间。|52479|52480|entityMap^0|0|0|0|0|0|0|0|0|9|3|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|18|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1A|8|@$T|1B|U|1C|V|W]]|9|@]|A|$]]|$1|X|3|Y|5|S|7|1D|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|11|$]]

Show them the difference between:

<pre><code>for(int i = 0; i &lt; 10; i++) {
 print i;
}
</code></pre>

and

<pre><code>print 0;
print 1;
print 2;
...
print 9
</code></pre>

And ask them whether 10 SLOC or 3 SLOC is better.

<hr>

In response to the comments:

<ol>
<li>It doesn't take long to explain how a <code>for</code> loop works.</li>
<li>After you show them this, say "we now need to print numbers up to 100 - here's how you make that change." and show how much longer it takes to change the non-DRY code.</li>
</ol>

blocks|key|2536577|text|有人说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2536578|“使用SLOC来度量软件进度就像使用kg来度量飞机制造进度一样。”|2536579|这是完全不合适的，因为它会鼓励不良做法，例如：|2536580|使用无意义的comments|2536581|...|unordered-list-item|2536582|
进行|2536583|Copy-Paste-Syndrome|2536584|discourage重构以实现easier|2536585|Stuffing|2536586|2536587|唯一的用途是，当您打印出完整的源码树时，它可以帮助您估计要在打印机中放入多少纸张。|2536588|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|J|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|15|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|17|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|W|$]]

Someone said :

"Using SLOC to measure software progress is like using kg for measuring progress on aircraft manufacturing"

It is totally inappropriate as it encourages bad practices like :

<ul>
<li>Copy-Paste-Syndrome</li>
<li>discourage refactoring to make things easier</li>
<li>Stuffing with meaningless comments</li>
<li>...</li>
</ul>

The only use is that it can help you to estimate how much paper to put in the printer when you do a printout of the complete source tree.

blocks|key|52622|text|可以通过添加额外的空行(“为了可读性”)或者通过放置或删除注释来显著改变SLOC。因此，仅依赖SLOC可能会导致混乱。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52623|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

SLOC can be changed dramatically by putting extra empty lines ("for readability") or by putting or removal of comments. So relying on SLOC only can lead to confusion.

blocks|key|52559|text|​|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52560|📷|atomic|offset|length|52561|52562|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/8b7d38ca72239bf337ecd1178ca3a511.gif|imageAlt^0|0|0|1|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@$E|S|F|T|1|U]]|A|$]]|$1|G|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O|P|-4]]]]

blocks|key|2536756|text|为什么SLOC作为生产力的单个指标是不好的|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2536757|把代码想象成一块黏土/石头。你需要雕刻，比如说10个雕像。重要的不是你雕刻了多少雕像。重要的是你雕刻得有多好。同样，不是看你写了多少行，而是看它们运行得有多好。在代码的情况下，LOC可能会以这种方式作为指标适得其反。|2536758|当编写一段复杂的代码时，生产力也会发生变化。编写一条print语句只需要一秒钟，但编写一段复杂的逻辑却需要很多时间。不是所有的手指都是一样的。|2536759|如何使用SLOC为您带来好处|2536760|我认为缺陷百分比的SLOC是一个很好的度量标准。是的，难度水平是起作用的，但这是一个很好的参数，经理们可以在做生意时抛来抛去。也试着从他们的角度思考。他们不讨厌你或你的工作，但他们需要告诉客户你是最好的，为此他们需要一些有形的东西。尽你所能地给予他们:)|2536761|entityMap^0|0|C|0|0|0|0|E|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|T|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|X|8|@]|D|@]|E|$]]|$1|N|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|O|$]]

Why SLOC is bad as an individual metric of productivity 

Think of code as a block of clay/stone. You need to carve, say 10 statues. It's not how many statues you carve that counts. It's how well you've carved it that counts. Similarly it's not how many lines you've written but how well they are functioning. In case of code LOC can backfire as a metric this way.

Productivity also changes when writing a complex piece of code. It takes a second to write a print statement but a lot of time to write a complex piece of logic. Not all fingers are equal. 

How SLOC can be used to your benefit

I think SLOC for defect % is a good metric. Yes the difficulty level comes into play but this is a good parameter that the managers can throw around while doing business. Try to think from their perspective too. They don't hate you or your work, but they need to tell customers that you're the best and for that they need something tangible. Give them what you can :)

blocks|key|52102|text|你不能判断它有多好(有多少特性，性能如何..)平面基于其重量(Sloc)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52103|当你想让你的飞机飞得更高、更长、性能更好时，你不需要给它增加重量。你可以用更轻/更好的材料替换它的一部分。你去掉了不需要的部分，这样就不会增加不必要的重量。|52104|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You don't judge how good(how many features,how it performs..) a plane is based on its weight(sloc). 

When you want your plane to fly higher, longer and perform better, you don't add weight to it. You replace parts of it with lighter/better materials. You strip off parts you don't need as to not add unnecessary weight.

blocks|key|52106|text|SLOC的问题是，它是一个容易玩弄的指标。高效并不等同于生成更多的代码。因此，我向人们解释斯基尔德里克所说的话的方式是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52107|52108|代码行越多，事情就越复杂。|ordered-list-item|52109|事情越复杂，就越难理解。|52110|在我添加新功能或修复错误之前，我需要花时间来理解it.|52111|Understanding。|52112|时间是要花钱的。|52113|<代码>G211|52114|更小的代码->更容易理解->添加新功能的成本更低|52115|Bean计数器可以理解这一点。|52116|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

The issue with SLOC is that it's an easy metric to game. Being productive does not equate to producing more code. So the way I've explained it to people baring what Skilldrick said is this:

<ol>
<li>The more lines of code there are the more complicated something gets.</li>
<li>The more complicated something gets, the harder it is to understand it.</li>
<li>Before I add a new feature or fix a bug I need to understand it.</li>
<li>Understanding takes time.</li>
<li>Time costs money.</li>
</ol>

Smaller code -> easier to understand -> cheaper to add new features

Bean counters can understand that.

blocks|key|2746664|text|为什么他们不明白SLOC没有改变，但是软件比昨天做了更多的事情，因为你添加了新的功能，或者修复了bug？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2746665|现在像这样向他们解释。通过比较代码行来衡量代码完成了多少工作，这与通过比较手机的大小来衡量手机中的功能是相同的。由于技术的进步和技术的进步，手机在过去的20年里缩小了尺寸，同时增加了更多的功能。好的代码遵循同样的原则，因为我们可以用越来越少的代码行来表达相同的逻辑，使其更快地运行，更容易维护，更容易理解，因为我们提高了对问题的理解，并引入了新的开发技术。|2746666|我会让他们专注于通过功能开发、维护和错误修复所返回的业务价值。如果对软件感到满意的人说他们可以看到改进，不要担心SLOC。|2746667|去看看这篇文章：|2746668|https://stackoverflow.com/questions/3800707/what-is-negative-code|offset|length|2746669|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|1T|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@$J|X|K|Y|1|Z]]|A|$]]|$1|L|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|I]]]]

Why don't they understand that the SLOC hasn't changed, but the software does more than it did yesterday because you've added new features, or fix bugs?

Now explain it to them like this. Measuring how much work was done in your code by comparing the lines of code is the same as measuring how many features are in your cell phone comparing it by size. Cell phones have decreased in size over 20 years time while adding more features because of technological improvements and techniques. Good code follows this same principal as we can express the same logic in fewer and fewer lines of code, making it faster to run, easier to maintain, and simpler to understand as we improve our understanding of the problem and introduce new techniques for development.

I would get them to focus on the business value returned through feature development, maintenance, and bug fixes. If whoever is happy with the software says they can see improvement don't sweat the SLOC.

Go read this:

<a href="https://stackoverflow.com/questions/3800707/what-is-negative-code">https://stackoverflow.com/questions/3800707/what-is-negative-code</a>

blocks|key|2746688|text|即使是现代的代码度量工具也会批评SLOC争辩，我喜欢ProjectCodeMeter常见问题解答中的观点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2746689|What's+wrong+with+counting+Lines+Of+Code+(SLOC+/+LLOC)?|offset|length|2746690|entityMap|0|LINK|mutability|MUTABLE|url|http://www.projectcodemeter.com/cost_estimation/help/FN_FAQgen.htm^0|0|0|1J|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

even modern code metrics tools criticize SLOC conting, i like the point made in the ProjectCodeMeter FAQ:

<a href="http://www.projectcodemeter.com/cost_estimation/help/FN_FAQgen.htm" rel="nofollow">What's wrong with counting Lines Of Code (SLOC / LLOC)?</a>

blocks|key|52763|text|我不同意SLOC是一个糟糕的指标。进入一个有11个答案的多年的问题可能没有意义，但我仍然会添加另一个答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52764|大多数论点称它是一个糟糕的指标，因为它不适合直接衡量生产率。这是一个奇怪的论点；它假设指标被疯狂地使用。根据这个推理，人们可以说开尔文是一个糟糕的单位，因为它不适合测量距离。|52765|代码长度是衡量镇流器的一种可行方法。|52766|非注释代码行的数量与以下内容相关：|52767|52768|未检测到的errors|unordered-list-item|52769|maintenance成本|52770|针对新功能的培训时间成本|52771|新功能成本|52772|52773|还有更多类似的成本，比如优化成本。|52774|当然，SLOC计数并不是这些的精确度量。代码可以是非常好的，也可以是非常难看的。但可以假设代码长度很少是自由的，因此，更长的代码通常更难管理。|52775|如果我管理一个程序员团队，我会非常想跟踪它创建或移除的镇流器。|52776|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|K|7|18|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|Z|$]]

I disagree on SLOC being a bad metric. It may be moot to go into a years-old question with eleven answers, but I'll still add another.

Most arguments call it a bad metric because it is not suited to directly measure productivity. That is a strange argument; it assumes the metric to be used in an insane way. With this reasoning, one could call the Kelvin a bad unit because it is unsuited to measure distance.

<h2>Code length is a viable measure of ballast.</h2>

The amount of non-comment code lines correlates with:

<ul>
<li>undetected errors</li>
<li>maintenance costs</li>
<li>training time for new contributors</li>
<li>migration costs</li>
<li>new feature costs</li>
</ul>

and many more similar kinds of costs, like the cost of optimization.

Of course SLOC count isn't a precise measure of any of these. Code can be anywhere between very nice and very ugly to manage. But it can be assumed that code length is rarely free, and thus, longer code is often harder to manage.

If I were managing a team of programmers, I would very much want to keep track of the ballast it creates or removes.

blocks|key|2536988|text|我相信SLOC是一个很好的指标。它告诉你你的系统有多大。这对于判断复杂性和资源是很好的。它还可以帮助您为下一位开发人员编写代码库做好准备。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2536989|但是，只有在应用了其他适当的代码质量度量之后，才应该分析SLOC计数。所以..。|2536990|2536991|不要在1行就可以的情况下编写2行代码，除非2行版本使代码更容易维护2倍。|unordered-list-item|2536992|不要仅仅为了弄乱SLOC计数就用不必要的注释来弄乱代码。|2536993|不会根据SLOC计数来支付人员工资。|2536994|2536995|我已经管理软件项目30年了。我一直使用SLOC+count来帮助理解成熟的系统。在一个项目接近1.0版本发布之前，我从来没有发现看一眼SLOC计数是有用的。|2536996|基本上，在开发过程中，我担心的是质量、性能、可用性和与规范的一致性。把这些做好，这个项目可能会取得成功。当尘埃落定时，看看SLOC计数。您可能会惊讶于您从5000行代码中获得了如此多的内容。你可能会惊讶于你得到的如此之少！(但SLOC计数不会影响质量、性能、可用性和与规范的一致性。)|2536997|并且总是像下一个要开发你的代码的人是一个暴力的精神病患者，他知道你住在哪里。|2536998|干杯，奇普叔叔|2536999|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|G|7|11|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

I believe SLOC is a great metric. It tells you how large your system is. That is good for judging complexity and resources. And it helps you prepare the next developer for working on a codebase.

But SLOC count should be analyzed only AFTER other appropriate code quality metrics have been applied. So...

<ul>
<li>Do NOT write 2 lines of code when 1 will do, unless the 2-line
version makes the code 2 times easier to maintain.</li>
<li>Do NOT fluff code with unnecessary comments just to fluff SLOC count.</li>
<li>Do NOT pay people by SLOC count.</li>
</ul>

I have been managing software projects for 30 years. I use SLOC count all the time, to help understand mature systems. I have never found it useful to even glance at SLOC count until a project is near version 1.0 release.

Basically, during the development process, I worry about quality, performance, usability, and conformance to specifications. Get those right, and the project will probably be a success. When the dust settles, look at SLOC count. You might be surprised that you got SO much out of 5,000 lines of code. And you might be surprised that you got SO little! (But SLOC count does not affect quality, performance, usability, and conformance to specification.)

And always code like the person who will be working on your code next is a violent psychopath who knows where you live.

Cheers,
Uncle Chip

We are documenting our software development process. For technical people, this is pretty easy: iterative development with internal milestones every four weeks, external every 3 months. 

However, the purpose of this exercise is to expose things for our project management in terms that they can understand. Specifically, these non-technical managers need metrics that they can understand.

I understand our options for metrics well and have proposed a whole set (requirements met and actual costs vs. budgeted costs are two of my favorites). However, we do have some old hands involved and they tend to hang onto metrics like SLOC. 

I understand the temptation of SLOC: it seems easy for non-software people to understand and it seems like the closest analog of a physical thing (it's just like counting punched cards back in the old days!).

So here's the question: how can I explain the dangers of SLOC to a non-technical person?

Here's some concrete motivation: we work on a fairly mature deployed system that has years of history behind it. As we add features, SLOC tends to stay approximately level or even decrease (refactoring removes old / dead code, new features are really just adjustments of existing, etc). To a non-programmer manager, a non-increasing SLOC in a development project is perplexing at best....

Clarifying in response to a recent answer below: remember, I'm arguing that SLOC is a bad metric for the purposes of measuring project progress. I'm not arguing that it is a number that's not worth collecting. It requires extensive context to do anything useful with it and most program managers don't have that context.

How bad is SLOC (source lines of code) as a metric?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们正在记录我们的软件开发过程。对于技术人员来说，这非常简单:每四周使用内部里程碑进行迭代开发，每3个月使用外部里程碑进行迭代开发。但是，此练习的目的是为我们的项目管理提供他们可以理解的内容。具体地说，这些非技术经理需要他们能够理解的指标。我很好地理解我们的指标选项，并提出了一整套(满足的需求和实际成本与预算成本是我最...

问SLOC (源代码行)作为度量标准有多糟糕？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SLOC (源代码行)作为度量标准有多糟糕？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SLOC (源代码行)作为度量标准有多糟糕？
EN