问题标签 [methodology]

省略计算素数的方法和分解方法的细节。

为什么要分解？

它的应用有哪些？

大约 5 年前上坡时，我的职业生涯还算顺利，但分离、家人的死亡和一些疾病使我做出了几个糟糕的职业决定，我最终进入了一个死胡同的工作，主要是做 vb 6，虽然它是30 年中下旬结束，但最近休息了，与一家具有前瞻性的 vb.net 公司合作，我双手抓住了机会，到现在已经 5 个月了

事情进展顺利，花了很多时间在这样的地方，阅读书籍，但是来自 C / 机器代码 / VB 5 &6 背景，如果我写的话，我会发现 .NET 的一点内向性在我身上迷失了例如，我不认为使用委托的代码，有没有人对使“大脑”VB.NET 跳跃或我应该关注的培训有任何建议（请记住，我并不富有）

谢谢你的时间

我相信敏捷不过是螺旋模型的另一种实现。我是 Spiral 的大力支持者（螺旋模型是一个软件开发过程，结合了设计和原型设计阶段的元素，努力结合自上而下和自下而上概念的优势），并且已经看到许多项目在不知道它们在螺旋世界中运行的情况下实施螺旋。从敏捷开始流行的那一天起，螺旋的概念就开始被忽视了。我确信对于复杂的项目螺旋仍然是最好的选择，但我想更好地了解敏捷和螺旋技术之间的异同。谁能解释他们的差异/相似之处？

我似乎是少数，但老实说我对 linq 不太满意，也看不到我个人发展的任何好处（不是说没有好处，只是根据我的情况提出的个人意见）。

我构建 Web 应用程序（.net、.net mvc）并且我喜欢在存储过程中包含我的部分数据层。我喜欢 sprocs 的一件事是，我可以生成整个数据库以编写脚本，然后扫描我的查询，我可能添加的可读查询，在高级别。

对于那些不喜欢linq的人，你的理由是什么？只是缺乏知识/学习曲线，还是有不使用它的商业案例？

基本步骤是Agile software development什么？
以及如何使用敏捷方法开始一个新项目？

问候。我现在一直在看文学编程，我确实喜欢它背后的想法：你基本上写了一篇关于你的代码的小论文，并写下尽可能多的设计决策，代码可能围绕模块，内部工作由设计决策、潜在扩展产生的模块、假设和结论，所有这些都可以使用 tex 以一种很好的方式写下来。当然，第一点：它是文档。它必须保持最新，但这不应该那么糟糕，因为你的改变应该有一个理由，你可以把它写下来。

但是，文学编程如何在更大程度上扩展？总的来说，文学编程仍然只是文本。当然，文本是人类可读的，但仍然是文本，因此很难遵循大型系统。例如，我修改了编译器的大部分以使用 >> 和一些魔法将编译步骤链接在一起，因为一些 "x.register_follower(y); y.register_follower(z); y.register_follower(a);... " 变得非常笨拙，将其更改为 x >> y >> z >> a 使它变得更好一些，即使这也处于临界点。

那么，文学编程如何扩展到更大的系统？有人尝试这样做吗？

我的想法是使用 LP 来指定使用事件流相互通信的组件，并使用 graphviz 的子集将所有这些链接在一起。这将是 LP 的一个相当自然的扩展，因为您可以从网络中提取文档——数据流图——并且还可以很好地从中生成代码。你怎么看呢？

——特萨。

（这不是一个调查 TDD 优点的问题。还有其他地方可以进行此类讨论。提前致谢。）

我遇到过太多不熟悉该技术的开发人员，他们也报告对测试驱动开发和 NUnit 不满意。

我听到一些负面评论，例如：

• “我不喜欢 NUnit。 我在一年前尝试过，但我忘记了如何使用它。让我们使用我刚刚编写的这个 Windows 窗体应用程序作为测试工具。无论如何，测试代码都是一次性代码，什么是有什么区别？反正我过去的方法还不错。

• “我对 TDD 持保留意见。在我们的最后一个项目中（顺便说一句，这是我第一次也是唯一一次使用 TDD 的项目经验），我们甚至不知道设计是什么。”

• “更多的代码注释很糟糕？你疯了吗？如果你不介意的话，我真的有一些工作要做。” （来自老派的更多评论是更好的评论，你永远不会有太多评论。）

当一个新手抱怨说 TDD 在他们的第一个使用 TDD 的项目中“没有工作”令他们满意时，是 TDD 真的让他们失望了，还是开发人员自己的技能还不足以获得好的结果？

如果他们不恨我这么说，我怎么能沟通呢？

问题的关键是，可以通过哪些外交手段与开发人员进行沟通，以鼓励他们更诚实地评估自己在新开发技术方面的新生和不足的能力，而不会危及我们重要的工作关系？

通常，许多开发人员显然还没有掌握 TDD 的许多重要元素，以便在他们的第一个项目中很好地完成它。

例如，与我交谈过的开发社区中的抱怨者很典型：

• 甚至从未尝试查看或记住代码异味列表。

