问题标签 [methodology]

是否可以在没有任何第三方工具的情况下进行 DI？在他们发现一些 DI 框架之前，我已经读过有人用抽象类和接口来做这件事。ID是如何以这种非常基本的形式完成的？

我已经开发了几年，并且对我团队中的一些年长程序员如何在没有任何开发理念的情况下进行设计和实现感到沮丧，这通常会导致开发轨道进一步出现问题，通常是由于缺乏灵活性和有效性。我向我的同事提出了这个问题，他们回答说：“那么，你建议我们使用数百种开发理念中的哪一种？”

这是一个很难回答的问题，因为在自己工作时使用开发理念比在团队中工作要容易得多。我有点偏爱测试驱动开发，因为它似乎为我提供了我的代码正常工作的最大安全感，但是 TDD 确实有其局限性，主要是编写所有测试所需的开销以及确保我们的测试框架没有差距（在团队中工作时很难实现）。我的一个朋友对敏捷统一过程 (AUP) 发誓，拒绝使用其他任何东西。

我的问题是

• 在团队中开发时，您发现哪些开发理念运作良好，它们如何帮助您在预算内按时交付产品？

• 你遇到了什么问题，你是如何克服的？

• 你认为它们甚至是必需的吗？

我刚刚看到一个招聘广告询问“UP 开发方法”

它是什么？

或者 HT 部门的工作规范有误。

我是一名 PHP 开发人员，我的老板快把我逼疯了。他时不时地给我打电话，即使之前的任务还没有完成，他也会给我任务。禁止我与客户会面，并通过口头或电话告诉我不完整的规范，并希望从第一次部署开始就有工作应用程序。任何机构都可以提出一种方法来抑制这些人的热情吗？

我在一家很小的公司里做一个单独的开发人员。我的工作很混乱，我正在寻找使它更有条理的方法。

一个问题是我的项目几乎没有管理。很少有人问我在做什么，或者我是否有任何问题。在某个时候，有人谈论每周状态会议，但那是前一段时间了。似乎如果我想要那样的东西，我必须自己安排这些。有时我对下一步应该做什么有点迷茫，因为我没有任务或明确的时间表。

从书籍和文章中，我发现了许多可能有用的东西。就像有一个好的编码标准（只有一个粗略的风格指南，在我看来有点过时了），代码检查，TDD，单元测试，错误数据库......但在一家小公司似乎没有资源或时间任何不重要的东西。我在嵌入式领域工作的事实似乎只会让事情变得更加复杂。

我觉得还有一种在短时间内偷工减料和快速破解的习惯。这导致未完成和不专业的产品和错误等待在以后出现。我想他们也很难维持。所以，我即将继承一个具有挑战性的代码库，进行需要学习很多新事物的新开发，我想同时尝试为它构建一个流程。最后可能会有所收获，但由于经验不足，我不确定是否可以成功。

在像这样的小商店里，环境远非最适合编程。偶尔还需要做很多其他的事情，比如客户支持、接听电话、签署包裹、硬件测试、组装以及任何可能出现的杂项任务。所以你对资源有了概念。这并不全是坏事（有时解决一些客户问题很有启发性），我相信它可以改进，但这是我真正关心的其他事情。

有可能在这样的地方进行开发吗？

进行某种管理会有所帮助吗？什么样的？

有没有可能用小资源做出优质产品？

我如何让自己和他人相信这家成功运作了几十年的公司需要改变？什么是必不可少的？

也许有人在类似的商店工作？

作为一名软件工程师，我强烈倾向于在应用层编写业务逻辑，而通常只依赖数据库进行 CRUD（创建检索更新和删除）操作。另一方面，我遇到过大量业务逻辑写在存储过程中的应用程序（通常是较旧的应用程序），因此有些人更喜欢在数据库层中编写业务逻辑。

对于拥有和/或喜欢在存储过程中编写/编写业务逻辑的人，您使用此方法的原因是什么？

我有一页（第 1 页），日期为 1989 年 2 月 2 日，是我的前任老板给我的，概述了 Niman 的 13 条最低限度的编程戒律。（他意识到它们已经过时了，这使得这更像是一部考古作品，而不是一套现代指南。）如果你还没有看过它们，它们如下：

