Questions tagged «development-process»

有关软件开发过程的问题。

1
划分开发堆栈-对角线?
我们正在进行一个新项目,目前开发人员已分为两个团队,即团队A和团队B。该项目有两个部分,需要在整个开发堆栈中进行开发。堆栈的简化示例如下所示: 项目的每个部分都需要在整个堆栈上进行开发,因此我通常希望使用完整的堆栈开发人员方法,这就是我们如何分解团队B中的工作,设计和设计不同部分之间的交互的方式。 但是,我最近了解到,团队A要负责堆栈的某些部分,他们提议在两个团队之间进行划分,其中数据抽象层(并将内容放入数据层)由团队B没有任何发展。这种鸿沟看起来类似于: 对我来说,这感觉很不自然。每个团队都有不同的目标和时间表来实现这些目标,但是B团队将依赖于A团队来实现功能。提出的解决方案是预先定义通用接口(该项目可能需要2年的时间,因此可能会很多)。尽管有自己的目标,团队A仍将尽早为这些接口开发所需的位,而团队B则在短期内取消所有呼叫,以便他们继续前进。 我对此方法感到担忧: 接口可能会更改,并且组A可能没有带宽或时间来适应不断变化的需求。 A团队代码中的错误可能会阻止B团队前进,并且由于A团队的优先级队列不同,它们可能也不是解决这些错误的优先事项。 团队之间缺乏知识传播-团队B可能无法完全了解幕后情况,因此可能会做出糟糕的设计决策。 已经提出,该行业中的许多公司都有子团队,并且必须能够处理此问题。根据我的理解,通常团队会按照最初的期望进行拆分(全栈),或者通过如下分解技术栈: 因此,我有兴趣了解其他行业的情况。大多数拆分是垂直/水平的吗?对角线分割有意义吗?如果发生对角线分裂,我的担忧似乎是成立的,并且B团队还有其他需要关注的问题吗?请注意,我可能要对B团队的成功或失败负责。

1
如何查看代码的哪些部分最常运行?
我希望能够看到成千上万行源代码中的哪些代码运行最频繁且花费时间最长。这样做的目的是为了优化。 能够看到最常运行的代码部分对于优化很重要,因为这些部分是我应该集中精力来加快速度的地方。当然,与此同时,某些代码经常运行,但是几乎不需要时间,因此能够看到哪些代码花费的时间也很重要。 我猜这两个方面最好的是一个程序,该程序可以将一段代码加起来的时间加起来,包括运行该代码的所有时间(从而弄清楚什么会使您的代码整体上最慢)。是否有一种用于此的工具?

3
集成测试中应包括集成测试吗?
假设我们正在开发一个Web应用程序,并且Hudson做一些典型的工作,例如编译,单元测试和静态代码分析。 但是棘手的部分是:一旦完成先前的工作,Hudson就会部署并启动应用程序服务器以进行集成测试。 这意味着一些困难的事情,例如数据库连接,第三部分应用程序连接,套接字端口监听,环境变量,服务器启动故障处理等。我们每次都必须正确地设置和拆除这些东西,这很难。更糟糕的是,集成测试会轻易破坏集成测试。 您认为持续集成(CI)中是否应包括集成测试?可以手动吗?还是简化集成测试?

3
如何仅向少数几个用户推出功能
我想问的一个很好的例子是Facebook的新时间轴功能。开始时,只有少数几个被允许访问时间轴。随着该功能在其工作方式上变得更加牢固并修复了一些错误,允许其他用户访问该功能。后来,允许大量用户访问该功能,现在,所有用户都可以使用该功能。开发团队如何管理这种功能? 我一直在考虑使用配置设置来通过配置文件和代码中的条件if语句有选择地控制访问(如果正在测试或生产中)。现在,尽管可以使用简单的功能,但我相信,如果我们尝试在更大的功能集中实现这一点,将变得难以管理。 以这种方式管理功能推出的最佳方法是什么?

5
什么时候应该创建开发分支?
我们正在将我们的项目团队从使用单个Main / Trunk分支转移到应定期合并到Main中的多个Development / Work分支。我们将基于本文和《TFS分支指南》(我们正在使用TFS和Visual Studio 2010)建立新流程。 目前,任何时候都有1至5个人从事该项目。Main必须始终保持稳定,因为我们希望该选项可以在需要时释放。我们没有固定的冲刺-至少现在还没有-现在每1-2周发布一次。 现在,每个人都在修复整个应用程序中的错误。在几周内,我们将开始为该应用程序开发新的大型组件。 我们发现的一个症结是何时应该创建开发分支。我们将根据开发人员的技能水平并行实施多个用户故事。我们已经考虑过为每个开发人员创建一个分支,但这没有任何意义,因为在一件作品上总会需要一些协作。我们不能只靠一个开发分支,因为我们想在其他工作完成时合并到Main。 有人对此有指导吗?

