Questions tagged «methodology»

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 看起来，即使开发人员工具变得更加牢固和强大，编写好的代码也已成为挑战。即使这些工具功能更强大，代码质量也没有得到改善。我提出了两个重要因素，时间更少，项目更复杂。由于我们今天使用的工具功能更强大，因此更容易编写更复杂的代码，但是由于没有时间进行计划并且不回头，会降低代码质量，并增加错误和维护量。并不是说我们以前没有编写复杂的代码。是我们编写了更复杂的代码。 我的问题是：考虑到我们拥有更强大的语言和工具。 为什么编写好的代码更加困难？ 因素，时间和复杂性是否对此有所贡献？ 方法是否正确实施？ 我考虑的项目类型是具有较大复杂性和业务逻辑的企业应用程序。“好代码”的定义是个人的，请不要卡在“好代码”的解释中。

19 programming-languages  methodology 

我想问您，关于实施过滤后的搜索表单的意见。让我们想象以下情况： 1个有很多列的大表 可能很重要的一点是，此SQL Server 您需要实现一个表单来搜索此表中的数据，并且在此表单中，您将具有几个复选框，可用于汇总此搜索。 现在，我的问题是，以下哪一项应该是实现搜索的最佳方法？ 创建一个内部带有查询的存储过程。此存储过程将检查应用程序是否提供了参数，如果未提供参数，则将在查询中放入通配符。 创建一个动态查询，该查询将根据应用程序给出的内容进行构建。 我之所以这样问，是因为我知道SQL Server在创建存储过程时会创建执行计划，以优化其性能，但是通过在存储过程内部创建动态查询，我们会牺牲执行计划获得的优化吗？ 请告诉我，您认为最好的方法是什么。

17 database  sql  sql-server  methodology  development-approach 

在过去的三年中，我一直在开发软件，但是最近我才意识到自己对良好实践的无知。这使我开始阅读《清洁代码》一书，这使我的生活变得更好，但我一直在努力了解一些编写程序的最佳方法。 我有一个Python程序，其中... 使用argparse required=True强制使用两个参数，它们都是文件名。第一个是输入文件名，第二个是输出文件名 具有readFromInputFile首先检查输入文件名已被输入的功能 具有writeToOutputFile首先检查查看输入的文件名的功能 我的程序很小，导致我相信＃2和＃3中的检查是多余的，应将其删除，从而将这两个功能从不必要的if条件中解放出来。但是，我还被认为“双重检查是可以的”，并且可能是一个程序的正确解决方案，在该程序中可以从不进行参数解析的其他位置调用函数。 （此外，如果读取或写入失败，我try except在每个函数中都有一个引发相应的错误消息。） 我的问题是：最好避免所有冗余条件检查？程序的逻辑是否应该如此扎实，以至于检查只需进行一次？有没有很好的例子说明这一点或相反的情况？ 编辑：谢谢大家的答案！我从每个人那里学到了一些东西。看到如此多的观点使我对如何解决这个问题以及根据我的需求确定解决方案有了更好的理解。谢谢！

16 clean-code  methodology 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引文回答。 4年前关闭。 在我的公司中，我发现有些日子要做的工作很少。这些年来，我很想进行研究以了解有关手工艺的新知识。 我要说的是，平均而言，我每周大约有一天没有什么事情要做（或一周中的某些时间组合）。 我想知道这是否是软件开发环境中的常见情况，这个问题的答案在全职工作和合同工作之间是否有所不同？

16 self-improvement  methodology 

刚开始编程时，我非常依赖流程图（和打印机间距图）。当我在COBOL课堂上时，直到我的流程图被教员批准后，我才能开始编写任何代码。那时，我必须为所有内容制作流程图。 今天，二十五年后，我发现自己只绘制了两种情况。逻辑很棘手的非常具体的算法或非常笼统的概念，以确保我按正确的顺序定义了所有重要步骤。 我只是忽略了流程图的其他用例吗？

