我正在为我们公司的软件开发编写架构和设计文档，其中包含供开发人员遵循的规则和指南。它针对的是J2EE Web应用程序，但我不断提到相同的基本“成分”（缺少更好的词，并避免使用流行语）来引入和捍卫某些选择。
以下是：
包含它们的好处是，当文档没有特别提及某些内容时，很容易指出这些关键因素，因此它们可以作为一种全能的方式。
缺点是反应如“是的，很好，但我只需要知道我需要扩展哪个类来实现这个控制器。”
我是否正确地首先确定和讨论这些一般性问题，或者我应该“坚持这一点”？
答案 0 :(得分：2)
我认为软件开发很难，并且无法列出这四个概念，无论多么重要，都无法提高组织中代码的质量。你真正需要的是建立知识和经验。如果我必须编制一个列表，它将包含：
所有这些都是人为因素。我认为这是在组织中开始更好的编程的道路。
答案 1 :(得分：1)
这是需要教授和解释的事情。
有些人可以从书本中学习，但书籍需要写得好，没有冒犯，但大多数人实际上并不擅长这一点，所以考虑使用现有的经过良好评价的书籍（++代码完成）或许关于哪些章节相关的一些迹象。
有些人不能（或不会）从书本中学习。如果他们不能，那么你需要发现这些人并帮助他们，如果他们值得您投入时间。如果他们不考虑解雇他们，因为他们只是在浪费你的时间。
这些概念是非常短暂的，直到你真正使用它们（更好的是不要使用它们，稍后会意识到它造成多少痛苦而不是第一次做对，并从你的错误中吸取教训）。简单地重述现有的文献，但更糟糕的是没有充分利用你的时间IMO。
答案 2 :(得分：1)
我在类似的船上：为开发人员编写文档。面对现实，他们不会阅读它，如果他们这样做，他们将不会应用这些原则。您需要带头并开展小型培训课程，向他们展示您的意思/寻找方式。我做得非常成功。与资深开发者进行1-2小时的小课程。我们查看了良好的代码，糟糕的代码，并通过为什么进行了讨论，这是好的和坏的。
文档可以作为一个很好的备份，但面对面的学习永远不会被打败。
答案 3 :(得分：0)
作为一名建筑师，你有责任让这些事情发生，如果用流行语来捣乱，那就是它。
在您的级别，实际代码只是一个实现细节， 这一点。
答案 4 :(得分：0)
只需在您的资料库中放置Code Complete 2的副本，然后将您的开发人员指向该处。
答案 5 :(得分：0)
你提到的对于任何开发者来说应该是显而易见的，但他们一旦开始打字就会忘记他们。根据我的经验，这些指南将帮助您改进：
重要提示：这些是指南，而不是规则。指南适用于不断变化的环境，而规则则不然。
推理：编写测试时，需要抽象类。您会自动开始隐藏内部细节，因为其他任何东西都会使您的测试更加复杂。
每晚构建系统将帮助您在24小时或更短时间内发现错误。如果你在昨天早上发现了一些破碎的东西，你很可能还记得你在做什么。这样可以更容易地找到并解决问题。
至于代码覆盖率：你需要20％的时间来编写涵盖80％代码的测试，80％代表编写测试，用于接下来的10％和1000％的时间（10次） 100％（或更确切地说是99.999％）。如果你真的走得那么远，每次代码更改都会打破这么多测试，你将停止测试。最终，80-90％的覆盖率将为您带来更好的投资回报率。
我还建议您阅读：Thoughts on Developer Testing
答案 6 :(得分：0)
在我看来，你的问题过于关注源代码。源代码是开发过程的最终结果。我认为你也应该关注-process-，即如何开发软件。
此外，对于每个开发活动，可以指定一些工具来支持开发团队，例如：
我的经验是，结构化开发过程最终也会有助于提高源代码的质量。例如，当开发人员定期向整个开发团队展示他们的工作时，他们将获得建设性的反馈并向他们的同事学习。更好地理解OO概念（抽象，关注点分离，继承等）的开发人员有机会将他/她的知识转移给他/她的同事。