Questions tagged «large-scale-project»

假设我正在开发一个相对较大的项目。我已经用Doxygen记录了我的所有类和函数，但是，我有个主意，在每个源代码文件上都写上“程序员笔记”。 这背后的想法是用通俗的术语解释一个特定的类是如何工作的（不仅是为什么大多数评论如此）。换句话说，让其他程序员对类的工作方式有另一种看法。 例如： /* * PROGRAMMER'S NOTES: * * As stated in the documentation, the GamepadManager class * reads joystick joystick input using SDL and 'parses' SDL events to * Qt signals. * * Most of the code here is about goofing around the joystick mappings. * We want to …

104 documentation  large-scale-project 

我已阅读《敏捷架构师原则》，其中定义了以下原则： 原则1：对系统进行编码的团队设计系统。 原则2构建最简单的可行架构。 原则＃3如有疑问，请将其编码。 原则4：他们构建，测试。 原则5：系统越大，跑道越长。 原则6系统架构是角色协作。 原则7：创新没有垄断。 该论文说，大多数架构设计是在编码阶段完成的，而在此之前只有系统设计。那也行。 那么，系统设计如何完成？使用UML？还是定义接口和主要块的文档？也许还有别的吗？

59 architecture  agile  large-scale-project 

我开始学习Vim，并遵循stackexchange中此处给出的一些建议。我开始在一些玩具项目中使用它，对此我感到很高兴。 但是我开始想知道如何在不始终打开​​其他文件的情况下提高工作效率，只是想知道该类的名称如何，其他文件中包含的宏是什么，等等。 您可以提供哪些常见建议？

17 vim  large-scale-project 

在大学中，在我们的算法课程中，我们学习如何精确计算实际使用的各种简单算法（例如哈希表或快速排序）的复杂性。 但是现在在一个大型软件项目中，当我们想使其更快时，我们所要做的只是看各个部分-那里有一些嵌套循环，可以用更快的哈希表代替，这里的慢速搜索可以通过更花哨的技术-但我们从未计算过整个流程的复杂性。 有什么办法吗？还是在实践中人们只是使用快速算法依靠“本地”来使整个应用程序更快，而不是全局地考虑整个应用程序？ （因为在我看来，要证明如果您堆积大量已知非常快速的算法，那么最终还是会得到一个整体快速的应用程序。） 我之所以这样问，是因为我的任务是加快别人编写的大型项目的速度，其中许多算法正在交互并处理输入数据，因此我不清楚在单一算法上更快地完成单一算法的影响。整个应用程序。

11 complexity  large-scale-project 

在我的公司中，通常不做任何中间构建来检查每个功能/错误修正分支如何在dev中合并。每天只有一次构建，这总是会引发很多测试失败和构建错误。有人告诉我，为超过1000个开发人员的每次合并进行构建都是不合理的。 因此，我搜索了在拥有那么多开发人员或更多开发人员的公司（Microsoft，Facebook）中如何配置CI，却一无所获。也许内部人士可以告诉我呢？

11 development-process  continuous-integration  large-scale-project 

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

11 development-process  large-scale-project 

关于用于改进遗留代码库的工具和技术的信息很多，但是我还没有遇到任何成功的现实案例研究。大多数建议都是微观的，尽管很有帮助，但由于缺乏证据，因此无法说服很多人，因为它不能在宏观上提供帮助。 我正在专门寻找渐进式改进，这些改进已被证明在更新大型遗留代码库以满足当今的质量标准而不是完全重写时在现实世界中是成功的。 之前： 大：大于1MLOC 旧版：无自动化测试 劣质：高复杂度，高耦合，高逸出缺陷 后 自动化测试 更容易的更新/维护 高质量：降低复杂度，解耦代码，避免一些缺陷 在现实世界中，已经证明了哪种增量步骤可以成功更新大型遗留代码库，以达到上述质量标准，而无需进行完全重写？ 如果可能，请在回答中包含一个示例公司或一个大型旧项目的案例研究，该项目已通过“成功的”质量改进过程以进行备份。

10 quality  legacy  large-scale-project 

在我的（主要是C ++）开发中，我一直坚持使用源代码之外的版本。也就是说，我的来源通常坐落在一个/project/src目录和建立生活在一个/project/build/bin/release，/project/build/bin/debug目录。之所以这样做，是因为它可以使我的源目录与中间文件保持干净，我的所有二进制文件都位于一个位置，打包更容易，清理更容易，版本控制也更容易。（我有什么想念吗？） 我现在正在继承一个使用源代码内部构建的（大型）项目。这种结构的动机是什么，它的优点是什么？（我最关心的是工程级别的原因与个人喜好类型的原因。） 我希望拉科斯（Lakos）的“大型C ++软件设计”能在其中发挥作用，但如果这样做，我会错过它。

10 builds  directory-structure  large-scale-project  cmake