14 design  methodology  flowchart 

一个团队经常（每周一次）遇到发布软件的困难。以下是典型的发布时间表： 在迭代过程中： 开发人员在基于master分支的短时（强烈执行）功能分支的待办事项上处理故事。 开发人员经常将其功能分支拉入集成分支，该集成分支会自动不断构建和测试（就测试覆盖范围而言）。 测试人员可以自动将其集成到暂存环境中，并且每周进行多次，从而可以持续运行他们的测试套件。 每逢星期一： 有一次发布计划会议，以确定哪些故事是“已知的好”（基于测试人员的工作），因此将在发布中。如果故事存在已知问题，则将源分支从集成中撤出。 在本周一，不得将任何新代码（仅测试人员要求的错误修复）用于集成，以确保测试人员具有稳定的代码库来减少发布。 每逢星期二： 测试人员已经在可能的时间范围内尽可能多地测试了集成分支，并且没有已知的错误，因此将发行版剪切并缓慢地推送到生产节点。 在实践中这听起来不错，但是我们发现很难实现。小组看到以下症状 在生产环境中发现了在过渡环境中未发现的“细微”错误。 最后一分钟的热修复程序一直持续到星期二。 生产环境中的问题需要回滚，这会阻止继续开发，直到成功完成实时部署并且可以更新master分支（并由此分支）为止。 我认为测试覆盖范围，代码质量，快速回归测试的能力，最新更改和环境差异都在这里发挥作用。谁能提供有关如何最好地实现“连续”交付的任何建议？

14 methodology 

一些背景资料 我是内部软件开发团队的一员。它包括 5位开发人员（经验从2到5年不等，我是其中之一） 3名实施人员（他们进行软件部署和培训） 和一名项目经理。 我们开发了大量的中小型项目，它们的时间表通常重叠。开发过程如下： “客户”给我们提出了一系列初步要求 我们按照上述规范开发系统 向“客户”展示所述系统 “客户”根据上述介绍向我们提出了其他要求 重复2-4，直到“客户”用完新要求或部署目标日期临近 设置和部署系统 这与事实是，大多数情况下都是由“客户”来处理最后期限（这是一个危险信号，根据我在Programmers和PM.SE中的了解），我们没有遵循明确的开发方法牛仔编码，几乎不可维护的代码以及通过生产而产生的错误等。这就是为什么我们选择采用像Scrum这样基于敏捷的方法。 为什么是Scrum？ 这是我们经理的倡议，鉴于我们目前的情况，每个人似乎都对此表示同意。 Scrum的问题 Scrum的某些元素与我们目前无法轻松解决的设置存在冲突，特别是敏捷开发人员的“万事通”性质。部署团队不知道如何编程，开发人员的沟通和培训技能低于平均水平。而且这个阵容不会很快改变。 问题 它会影响Scrum作为一种方法的有效性吗？是否需要进行其他更改以补偿？还是完全放弃这种想法而考虑另一种方法会更好吗？

13 agile  scrum  methodology 

我在一家制造工厂工作，该工厂负责IT部门创建车间调度程序（非常需要）。根据其他经验，最好花更少的时间来构建可用的基本框架，然后在基础上通过添加功能或通过立即创建完全实现的解决方案来开始构建。我只从事开发工作大约一年，对于最初创建这种大小的应用程序没有太多经验。我一直倾向于这样一种想法：准系统应用程序是第一种应运而生的方法，这是由于对某种类型的数字时间表的极端需求，但我担心在事实之后添加随机功能可能会有些混乱。如果您处在相同的情况下，您会选择哪条路？

11 design  theory  methodology 

在某些组织中，采用敏捷可能会失败，我什至在一家公司（瀑布式）是唯一（真正）方法的工作，但这仅仅是因为他们在项目上尝试了敏捷并失败了。 当我问那些仍然记得（我还是大三）的人时，我很难过，就像我提醒他们一场噩梦一样，这确实发生了。 我不知道为什么项目失败了。网上可以找到一些资源，为什么有些公司会导致Agile失败，但原因主要是经济上的。所以我想在此先提出一些反馈。 在某些组织中，敏捷采用失败的原因是什么？或者，另一种表达方式。.要使敏捷成功，您需要做什么？