• 甚至从未尝试研究重构目录，也从未在实际项目或玩具项目中实践过重构目录。对于某些人来说，可能需要学习更多的 OOP，以便能够很好地进行重构。重构不仅仅是“重命名方法”和“重命名变量”，它们显示为 Visual Studio 2005 重构菜单上的项目。

• 甚至从未尝试过研究或参与使用紧急设计（通过重构）实现的实际项目，与预先使用设计完成整个项目相比，与仅在编写代码后才编写单元测试的整个项目相比，并且知道差异和它们之间的权衡和适用性。

他们似乎都曾经使用过 NUnit，所以无论他们用它做什么，都是 TDD，天哪，他们似乎认为。NUnit 或单元测试的存在并不意味着 TDD，但他们还不够了解，甚至不知道这一点。

这些都是聪明人。开发人员是聪明人，因为这是进入整个职业的门槛。否则你不能在这个职业中呆太久。当然，如果他们花时间研究这些材料，他们就可以理解。

当他们的经验和知识的总和显然太弱以至于无法对方法或其结果进行评估时，人们怎么能诚实地告诉自己方法论很弱呢？

然而他们确实……我相信这是一种自我保护的行为。或者是懒惰。如果你甚至无法从 Fowler 的重构书目录中说出三个重构，或者如果你无法说出几个代码异味，那么你就是重构的新手，并且可能也是整个 TDD 方法论，以及你所谓的 1或者2个项目经验显然是不够的。

我可以对人们说些什么，或者我可以引导人们关注哪些材料，以让他们做必要的事情来更多地了解 TDD 成功所依赖的技能，例如：

• 单元测试，
• 重构，
• 设计模式，
• OO设计和分析？

关于这些主题中的每一个都有整本书，有些非常好。也许也有一些更容易接受的学习技巧？我可以以身作则，但我自己给他们的时间是有限的，而且我还不是所有这些技术的黑带。

此外，他们一起去。没有彼此，它们就不能很好地工作。单元测试和重构就像花生酱和果冻一样。如果你不能 grep 单元测试，那么你的重构肯定不会有很好的结果！（问我为什么如果你还不知道，我很乐意向新人解释。）

同样重要的是，无论我做什么或说什么，都不会适得其反：

我不能让我的同事疏远 TDD 概念；此外，我绝不能疏远我的同事。 在接下来的许多年里，我将不得不每周与他们一起工作。

很难不让其他长期资深的开发人员感到不安，他们已经证明自己在编程的其他方面非常精通。他们理所当然地为自己过去的成就感到自豪，但是他们的自尊心或他们对编程中所有事情的掌握的自我概念几乎是无法克服的，而不会伤害他们的感情。一些高级开发人员还没有准备好面对他们不知道应该向其他人学习的一些新技术。在编程方面，高级开发人员可以更习惯和更自在地成为房间里的专家，有时他们要求被视为专家，即使在涉及 TDD 和相关技术和技术时这完全不现实。

我很高兴地报告说，在编写结构化自动化单元测试方面，我在扭转我们的常驻“反对者”之一方面取得了相当大的成功，一种方法是与他们一对一地使用结对编程。我猜，结对编程为学员提供了一些现实生活中的例子和经验，以及更有经验和知识渊博的从业者的直接指导。

但是结对编程是不够的。他们需要学习更多的重构、代码异味、OOP 概念和 OOD&A 概念，而我无法在一个项目中教授所有这些，甚至不能接近。

我是 Scrum 新手，虽然我了解 Sprint 背后的团队概念，但我想仍然需要一个团队的监护人，以尽量减少不熟悉软件开发的产品负责人的干扰。你的成功是什么，你经历过哪些恐怖故事？

更新：

我正在寻找实现业务流程的编码与为客户创建适当的架构之间的平衡。如果产品负责人来自业务部门，则必须指导应该在数据模型上花费多少时间等。

定义：

我所说的“失控”产品负责人通常是指业务部门中的某个人，他们积极设定时间框架，但没有真正的技术能力来创建该估计。通常这个人会说：“在下周与运营委员会的下一次会议之前，我需要这些屏幕，所以首先优先考虑这些工作产品。我们将在与运营部交谈后处理数据库。”

每个人都很好的答案。谢谢你的好意见。

我不确定“先测试”是如何工作的，我想听听关于何时以及为何采用这种方法的争论。

我听说通常建议在编写单行实现之前编写测试和模拟事物。但是，我不禁认为它并不适合所有情况。例如，假设我正在制作一个原型，但我还不确定一切将如何工作。所以我只是开始寻找我认为我需要的每个步骤的示例并将它们放入我的代码中。最后，我证明了我的理论，并没有花那么长时间。这本质上是“我的测试”。这不是单元测试，而是测试（很可能是控制台应用程序）。

这几乎就是我的工作方式。我想我想做什么并尝试去做。如果它有效，那么我最终会回去编写单元测试，以便我可以捕获回归。这与您“应该做的”不同吗？

在我公司的每个项目中，我们通常有 1-4 名开发人员/艺术总监/文案，您建议使用什么方法？敏捷？经验？Scrum？还有什么？（我知道它们都是本质上相同概念的变体，是的）