8
开发大型项目时最大的瓶颈是什么?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 假设我的公司正在开发MS Word的副本(仅作为示例)。假设一个人拥有无限的可用现金并且拥有像Microsoft这样的组织,那么开发过程的瓶颈将是什么?换句话说,快速开发此类软件的最常见障碍是什么?假设所有规格均已就绪并且组织运行良好,那么我们只专注于软件开发,直到产品准备好发货为止。一些替代方法可能是:-编写代码-编写测试-手动测试最终产品-首先由于设计不良而重写代码-设计代码-由经验丰富的开发人员进行代码审查-设计GUI-基于alpha重新设计GUI / beta用户反馈-处理来自用户的反馈-等待alpha / beta用户反馈 请在您的答案中使用参考或陈述您对该主题的经验。

3
将新的JVM编程语言引入已建立的企业环境
想象一下,您当前的工作场所是一家Java商店。有很多有关Java语言的丰富知识,并且有一个完善的构建和部署过程来以流畅,敏捷的方式处理所有事情。 有一天,一个项目问世了,它大声疾呼要用Ruby编写。只有高级开发人员才有关于Ruby的任何线索,但有一个普遍的概念,因为JRuby存在于JVM中,所以可以继续使用和支持现有的基础结构。同样,JRuby可以展示一种以更少的代码实现更好的方式来实现当前应用程序的方法,因此这可能表示正在进行的迁移。 请记住,JRuby只是一个示例,它可以等效地是Clojure或Groovy或在JVM上运行的任何其他程序。 问题是,您将如何引入这种变化-如果有的话?

4
当您有多个并行运行的编程项目时,如何确定任务的优先级?
假设您有5个客户,则每个客户开发2或3个不同的项目。每个项目都有X i个任务。 每个项目需要2到10个工时。 由于资源很少,因此需要最小化管理开销。 在这种情况下的两个问题: 您将使用哪些工具来确定任务的优先级并跟踪其完成,同时又将开销降至最低? 鉴于主要目标是提高吞吐量(每个时间单位完成更多的项目,因此该目标与开始一个项目并完成然后继续进行操作相冲突),您将考虑采用什么标准来确定将哪个任务分配给下一个可用资源下一个)? 欢迎想法,管理技术,算法

4
什么是“过早抽象”?
我听过这个短语被扔掉了,对我来说,论点听起来完全是疯了(对不起,如果我在这里是稻草人,那不是我的意图),通常它遵循以下原则: 您不希望在知道一般情况之前先创建一个抽象,否则(1)您可能会将不属于您的东西放在抽象中,或者(2)忽略了重要的事情。 (1)对我来说,这听起来像程序员不够务实,他们已经假设事情会出现在最终程序中,而事实并非如此,因此他们使用的抽象程度很低,问题不是过早的抽象,它是过早的凝结。 (2)忽略重要的事情是一回事,完全有可能在规范中省略了某些事情,后来证明这很重要,解决这个问题的方法不是在发现自己时就浪费自己的资源和浪费资源。猜错了,这是从客户端获取更多信息。 我们应该始终从抽象到具体工作,因为这是最实用的做事方式,而不是相反。 如果我们不这样做,那么我们可能会误解客户,并创造需要更改的东西,但是如果我们仅构建客户以其自己的语言定义的抽象,那么我们就永远不会遇到这种风险(至少远不及承担风险)是在黑暗中带着某种凝结的镜头),是的,客户可能会改变对细节的想法,但是他们最初用来传达他们想要的内容的抽象往往仍然有效。 这是一个示例,假设客户希望您创建一个物品装箱机器人: public abstract class BaggingRobot() { private Collection<Item> items; public abstract void bag(Item item); } 我们正在从客户端使用的抽象中构建一些东西,而没有涉及我们不知道的事情的更多细节。这是非常灵活的,我已经看到这被称为“过早抽象”,而实际上假设套袋是如何实施还为时过早,可以说与客户讨论后,他们希望一次将多个袋装成袋。为了更新班级,我只需要更改签名,但是对于自下而上的人可能需要进行大范围的系统检修。 没有过早的抽象,只有过早的凝结。这句话有什么问题?我的推理的缺陷在哪里?谢谢。

1
异构开发环境是否有优势?
我与一组开发人员一起工作,他们可以选择运行什么硬件和软件。我们的感觉是,这种情况使我们在进行测试之前就可以看到各种各样的目标系统。我们的经验是,引入问题后不久,我们便在不同的浏览器和操作系统中发现了许多奇怪的问题。但这只是一个小组的经验。 对于我们的基础架构和安全团队来说,各种各样的系统很困难,因此经常会出现一个痛点。 在一个开发人员团队中拥有同构或异构开发环境是否更有益?

1
什么是基于“火车”的发展?
我在开发方法学中遇到了另一个新名词,但我一直找不到它的定义。具体来说,它称为“基于火车的开发”。 这是我看到这个词的一些例子。 本周早些时候,我请我们的工程主管和发布经理将Windows Metro版本的Firefox下线。(约翰娜·南丁格尔) https://blog.mozilla.org/futurereleases/2014/03/14/metro/ 从Mozilla的职业网站上: 具有使用敏捷开发方法论和基于培训的开发/ QA团队的经验。 我听说过“火车”,而不仅仅是Mozilla。但是我还没有在网上找到关于它的任何好的信息。 当我搜索“基于火车的软件开发”时,我在搜索结果中发现的信息很少。我能挖掘出的最能使火车与货车分开的地方是,“火车”是根据时间表定期释放。但是似乎“培训”是一种具体的质量检查设置。 那么,什么是“基于培训的开发”?

