记录好的软件开发的关键要素?[闭门]

是的,我做过一次。没有帮助。

我认为软件开发很难,列出这四个概念,无论多么重要,都无法提高组织中代码的质量。你真正需要的是积累知识和经验。如果我必须列出一份清单,它将包括:

• 接受 . 如果一个编码员不同意这一点,您可能会遇到麻烦。
• 做代码审查。这将解决您列出的大多数问题,并具有许多其他优点。
• 交流你正在做的事情——越频繁越好。把你的自尊心放在一边,毫不犹豫地向你的资深同事征求意见。如果您是一名高级开发人员,请听取您的年轻同行的意见,他们通常更了解最新的技术、想法、实践和习惯用法。
• 尊重你的代码库。每一行代码都很重要,必须是正确的。

所有这些都是人为因素。我认为这是一个组织中更好的编程之路的起点。

我也在一条类似的船上:为开发人员编写文档。面对现实,他们不会读,如果读了,他们也不会应用这些原则。你需要带头进行小规模的培训,向他们展示你的意思/期望。我这样做非常成功。与高级开发人员进行1-2小时的小会议。我们研究了好代码和坏代码,并进行了讨论 为什么? 这是好是坏。

这是需要教授和解释的。

有些人不能(或不会)从书本上学习。如果他们做不到,那么你需要发现这些人,如果他们值得你花时间投资的话,你需要帮助他们。如果他们不考虑解雇他们,因为他们只是在浪费。 你的 时间

这些概念在你实际使用之前是短暂的(更好) 不要使用它们

作为一名架构师,你有责任让这些事情发生,如果你需要用流行语继续下去的话,那就去做吧。

在您的级别上,实际代码只是一个实现细节, 这 是 重点。

只要放一份 Code Complete 2

您提到的内容对任何开发人员来说都应该是显而易见的,但他们往往在开始键入时就忘记了这一点。根据我的经验,这些指导原则将帮助您改进:

• 拥有一个自动构建系统,该系统可以构建整个产品,为通宵生产做好准备

重要提示:这些是 指导方针 不 . 准则在不断变化的环境中起作用,而规则则不起作用。

推理:编写测试时,需要抽象类。您会自动开始隐藏内部细节,因为其他任何东西都会使您的测试更加复杂。

夜间构建系统将帮助您在24小时或更短的时间内发现bug。若你们在早上发现你们昨天工作的东西坏了,你们很可能还记得你们在做什么。这将使查找和修复问题变得更加容易。

至于代码覆盖率:您将需要20%的时间来编写覆盖80%代码的测试,80%的时间来编写测试,接下来的10%和1000%的时间(十次)才能得到100%(或者说99.999%)。如果您真的做到了这一点,那么每一次代码更改都会破坏太多的测试,您将停止测试。最终,80-90%的覆盖率将为您带来更好的投资回报率。

我还建议阅读以下内容: Thoughts on Developer Testing

在我看来,您的问题过于关注源代码。源代码是开发过程的最终结果。我认为您还应该关注-过程,即软件是如何开发的。

• 开发过程中的活动是什么,可以定义哪些阶段和里程碑?
• 谁参与了开发过程,他们的角色是什么?
• 不同活动的最终交付物是什么,例如设计文档、图表、演示、手册、源代码、二进制文件等?
• 谁负责每个阶段?

此外,对于每个开发活动,可以指定一些工具来支持开发团队,例如:

• 设计理念的展示和辩论
• 问题列表和bug跟踪程序
• 版本管理
• 等