11 agile  methodology  waterfall  technique 

我今天在infoq上遇到了MDSE的缩写，该信息我可以找到非常不清楚的地方，并且描述中充斥着流行语： MDSE旨在使软件工程师能够在抽象级别上工作，在该级别上，需求，体系结构和设计信息将得到最大程度的排序（就信息“熵”而言）。（将其称为“设计工作产品”）。此外，MDSE应该为工程师提供主要根据其“设计工作产品”条款验证和验证其设计的方法。 显然，每个人都在这样做：（再次从文章中） 我们正处在MDSE时代的曙光中。在接下来的5-10年中，我们将看到向MDSE的重大转变，我认为到此阶段结束时，也许有60-80％的软件将使用基于模型的技术进行设计。 我想对MDSE是什么有一个具体的，无术语的描述。是否像在90年代使用Rational Rose那样绘制UML框并用它生成代码？ （当时，如果有人有使用这些技术生成的软件示例，我真的很想看到一个具体的示例）。

10 methodology 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 假设您必须完全自行开发中等大小的软件。就像是您要完成的个人项目一样。 您将使用什么方法/工具来定义需要开发，学习的内容以及对系统及其详细内容有全局了解的全局？ 基本上是为了保持自己的步调而不会迷路。

10 tools  methodology 

很难说出这里的要求。这个问题是模棱两可，含糊，不完整，过于宽泛或夸张的，不能以目前的形式合理地回答。如需帮助澄清此问题以便可以重新打开， 请访问帮助中心。 8年前关闭。 我喜欢小迭代。我喜欢单元测试。我喜欢代码审查。我不喜欢的是很少或根本没有文档的开始。我一个人吗？我是否只是对该过程有误解？ 任何想法将不胜感激。

10 agile  documentation  methodology 

我正在写一份涉及软件开发方法论的小型研究论文。我一直在研究所有可用的方法论，并且想知道在所有方法论中，是否有任何方法为其他方法论奠定了基础？ 例如，查看以下方法： 敏捷，原型设计，洁净室，迭代，RAD，RUP，螺旋，瀑布，XP，精益，Scrum，V模型，TDD。 我们可以说： 原型，迭代，螺旋和瀑布是其他的“基础”吗？ 还是没有“基础”之类的东西，每种方法都有自己独特的历史吗？ 我当然想在我的研究论文中描述所有方法论，但是我根本没有时间这样做，这就是为什么我想知道哪些方法论可以看作代表。

10 project-management  language-agnostic  project  development-methodologies  methodology 

我曾经在一家专业的咨询公司工作，而我们是根据许多不同的合同条款工作的。当我们可以获得时间和材料项目时，我们使用SCRUM运行了该项目，并在问题跟踪系统中跟踪了积压工作。 但是，大多数时候，我们必须按照固定价格合同交货。这需要一份规格文件作为合同的附录。因此，我们总是最终从规范中批量导入工作项（或更糟糕的是，手动输入）。变更单花费了大量时间来确保所有内容都保持同步，尤其是在项目结束时。 有没有使整个过程保持干燥的方法论或软件工具？我已经做了一些搜索，但显然没有使用正确的术语。我的大多数专业网络都不做固定价格工作。 我愿意接受： 切换我的错误跟踪器或购买插件（当前使用FogBugz）。 遵循不同的开发方法 编写软件来管理规范并更新Bug跟踪器和规范文档（但这听起来可能需要大量工作才能带来可疑的收益） 最后，这真的值得解决吗？在某些项目上，这花费了我们很多时间，但在其他项目上，它并没有最终影响我们。

9 issue-tracking  specifications  methodology