Questions tagged «development-process»

作为程序员，我们经常被问到“需要多长时间”？ 而且，情况几乎总是这样： 要求不清楚。没有人对所有含义进行深入分析。 新功能可能会破坏您在代码中所做的一些假设，并且您立即开始考虑可能需要重构的所有内容。 您从过去的工作中还有其他事情要做，您将不得不做出一个将其他工作考虑在内的估算。 “完成”的定义可能尚不清楚：何时完成？就像刚刚完成编码一样是“完成”，还是像“用户正在使用它”那样是“完成”？ 无论您对所有这些事情有多有意识，有时您的“程序员的自尊心”都会使您付出/接受的时间比您最初预期的要短。特别是当您感受到截止日期和管理层期望的压力时。 其中许多是组织上或文化上的问题，这些问题不容易解决，但最终，现实是您被要求提供估计，他们希望您给出合理的答案。这是你工作的一部分。你不能简单地说：我不知道。 结果，我总是最终给出估计，后来我意识到自己无法实现。它发生了无数次，我始终保证不会再发生。但是确实如此。 您确定和提供估算的个人流程是什么？您发现哪些技术有用？

652 project-management  development-process  estimation  time-management 

看完《国家地理》的MegaStructures系列影片后，令我感到惊讶的是大型项目的完成速度如此之快。在纸上完成了初步工作（设计，规格等）后，大型项目的实现本身仅需要数年甚至数月的时间。 例如，空中客车A380 “于2000年12月19日正式发射”，以及“于2005年3月上旬”已经对飞机进行了测试。大型油轮，摩天大楼等也是如此。 将此与软件行业的延迟进行比较，我不禁要问为什么大多数IT项目如此之慢，或更准确地说，如果有足够的人员，为什么它们不能在相同的规模下同样快速，无故障？ 诸如空中客车A380之类的项目都具有以下两个特点： 重大的不可预见的风险：虽然这不是首架飞机，但它仍然推动了技术的极限，对于小型客机而言，运转良好的事物可能由于物理限制而不适用于大型客机；以同样的方式，使用了尚未使用的新技术，例如，当波音747于1969年制造时，它们就不可用了。 总体而言，与人力资源和管理相关的风险：项目中途退出的人们，因休假而无法联系到某个人，常见的人为错误等。 有了这些风险，人们仍然可以在很短的时间内完成像大型客机这样的项目，尽管交付延迟，但这些项目仍然取得了巨大的成功，而且质量很高。 在软件开发方面，这些项目几乎不如客机那么大和复杂（从技术和管理角度而言），而来自现实世界的不可预见的风险则要少一些。 不过，大多数IT项目进展缓慢且迟到，并且向项目中添加更多开发人员并不是解决方案（从十人的开发团队到2000个开发人员的团队有时可以更快地交付项目，有时不能，但是有时只会损害项目，并增加根本无法完成的风险）。 仍交付的那些可能通常包含很多错误，需要连续的服务包和定期更新（想象一下，每周在每架空客A380上两次“安装更新”，以修补原始产品中的错误并防止飞机坠毁）。 如何解释这种差异？是否仅由于软件开发行业还太年轻而无法在一个项目中管理成千上万的人，以便快速交付大规模，几乎无故障的产品？

509 project-management  development-process  time-management  industry 

我希望这不是一个普遍的问题。我真的可以使用一些经验丰富的建议。 我刚刚在一家规模很小的科学家商店中担任唯一的“软件工程师”，他们在过去的10到20年中花了很多时间编写了庞大的代码库。（它是用一种几乎过时的语言编写的：G2-用图形来思考Pascal）。该程序本身是复杂的化学加工厂的物理模型。编写该程序的团队具有难以置信的深厚知识，但是很少或没有正式的编程基础培训。他们最近学到了一些关于不存在的配置管理的后果的艰难教训。代码本身中大量未记录的“污泥”的积累也极大地阻碍了他们的维护工作。我会避免给您这种情况的“政治”（总是 政治！），但足以说，就未来的道路需要什么没有达成共识。 他们要求我开始向团队介绍现代软件开发的一些原理。他们希望我介绍一些有关编码约定，生命周期管理，高级设计模式和源代码控制的行业标准实践和策略。坦白地说，这是一项艰巨的任务，我不确定从哪里开始。 最初，我倾向于在The Pragmatic Programmer或Fowler's Refactoring（“代码气味”等）的一些中心概念中对它们进行辅导。我也希望介绍一些敏捷方法。但最终，要想发挥作用，我认为我需要磨练5-7个核心基础知识。换句话说，他们可以实际开始实施的最重要的原则或实践是什么，这将使他们获得最大的“收益”。 因此，这就是我的问题：您将在最有效的策略列表中包括哪些内容，以帮助理顺意大利面（并在以后防止出现这种情况）？

