nwhittier

我对大多数计算机科学毕业生在软件设计/开发技能方面的不足感到非常担忧。这些担忧主要源于在一家新兴创业公司多年来招聘和培训计算机科学毕业生的经验。许多人说计算机科学不是关于软件设计/开发的，虽然这可能是事实，但我认为这是一个问题。

我认为解决这个问题的一个可能方案是将开源参与融入到标准的计算机科学课程中。然而，你的问题让我感到震惊，因为我从未考虑过软件设计的“艺术”的可能性。经过反思，这完全有道理，并且（并非要贬低这个观点或问题）似乎几乎是显而易见的。

我只是想强调你的问题的重要性，并感谢你关于软件开发是科学与艺术之间奇特混合体的深刻见解。

为了尝试对你的问题进行非答案式的回答：我认为它不能完全作为其中任何一种来教授，而应该是两者的某种结合。

这很好地指出了忽略简单步骤是多么容易。

在参与质量保证（QA）时，我对这一点深有体会，在质量保证中，遗漏任何步骤都会导致“已解决：无法重现”的更新，并受到开发人员的鄙视。经过仔细审查，你会意识到在步骤 3 和 4 之间，应该有一个关于使用 Enter 键而不是点击登录按钮（或某些其他可变操作）的说明。

质量保证的关键是确保计算机可以按照你的步骤重现问题（计算机比你的配偶、孩子、表亲、非技术亲戚等更字面化）。我总是假设计算机将尝试重现问题来记录错误。这意味着在对象/细节引用、动词、引号、大小写等方面保持一致。就像在食谱中，如果你反复从“tsp.”切换到“teaspoon”，有人可能会感到困惑或开始自我怀疑。

在最终用户文档中，占位符通常会给用户带来安慰。也就是说，仅仅指出某个部分缺失，或者你的文档中需要更多细节，就能产生巨大的影响。这区别于某人迷路并放弃，以及同一个人意识到他们在被声明为令人困惑的区域迷路了。这种简单的承认可能会导致用户进一步调查（甚至通过电子邮件/IRC/其他方式联系你），而不是直接寻找另一个项目。

正如 Mel 和一些评论所暗示的那样，问题在于假设其他人都和你拥有相同的经验/观点/假设。我也犯了这个错误，现在是时候停止抱怨编写文档了。即使这很痛苦，也要开始更新它，以便任何人都能理解你想说什么。从长远来看，这将节省大家很多时间。

对于我们这些想要参与开源的人来说 - 找到令人困惑的文档，并联系项目参与者来修复它！不要放弃，也不要只是抱怨，这是开始参与的完美途径，而且你可以在此过程中学到很多关于项目的东西。