1. 您应充分注释您的代码以解释您的意图。人并不仅仅靠记忆法思考。
2. 您应该将数字常量等同于有意义的符号名称。说清楚，避免异教偶像。
3. 你应该描述你的模块中的所有输入和输出。请善待可能需要维护您的模块的软件兄弟姐妹。
4. 你应该充分描述你的修改。期望你的同龄人成为读心者是一种罪过。无论如何，读心术是一种罪过。
5. 你应该提供你的汇编代码的伪代码解释。确实，组装不是 Cobol。
6. 每个模块只能有一个入口点和一个出口点。有许多入口和出口点的人应该期望他们的身体发展相同。
7. 你应该在开发代码之前设计你的代码。确实，确实。
8. 你应该和你的同事一起审查你的代码。温顺的人有福了，因为他们将继承目标代码。
9. 你应该记录你的设计，并让所有维护代码的人都可以使用这些文档。确实，拒绝的人将永远在地狱中调试操作系统。
10. 你应该能够接受对他们代码的有意义的批评。如果你对你的代码感到羞耻，你应该成为一名职业投球手。
11. 在将代码放入库控制之前，您应彻底（原文如此）测试您的代码。圣经中遗漏的一部分是上帝通过调试作为柴油引擎控制器一部分的大型 8096 汇编语言程序来测试约伯。整个东西在发布前没有经过测试。更糟糕的是，乔布不得不使用英特尔工具。
12. 您应尽可能避免使用全局数据结构。塔应该被命名为 Babel，程序不应该。
13. 当您的汇编程序员无法与 20 世纪后期最佳编译代码的效率相匹敌时，您将使用高级语言。当心那些认为汇编总是比好的编译器可以产生的效率更高的假神（就速度和大小而言）。您必须非常擅长设计和编码才能真正利用汇编语言。

我搜遍了互联网，没有透露任何关于这些诫命或尼曼诫命的来源，我一直在试图找出更多关于这一点以及他可能不得不说的任何其他内容的信息。我唯一的其他线索是在左下角，有首字母“DEN”——我假设 N 代表尼曼，但我没有其他东西可以识别文本。所以，

A. 尼曼是谁？（程序员？老师？顾问？公司里随便的人？）

B. 这个页面是从哪里来的？（旧的编程指南？一些公司手册？一些 BBS 过去？）

C. 剩下的在哪里？（还有更多吗？还有什么？这是一个独立的东西吗？）

作为对评论的回应，我的老板已经离开了，但在那之前，他在这个行业待了很长时间，很长一段时间，白胡子什么的。通过纸张的颜色，我相当肯定日期（1989 年）大致是它的印刷日期。

在您看来，谁应该修复错误？程序员，对吧？好吧，但真的，谁……让我解释一下。

我是多个 Scrum 项目的 Scrum Master。Scrum 说“在可能的情况下保护你的资源”，我完全同意这种观点。

通常，我们整合每个 sprint 的某个百分比来修复前一个 sprint 的错误——一切都很好。

在每个 Sprint 之后，我们向客户演示和回顾，并将我们的开发代码推广到 UAT 环境（我们的客户通常不希望他的项目的一小部分上线，但这取决于他们 - 我们保持我们的通过确保我们部署工作和可测试的代码来讨价还价）。

一旦所有 sprint 完成，我们就有一个 UAT 阶段，客户在该阶段对已完成的软件进行彻底测试，以发现任何最后一分钟的错误。现在理想情况下，这些已经被捕获，但实际上有一些只是在 UAT 期间发现的。

在这个 UAT 阶段，并不是所有的开发人员都需要 100% 的时间参与项目，因此我们希望将他们重新分配给其他项目。然而，Scrum 说“在可能的情况下保护你的资源”。

我的问题是，我将开发人员分配到一个项目的 UAT 阶段，同时在其他地方与他们一起启动一个单独的 Scrum 项目。不理想 - 然而，这是目前的商业现实。

我可以：

1) 接受它并让开发人员修复他们自己的代码 - 并将开发人员的一些时间（例如，20%）分配给前一个项目的 UAT。

2) 确保移交到位，并有 1 或 2 名开发人员致力于 100% 的时间修复代码错误。

我喜欢 1)，但它让资源获取真的很痛苦。

2）让我害怕，我觉得开发人员不会对自己代码的质量负责。我觉得在确保开发人员对自己的代码拥有所有权方面有很多话要说——要求他们修复自己的错误是确保质量的好方法。没有人喜欢修复错误，所以我发现开发人员通常会尝试提前做好工作，因为他们知道无论如何他们都必须修复任何提出的问题。然而，2) 更容易规划和资源化。但是 2) 将花费更长的时间，因为修复其他人代码中的错误在时间和资源方面是昂贵的。如果它是一个复杂的修复，它可能无论如何都需要原始开发人员的帮助，并且由不熟悉该部分代码库的人修复肯定需要更长的时间。

人们怎么想？

此线程中引用了 BBD （Karl Seguin 的回答）。什么是 BDD？

您会推荐哪些管理看板的工具？