470 project-management  agile  development-process  maintenance  sdlc 

我正在一个网站上工作，该网站将允许用户使用来自Twitter，Google等的OAuth凭据登录。为此，我必须在这些提供商处注册并获得我拥有的超级秘密API密钥用誓言保护身体的各个部位。如果我的钥匙结了，那部分就被拉了。 API密钥必须随我的源一起传送，因为它在运行时用于执行身份验证请求。就我而言，密钥必须存在于应用程序中的配置文件中或代码本身中。当我在一台计算机上进行构建和发布时，这不是问题。但是，当我们将源代码管理混为一谈时，事情就会变得更加复杂。 因为我是个贱人，所以我更喜欢在云或GitHub中使用免费的源代码控制服务，例如TFS。这给我带来了一个小难题： 当我的API密钥在代码中并且我的代码可在公共存储库中使用时，如何保持身体完整？ 我可以想到许多方法来解决此问题，但是没有一种方法令人满意。 我可以从代码中删除所有私人信息，并在部署后重新编辑。实施起来会很痛苦（我不会在很多方面详述），并且不是一种选择。 我可以加密它。但是，由于我必须解密它，因此任何有消息来源的人都可以弄清楚该怎么做。无意义。 我可以支付私人来源控制的费用。哈哈j / k花钱了吗？请。 我可以使用语言功能将敏感信息与我的其余源代码隔离开，从而使它不受源代码控制。这就是我现在正在做的事情，但是如果错误地检查机密文件，很容易搞砸。 我真的在寻找一种有保证的方式，以确保我不会与世界共享我的私人信息（除了在手套上），这将通过开发，调试和部署而流畅地运行，并且也非常安全。这是完全不现实的。 那我该怎么办呢？ 技术细节：VS2012，C＃4.5，源代码管理将是TF服务或GitHub。当前使用分部类将敏感键拆分到一个单独的.cs文件中，该文件不会添加到源代码管理中。我认为GitHub可能具有优势，因为.gitignore可以用于确保不检入部分类文件，但是我之前已经搞砸了。我希望有一个“哦，常见的问题，这就是你的做法”，但我可能不得不满足于“没有那么多的吸引力”，：/

216 project-management  version-control  development-process  api 

几年前，当我读《神话人月》时，我发现了很多我已经从其他来源知道的东西。但是，尽管那本书是1975年的，但那里还是有新事物。其中之一是： 手术团队 Mills建议将大型工作的每个部分都安排到一个团队中，但该团队的组织应像外科手术团队一样，而不是生猪屠宰团队。就是说，不是每个成员都去解决问题，而是一个人去削减，其他人给他提供一切支持，这将提高他的效率和生产力。 对于组织软件开发团队来说，这是一个非常有趣的模式，但是我从未在任何其他软件工程书中找到它，甚至在任何地方都没有提及。 这是为什么？ 当时的“手术团队”是否还很特别？ 还是尝试过并失败了？ 如果是这样，它是怎么失败的？ 如果不是，为什么我们今天的软件项目中看不到这种模式呢？

164 development-process  patterns-and-practices 

当我阅读此问题时，投票得最高的答案引用了Bob叔叔的编码标准，但这个提示使我感到困惑： 如果可以避免，请不要写下来。相反，让代码成为捕获标准的方式。 这在我的大脑中反弹，但是我找不到合适的地方。如果有新成员加入团队，或者编码标准发生了变化，信息会不会混乱？ 我为什么不应该写下编码标准？

145 development-process  coding-standards 

