我有点担心这可能是重复的，但我搜索了网站，我能找到的每个问题似乎都更侧重于功能规范而不是技术规范。
我正在寻找有关如何沟通如何应该完成某些事情的信息，而不是应该做什么。我认为在最简单的层面上，我正在寻找最好的方法来帮助向初级编码员解释实现功能规范的正确方法。
关于文档的大多数答案似乎都假设，一旦给出详细的需求列表，开发人员就会知道实现它的最佳方式，而且我倾向于发现通常情况并非如此。到目前为止我发现的最好的资源似乎是史蒂夫麦康奈尔的10 *软件开发，但我想知道是否有其他人有一些有用的答案。
答案 0 :(得分：10)
我打算建议以Painless Functional Specifications - Part 1: Why Bother?开头阅读Joel的系列。他甚至还有Project Aardark specification（现在是Copilot）的链接，您可以下载并阅读这些链接，作为制作良好规范的示例
有一点：您在帖子中提到了技术和功能规范。有区别。
你正在谈论它看起来像编码标准的问题。
我个人赞成基于Wiki的纯技术设计文档方法。开发人员jsut不喜欢编写大型Word文档。 Wiki允许您编写内容，协作，插入类图或任何适当的内容。
我发现了一些关于此的更多信息，就像这个关于technical vs functional specifications的帖子一样，Joel写道：
我的思维方式就是你 不要写“技术规格” 涵盖了整个功能 应用......就是这样的 功能规范是为了。一旦你有了 一个完整的功能规格唯一 留给文件的东西是点 内部架构和具体 算法是（a）完全 看不见的（在封面下）和（b） 功能不够明显 规格。
所以技术规范最终没有结束 现有。在它的位置你或许可以 没有一些技术文章 小主题：
和
记住，如果你在谈论什么 关于影响用户界面或 甚至你所做的事情的行为 建筑，它在功能上 spec ...所以剩下的就是这些了 技术规范就是这样的 完全是利益 程序员，事实上，很多 那些东西可能是最好的评论， 所以最多，你应该有一把 关于主题的短篇文章 算法 - 你写那些 需要的文章 通过设计或文档来思考 未来的“大局” 程序员所以他们没有必要 弄清楚你的代码正在尝试什么 完成。
它比我更有说服力地描述它。
答案 1 :(得分：8)
有趣的是，我认为这个问题会得到许多有争议的答案，相反，我们得到的建议是编码标准可以解决问题，或者让开发人员继续使用它就是答案。从这个问题来看，我认为关键是我们正在谈论初级编码员，当你开始从功能规范到完成代码的巨大跳跃时，我们都知道有不止一种方法可以做到这一点。 / p>
我的方法是采用系统的一个特定部分，运用所有技术层 - DB，UI，Web服务，并记录应该如何实现，可能使用类图，也许只是建议特定的库和方法。通过这种方式，您的技术规范不会太大，可以称赞并扩展架构文档（如果您不需要太多的doco，可以将其作为项目符号列表）。
团队可以完全实现系统的垂直切片，它具有许多优点，您可以尽早构建和发布小切片，体系结构得到验证，迭代0内容（源代码控制，版本控制，构建）全部被执行 - 这只是做到这一点的方式。
答案 2 :(得分：4)
两个想法：
我所知道的有关提议实现的最有用的方法是使用类图和序列图。
我认为即使是初级开发人员也应该负责创建初始描述。考虑问题空间，然后接受对设计的批评，将更快地发展他们的能力。
答案 3 :(得分：2)
我认为这归结为某些设计基础：
你描述的内容表明他们没有对专业人士和骗子做出好的（如果有的话）分析。最后，它归结为Junior的自身能够收集正确的信息然后做出正确的决定。这可能涉及要求更高级的程序员; - ）
决定最佳选择的设计方法的一些示例：
答案 4 :(得分：1)
通过编码标准，代码审查以及可能的静态分析工具（如FxCop），您可以获得更多功能规格。代码可以基于合理的架构，但由于本地级别的不良风格而变得难以改变。