5
针对软件漏洞的攻击/工具的软件生命周期的独特之处是什么?
在我当地的大学中,有一个约20名学生的小型学生计算俱乐部。该俱乐部有几个小组,专门负责特定领域,例如移动开发,机器人技术,游戏开发以及黑客/安全性。 我正在向几个团队介绍一些基本的敏捷开发概念,例如用户故事,估计任务的复杂性以及持续集成以进行版本控制和自动构建/测试。 我熟悉一些基本的开发生命周期,例如瀑布,螺旋,RUP,敏捷等,但是我想知道是否存在诸如用于黑客入侵/破坏安全性的软件开发生命周期之类的东西。当然,黑客正在编写计算机代码,但是该代码的生命周期是什么?我认为他们不会太在意维护,因为一旦发现并修补了漏洞,利用该漏洞的代码就没有用了。 我认为生命周期将是这样的: 找出安全漏洞 利用安全漏洞 采购有效载荷 利用有效载荷 当产品的目的是破坏安全性时,软件的开发生命周期会有什么样的差异(如果有)?

3
是否需要XML注释文档?
我曾经是要求XML注释用于文档的爱好者。从那以后,我改变了主意,主要有两个原因: 像好的代码一样,方法应该是不言自明的。 实际上,大多数XML注释都是无用的噪声,不会提供任何附加值。 很多时候,我们只是使用GhostDoc生成通用注释,这就是我所说的无用噪声: /// <summary> /// Gets or sets the unit of measure. /// </summary> /// <value> /// The unit of measure. /// </value> public string UnitOfMeasure { get; set; } 对我来说,这很明显。话虽如此,如果要包含特殊说明,那么我们绝对应该使用XML注释。 我喜欢这篇文章的摘录: 有时,您将需要写评论。但是,这应该是例外而不是规则。仅当注释表示无法用代码表达的内容时,才应使用注释。如果要编写简洁的代码,请努力消除注释,而改写自记录代码。 我认为我们仅应在代码不足以自行解释时使用XML注释吗? 我相信这是一个很好的示例,其中XML注释使漂亮的代码看起来很难看。需要上这样的课... public class RawMaterialLabel : EntityBase { public long Id { get; set; } …

5
制造与软件开发[关闭]
按照目前的情况,这个问题并不适合我们的问答形式。我们希望答案得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 7年前关闭。 人们常说,与制造业相比,软件产业还不成熟。特别是关于过程驱动。 问题:作为开发人员,我们可以从制造过程中学习吗?采用他们的流程是否可以提高软件开发的成功率? 我的观点:在制造产品时,产品的生产很大程度上是过程驱动的。您可能有一家工厂,每个人都有他们要遵循的一组特定任务。工人(或机器人)可能整天拧紧螺丝。然后,下一位专家将执行该过程中的下一个任务。工人(和机器人)不会阻止过程,也不会“动态”地弥补问题。零件在整个过程中都经过搅动,输出是成品。它运作良好,公司获得了99.99966%的无缺陷产品。随着时间的流逝,公司消除了效率低下的问题。这令人印象深刻,并且很可能是行业成熟的标志。 在制造过程中,定义的过程可以从字面上创建最终产品。我认为在软件中不是这种情况。我们可能有用于源代码控制,代码审查,检入表,需求收集,SDLC等的流程。但是执行这些流程并不能本身创建成品。这些过程可能是有益的,但与实际创建正交。 假设您的公司与软件开发公司签有合同,该软件将搜索数百万张图像以查找罪犯的面孔。尽管有繁重的过程驱动环境,开发人员仍必须“即时”创建事物。动态地做事违背了制造业的精神。机器人无需考虑即可执行良好的制造过程。 为了创建尚未在人的脑海中扎根的复杂算法,必须实时创建事物。软件开发不是过程的后续,而是计算机要执行的过程的创建。那是根本的区别。无论我们围绕开发进行了多少正交处理,我们在创建时总是会“动态”进行。 与我交谈的每个人似乎都同意制造业的观念。我一个人在想吗?

5
PreProd和Prod的环境应如何相似?
我最近刚参与一个项目,在发布期间,我们意识到它在生产环境中不起作用。它可以在所有其他环境中使用,但是因为我们有一个单独的发布团队,而且我们无法自己设置服务器和环境,所以我们无法查看它们上的配置。 我们怀疑Prod在其帐户或IIS设置中具有某些用户权限,因此我们现在在努力。 因此,我认为整件事对我来说都是一次学习经历,我不想再重复同一件事。我想问一下,这些环境应该有什么不同?我一直认为PreProd应该是与Prod环境相同的副本,使用相同数据库的副本,使用相同用户帐户的副本,应安装在相同服务器等上。 但是我应该走多远?如果网站是外部的,那么PreProd应该是外部的吗?如果网站具有不需要用户帐户或密码即可导航的组件怎么办?将它暴露给外界仍然可以吗?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.