好的，所以很多代码检查都是相当常规的。但是，有时会发生更改，这些更改会广泛影响现有的复杂，易碎的代码。在这种情况下，验证更改的安全性，缺少回归等所需的时间过长。也许甚至超过了完成开发本身所花费的时间。 在这种情况下该怎么办？合并，希望一切顺利？（不主张这样做！）最好的方法可以并且仅尝试发现任何明显的缺陷（也许这是代码审查应针对的最大问题吗？）完全合并和测试，这是比代码审查更好的替代方法吗？ 这不是一个特别的问题，是否应该在代码审查中进行测试。这是一个问题，询问在上述情况下最好的选择是什么，尤其是在紧迫的截止日期，没有可用的全面单元测试套件或单元测试对零碎的代码不可行的情况下。 编辑：我给人的印象是，到目前为止，我的短语“广泛影响”已经得到了一些答案/评论，并可能认为这意味着更改涉及大量的代码行。我能理解这是一种解释，但这并不是我的意图。所谓“广泛影响”，是指例如由于代码库的互连性或连锁效应的范围而导致回归的可能性很高，而未必一定会使更改本身很大。例如，开发人员可能会找到一种方法，方法是调用一个现有的高级例程，该例程将调用级联到许多较低级别的例程，从而用一行代码修复错误。测试和验证该错误修复程序很容易。手动验证（通过代码审查）所有连锁效应的影响要困难得多。

144 development-process  code-reviews 

假设您正在使用JavaScript创建视频播放器。该视频播放器使用递归功能反复循环播放用户的视频，因此，浏览器too much recursion RangeError有时会触发。 可能没有人会那么多地使用循环功能。您的应用程序将永远不会抛出此错误，即使用户将应用程序循环了一周也不会出现此错误，但是它仍然存在。解决该问题将需要您重新设计应用程序中循环的工作方式，这将花费大量时间。你是做什么？为什么？ 修正错误 留下错误 您不应该只解决人们会偶然发现的错误吗？修正错误何时会变得矫kill过正？ 编辑： 如果您担心递归方法不会导致实际的错误，请假设播放器每次播放视频时，变量都会增加1。在2 53循环之后，此变量将溢出，您的程序将无法处理它，并引发异常。

128 development-process 

我的办公室正在尝试弄清楚我们如何处理分支拆分和合并，但是我们遇到了一个大问题。 我们的问题是长期的分支机构-在这种情况下，您需要几个人在与分支机构分离的分支机构中工作，我们会发展几个月，而当我们达到一个里程碑时，我们就会将两者同步。 现在，恕我直言，处理此问题的自然方法是将侧枝压缩为单个提交。master不断进步；应当-我们并没有追溯数月的并行开发master历史。而且，如果有人需要更好的分辨率来解决分支机构的历史，那么当然，它仍然存在-它不在master，而是在分支机构中。 问题出在这里：我只使用命令行工作，而我团队的其他成员则使用GUIS。而且我发现GU​​IS没有合理的选项来显示其他分支的历史记录。因此，如果您达成一个壁球承诺，说“此开发已从分支被压缩XYZ”，那么查看其中的内容将是巨大的痛苦XYZ。 在SourceTree上，据我所知，这非常令人头疼：如果您正在上master，并且想要查看的历史记录master+devFeature，则需要签master+devFeature出（触摸每个不同的文件），否则滚动浏览一个日志，该日志并行显示您存储库的所有分支，直到找到正确的位置。祝您好运。 我的队友很正确地不想拥有如此难以接近的发展历史。因此，他们希望合并这些大型的，长期的开发分支，并始终使用合并提交。他们不需要任何无法从master分支立即访问的历史记录。 我讨厌那个主意；这意味着平行发展历史的无尽，不可逾越的纠结。但是我没有看到我们有什么选择。而且我很困惑。这似乎阻碍了我对良好分支机构管理所了解的大多数知识，如果找不到解决方案，这将使我不断感到沮丧。 除了不断地将分支机构与合并提交合并到主分支之外，我们这里还有其他选择吗？还是有一个原因导致不断使用merge-commits并不像我担心的那样糟糕？

119 version-control  git  development-process 

