如果 IDE 在之前发现了一个会阻止编译的错误 实际编译，应该是 确定了？如果是的话，应该是 作为编译进行识别和跟踪 错误还是代码错误？
如果 IDE 是您工具链的一部分，那么它看到错误就像您发现错误一样，从而发现代码错误。如果你不经常使用IDE，那么我会把它们算作编译错误。
In general, as the PSP is a personal improvement process, the answers to your actual questions do not matter as long as you pick one answer and apply it consistently. That way you will be able to measure the times you take in each defined phase, which is what PSP is after. If your team is collectively using the PSP then you should all agree on which scripts to use and how to answer your questions.
My takes on the actual questions are (not that they are relevant):
In interpreted languages, there is no compile time. However, there might be problems in execution. Is executing the script, outside of the unit (and other) tests, considered "compile" or "test" time? Should errors with execution be considered "compile" or "test" errors when tracking defects?
To me, test time is the time when the actual tests run and not anything else. In this case, both the errors and execution time I'd add as 'compile' time, time which is used in generating and running the code.
If a test case encounters a syntax error, is that considered a code defect, a compile defect, or a test defect? The test actually found the error, but it is a code problem.
Syntax errors are code defects.
If an IDE identifies an error that would prevent compilation before actually compiling, should that be identified? If so, should it be identified and tracked as a compile error or a code error?
If the IDE is part of your toolchain, then it seeing errors is just like yourself having spotted the errors, and thus code errors. If you don't use the IDE regularly, then I'd count them as compile errors.
I've used PSP for years. As others have said, it is a personal process, and you will need to evolve PSP0 to improve your development process. Nonetheless, our team (all PSP-trained) grappled with these issues on several fronts. Let me give you an idea of the components involved, and then I'll say how we managed.
We had a PowerBuilder "tier"; the PowerBuilder IDE prevents you from even saving your code until it compiles correctly and links. Part of the system used JSP, though the quantity of Java was minor, and boilerplate, so that in practice, we didn't count it at all. A large portion of the system was in JS/JavaScript; this was done before the wonderful Ajax libraries came along, and represented a large portion of the work. The other large portion was Oracle Pl/Sql; this has a somewhat more traditional compile phase.
When working in PowerBuilder, the compile (and link) phase started when the developer saved the object. If the save succeeded, we recorded a compile time of 0. Otherwise, we recorded the time it took for us to fix the error(s) that caused the compile-time defect. Most often, these were defects injected in coding, removed in compile phase.
That forced compile/link aspect of the PowerBuilder IDE forced us to move the code review phase to after compiling. Initially, this caused us some distress, because we weren't sure how/if such a change would affect the meaning of the data. In practice, it became a non-issue. In fact, many of us also moved our Oracle Pl/Sql code reviews to after the compile phase, too, because we found that when reviewing the code, we would often gloss over some syntax errors that the compiler would report.
There is nothing wrong with a compile time of 0, any more than there is anything wrong with a test time of 0 (meaning your unit test passed without detecting errors, and ran significantly quicker than your unit of measure). If those times are zero, then you don't remove any defects in those phases, and you won't encounter a div/0 problem. You could also record a nominal minimum of 1 minute, if that makes you more comfortable, or if your measures require a non-zero value.
Your second question is independent of the development environment. When you encounter a defect, you record which phase you injected it in (typically design or code) and the phase you removed it (typically design/code review, compile or test). That gives you the measure called "leverage", which indicates the relative effectiveness of removing a defect in a particular phase (and supports the "common knowledge" that removing defects sooner is more effective than removing them later in the process). The phase the defect was injected in is its type, i.e., a design or coding defect. The phase the defect is removed in doesn't affect its type.
Similarly, with JS/JavaScript, the compile time is effectively immeasurable. We didn't record any times for compile phase, but then again, we didn't remove any defects in that phase. The bulk of the JS/JavaScript defects were injected in design/coding and removed in design review, code review, or test.
It sounds, basically, like your formal process doesn't match your practice process. Step back, re-evaluate what you're doing and whether you should choose a different formal approach (if in fact you need a formal approach to begin with).
In interpreted languages, there is no compile time. However, there might be problems in execution. Is executing the script, outside of the unit (and other) tests, considered "compile" or "test" time? Should errors with execution be considered "compile" or "test" errors when tracking defects?
The errors should be categorized according to when they were created, not when you found them.
If a test case encounters a syntax error, is that considered a code defect, a compile defect, or a test defect? The test actually found the error, but it is a code problem.
Same as above. Always go back to the earliest point in time. If the syntax error was introduced while coding, then it corresponds to the coding phase, if it was introduced while fixing a bug, then it's in the defect phase.
If an IDE identifies an error that would prevent compilation before actually compiling, should that be identified? If so, should it be identified and tracked as a compile error or a code error?
I believe that should not be identified. It's just time spent on writing the code.
As a side note, I've used the Process Dashboard tool to track PSP data and found it quite nice. It's free and Java-based, so it should run anywhere. You can get it here: http://processdash.sourceforge.net/
如果 IDE 发现错误 之前会阻止编译 实际编译，应该是 确定了？如果是的话，应该是 作为编译进行识别和跟踪 错误还是代码错误？
如果 IDE 识别出语法错误，则与您在执行之前实际发现错误相同。正确使用 IDE，几乎没有任何借口可以让影响执行的缺陷（例如，导致除逻辑/实现错误之外的应用程序执行错误）通过。
After reading the replies by Mike Burton, Vinko Vrsalovic, and JRL and re-reading the appropriate chapters in PSP: A Self-Improvement Process for Software Engineers, I've come up with my own takes on these problems. What is good, however, is that I found a section in the book that I originally missed when two pages stuck together.
In interpreted languages, there is no compile time. However, there might be problems in execution. Is executing the script, outside of the unit (and other) tests, considered "compile" or "test" time? Should errors with execution be considered "compile" or "test" errors when tracking defects?
According to the book, it says that "if you are using a development environment that does not compile, then you should merely skip the compile step." However, it also says that if you have a build step, "you can record the build time and any build errors under the compile phase".
This means that for interpreted languages, you will either remove the compile phase from the tracking or replace compilation with your build scripts. Because the PSP0 is generally used with small applications (similar to what you would expect in a university lab), I would expect that you would not have a build process and would simply omit the step.
If a test case encounters a syntax error, is that considered a code defect, a compile defect, or a test defect? The test actually found the error, but it is a code problem.
I would record errors where they are located.
For example, if a test case has a defect, that would be a test defect. If the test ran, and an error was found in the application being tested, that would be a code or design defect, depending on where the problem actually originated.
If an IDE identifies an error that would prevent compilation before actually compiling, should that be identified? If so, should it be identified and tracked as a compile error or a code error?
If the IDE identifies a syntax error, it is the same as you actually spotting the error before execution. Using an IDE properly, there are few excuses for letting defects that would affect execution (as in, cause errors to the execution of the application other than logic/implementation errors) through.
发布评论
评论（5）
一般来说，由于 PSP 是一个个人改进过程，只要您选择一个答案并始终如一地应用它，您实际问题的答案并不重要。这样你就能够测量你在每个定义阶段所花费的时间，这就是 PSP 所追求的。如果您的团队集体使用 PSP，那么你们应该就使用哪些脚本以及如何回答问题达成一致。
我对实际问题的看法是（并不是相关的）：
对我来说，测试时间是实际测试运行的时间，而不是其他任何时间。在这种情况下，我将错误和执行时间添加为“编译”时间，即用于生成和运行代码的时间。
语法错误是代码缺陷。
如果 IDE 是您工具链的一部分，那么它看到错误就像您发现错误一样，从而发现代码错误。如果你不经常使用IDE，那么我会把它们算作编译错误。
In general, as the PSP is a personal improvement process, the answers to your actual questions do not matter as long as you pick one answer and apply it consistently. That way you will be able to measure the times you take in each defined phase, which is what PSP is after. If your team is collectively using the PSP then you should all agree on which scripts to use and how to answer your questions.
My takes on the actual questions are (not that they are relevant):
To me, test time is the time when the actual tests run and not anything else. In this case, both the errors and execution time I'd add as 'compile' time, time which is used in generating and running the code.
Syntax errors are code defects.
If the IDE is part of your toolchain, then it seeing errors is just like yourself having spotted the errors, and thus code errors. If you don't use the IDE regularly, then I'd count them as compile errors.
我已经使用 PSP 多年了。正如其他人所说，这是一个个人过程，您将需要发展 PSP0 来改进您的开发过程。尽管如此，我们的团队（全部接受过 PSP 培训）在多个方面解决了这些问题。让我向您介绍一下所涉及的组件，然后我将介绍我们是如何管理的。
我们有一个 PowerBuilder“层”； PowerBuilder IDE 甚至会阻止您保存代码，直到代码正确编译并链接为止。系统部分使用了JSP，虽然Java的数量很少，而且是样板文件，所以在实际中我们根本没有计算在内。系统的很大一部分是用 JS/JavaScript 编写的；这是在出色的 Ajax 库出现之前完成的，并且代表了大部分工作。另一大部分是 Oracle Pl/Sql；这有一个更传统的编译阶段。
在 PowerBuilder 中工作时，编译（和链接）阶段在开发人员保存对象时开始。如果保存成功，我们记录的编译时间为 0。否则，我们记录修复导致编译时缺陷的错误所花费的时间。大多数情况下，这些是在编码中注入的缺陷，在编译阶段删除的。
PowerBuilder IDE 的强制编译/链接方面迫使我们将代码审查阶段移至编译后。最初，这给我们带来了一些困扰，因为我们不确定这样的更改如何/是否会影响数据的含义。在实践中，这不再是问题。事实上，我们中的许多人也将 Oracle Pl/Sql 代码审查移到了编译阶段之后，因为我们发现在审查代码时，我们经常会掩盖编译器报告的一些语法错误。
编译时间为 0 没有任何问题，就像测试时间为 0 没有任何问题一样（这意味着您的单元测试在没有检测到错误的情况下通过了，并且运行速度明显快于您的度量单位）。如果这些时间为零，则您不会删除这些阶段中的任何缺陷，并且不会遇到 div/0 问题。如果您觉得更舒服，或者您的测量需要非零值，您还可以记录名义上的最小值 1 分钟。
你的第二个问题与开发环境无关。当您遇到缺陷时，您可以记录将其注入的阶段（通常是设计或代码）以及将其删除的阶段（通常是设计/代码审查、编译或测试）。这为您提供了称为“杠杆”的衡量标准，它表明在特定阶段消除缺陷的相对有效性（并支持“常识”，即尽早消除缺陷比在流程中稍后消除缺陷更有效）。缺陷被注入的阶段是其类型，即设计或编码缺陷。缺陷被移除的阶段不会影响其类型。
类似地，对于 JS/JavaScript，编译时间实际上是无法估量的。我们没有记录编译阶段的任何时间，但话又说回来，我们没有删除该阶段的任何缺陷。大部分 JS/JavaScript 缺陷是在设计/编码中注入的，并在设计审查、代码审查或测试中删除的。
I've used PSP for years. As others have said, it is a personal process, and you will need to evolve PSP0 to improve your development process. Nonetheless, our team (all PSP-trained) grappled with these issues on several fronts. Let me give you an idea of the components involved, and then I'll say how we managed.
We had a PowerBuilder "tier"; the PowerBuilder IDE prevents you from even saving your code until it compiles correctly and links. Part of the system used JSP, though the quantity of Java was minor, and boilerplate, so that in practice, we didn't count it at all. A large portion of the system was in JS/JavaScript; this was done before the wonderful Ajax libraries came along, and represented a large portion of the work. The other large portion was Oracle Pl/Sql; this has a somewhat more traditional compile phase.
When working in PowerBuilder, the compile (and link) phase started when the developer saved the object. If the save succeeded, we recorded a compile time of 0. Otherwise, we recorded the time it took for us to fix the error(s) that caused the compile-time defect. Most often, these were defects injected in coding, removed in compile phase.
That forced compile/link aspect of the PowerBuilder IDE forced us to move the code review phase to after compiling. Initially, this caused us some distress, because we weren't sure how/if such a change would affect the meaning of the data. In practice, it became a non-issue. In fact, many of us also moved our Oracle Pl/Sql code reviews to after the compile phase, too, because we found that when reviewing the code, we would often gloss over some syntax errors that the compiler would report.
There is nothing wrong with a compile time of 0, any more than there is anything wrong with a test time of 0 (meaning your unit test passed without detecting errors, and ran significantly quicker than your unit of measure). If those times are zero, then you don't remove any defects in those phases, and you won't encounter a div/0 problem. You could also record a nominal minimum of 1 minute, if that makes you more comfortable, or if your measures require a non-zero value.
Your second question is independent of the development environment. When you encounter a defect, you record which phase you injected it in (typically design or code) and the phase you removed it (typically design/code review, compile or test). That gives you the measure called "leverage", which indicates the relative effectiveness of removing a defect in a particular phase (and supports the "common knowledge" that removing defects sooner is more effective than removing them later in the process). The phase the defect was injected in is its type, i.e., a design or coding defect. The phase the defect is removed in doesn't affect its type.
Similarly, with JS/JavaScript, the compile time is effectively immeasurable. We didn't record any times for compile phase, but then again, we didn't remove any defects in that phase. The bulk of the JS/JavaScript defects were injected in design/coding and removed in design review, code review, or test.
基本上，听起来您的正式流程与您的实践流程不符。退后一步，重新评估您正在做的事情以及是否应该选择不同的正式方法（如果实际上您需要一个正式的方法）。
It sounds, basically, like your formal process doesn't match your practice process. Step back, re-evaluate what you're doing and whether you should choose a different formal approach (if in fact you need a formal approach to begin with).
错误应根据错误创建时间而不是发现时间进行分类。
与上面相同。总是回到最早的时间点。如果语法错误是在编码时引入的，那么它对应于编码阶段，如果它是在修复错误时引入的，那么它处于缺陷阶段。
我认为不应该识别这一点。只是花时间写代码而已。
附带说明一下，我使用 Process Dashboard 工具来跟踪 PSP 数据，发现它非常好用。它是免费的并且基于 Java，因此它应该可以在任何地方运行。您可以在这里获取：
http://processdash.sourceforge.net/
The errors should be categorized according to when they were created, not when you found them.
Same as above. Always go back to the earliest point in time. If the syntax error was introduced while coding, then it corresponds to the coding phase, if it was introduced while fixing a bug, then it's in the defect phase.
I believe that should not be identified. It's just time spent on writing the code.
As a side note, I've used the Process Dashboard tool to track PSP data and found it quite nice. It's free and Java-based, so it should run anywhere. You can get it here:
http://processdash.sourceforge.net/
阅读 Mike Burton、Vinko Vrsalovic，以及JRL并重新阅读在《PSP：软件工程师的自我改进过程》中的相应章节中，我对这些问题提出了自己的看法。然而，好的一点是，我在书中找到了我最初在两页粘在一起时错过的部分。
根据该书，它说“如果您使用的开发环境无法编译，那么您应该跳过编译步骤”。但是，它还表示，如果您有构建步骤，“您可以记录构建时间以及编译阶段下的任何构建错误”。
这意味着对于解释型语言，您可以从跟踪中删除编译阶段，或者用构建脚本替换编译。因为 PSP0 通常用于小型应用程序（类似于您在大学实验室中所期望的），所以我希望您不会有构建过程，并且只需省略该步骤。
我会记录错误所在的位置。
例如，如果测试用例有缺陷，那就是测试缺陷。如果测试运行，并且在正在测试的应用程序中发现错误，则这将是代码或设计缺陷，具体取决于问题的实际根源。
如果 IDE 识别出语法错误，则与您在执行之前实际发现错误相同。正确使用 IDE，几乎没有任何借口可以让影响执行的缺陷（例如，导致除逻辑/实现错误之外的应用程序执行错误）通过。
After reading the replies by Mike Burton, Vinko Vrsalovic, and JRL and re-reading the appropriate chapters in PSP: A Self-Improvement Process for Software Engineers, I've come up with my own takes on these problems. What is good, however, is that I found a section in the book that I originally missed when two pages stuck together.
According to the book, it says that "if you are using a development environment that does not compile, then you should merely skip the compile step." However, it also says that if you have a build step, "you can record the build time and any build errors under the compile phase".
This means that for interpreted languages, you will either remove the compile phase from the tracking or replace compilation with your build scripts. Because the PSP0 is generally used with small applications (similar to what you would expect in a university lab), I would expect that you would not have a build process and would simply omit the step.
I would record errors where they are located.
For example, if a test case has a defect, that would be a test defect. If the test ran, and an error was found in the application being tested, that would be a code or design defect, depending on where the problem actually originated.
If the IDE identifies a syntax error, it is the same as you actually spotting the error before execution. Using an IDE properly, there are few excuses for letting defects that would affect execution (as in, cause errors to the execution of the application other than logic/implementation errors) through.