我从不知道什么时候项目足够远，可以首先提交到源代码管理。我倾向于推迟提交，直到项目“框架完成”为止，然后我主要提交功能。（我还没有做过足够大的个人项目，以至于没有一个太大的核心框架。）我觉得这不是最佳实践，尽管我不确定会出什么问题。 例如，假设我有一个包含单个代码文件的项目。要使该项目具有极其基本的功能（1个或2个功能），将需要大约10行样板代码和100行。我应该首先签入： 空文件？ 样板代码？ 第一个功能？ 在其他时候？ 另外，在特定地点办理登机手续的原因是什么？

118 project-management  version-control  development-process 

在过去的6个月或更长时间里，我已经看到很多代码托管在sourceforge.net以及其他托管网站“移至GitHub”上。仅使用短语“ Moved to Github”的Google搜索会返回多个结果，其中包含已移至github的文本。这对我来说非常令人困惑，我想知道，为什么人们要移动？这是否意味着GitHub更好，还是有我没有看到的一些特殊优势？

114 open-source  development-process  project-hosting 

当我的同事认为不需要在PC上进行测试时，他进行更改，提交然后进行推送。然后，他在生产服务器上进行测试，并意识到自己犯了一个错误。它每周发生一次。现在我看到他进行了3次提交，并在5分钟内将其推送到生产服务器。 我几次告诉他，这不是做好工作的方式。我不想再对他无礼，他在公司中的地位与我相同，他在这里的工作比我还要多。 我希望以某种方式惩罚这种行为，或使其尽可能不愉快。 在我开始之前，该公司使用诸如FTP之类的老式方法进行部署，并且没有版本控制。 我强迫他们/我们使用Git，Bitbucket，Dploy.io和HipChat。部署不是自动的，必须有人登录dply.io并按deploy按钮。 现在，如何强制他们不要在生产服务器上进行测试？像HipChat bot这样的东西可以感觉到同一行上有重复的编辑，并向程序员发送通知。

113 git  development-process 

我是一名初级开发人员，如果我可以证明更改的合理性，并且可以帮助团队完成工作，则可以帮助调整团队的流程。这对我来说是新的，因为我过去的公司或多或少都严格定义了来自管理层的流程。 我的团队很小，有些新（不到3岁）。他们缺乏： 定义明确的软件开发/工作管理框架（如Scrum） 强大的产品所有权 定义明确的角色（例如，业务人员将进行手动测试） 定期站立会议 合并的问题跟踪流程（我们有一个工具，该流程仍在开发中） 单元，系统，回归或手动测试套件或列表 有关业务逻辑和流程的文档 知识库以记录内部和面向客户的提示 而这样的例子不胜枚举。只要价值是合理的，管理人员就可以实施改进措施，并且可以帮助完成最重要的工作（即开发）。但是，基本假设是您必须在实现中拥有所有权，因为没有人会为您做这件事。毋庸置疑，上述某些项目是不平凡的，无疑是耗时的，并且显然不是开发工作。 随着时间的流逝，（初级）开发人员尝试实现上述目标是否值得？还是最好“随心所欲”并专注于开发，将大部分流程定义和优化留给管理人员？

108 project-management  scrum  development-process  process  product-owner 

不同的版本命名约定是否适合不同的项目？您使用什么，为什么？ 就我个人而言，我更喜欢以十六进制表示的内部版本号（例如11BCF），该数目应该定期增加。然后为客户提供一个简单的3位数版本号，即1.1.3。 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

107 project-management  development-process  naming  versioning 

我很调皮……太多的“牛仔编码”，还不够提交。现在，我在这里做出了巨大的贡献。是的，我应该一直坚持下去，但是现在为时已晚。 什么是更好的？ 做一个非常大的提交，列出我所做的所有更改 尝试将其分解为可能无法编译的较小提交，因为文件具有多种修复，更改，其他方法名称等。 尝试仅针对适当的提交对文件进行部分还原，然后放回新的更改。 注意：到目前为止，我是唯一从事此项目的程序员。至少在我们雇用更多程序员之前，唯一会查看所有提交评论的人就是我。 顺便说一句：我正在使用SVN和Subclipse。在进行任何这些更改之前，我确实创建了一个新分支。 更多信息：我首先问了一个与我如何进入这种情况有关的单独问题：如何为重写应用程序的粘合做准备

100 version-control  development-process  scm  cowboy-coding