我已经继承了200,000行意粉代码-现在怎么办？

#1 楼

前言

这确实是一项艰巨的任务，
有很多基础。因此，我谨以此建议为您的团队提供一些全面的指南，并提供指向适当工具和教育材料的指南。是要
根据情况采用，改编或删除的内容。您应该尝试挑选会为您带来最佳效果的元素，然后一次缓慢地引入它们。

注意：并非所有这些都直接适用到Visual Programming
像G2这样的系统。有关如何处理这些错误的详细信息，请参见结尾处的附录。


不耐烦的执行摘要


使用以下内容定义一个刚性项目结构：



项目模板，

编码约定，
熟悉的构建系统，
以及适用于您的基础架构和工具的使用指南集。


安装良好的SCM并确保他们知道如何使用它。
将它们指向具有良好IDE的IDE技术，并确保他们知道如何使用它们。
在构建系统中实施代码质量检查器和自动报告。
将构建系统与持续集成和持续检查系统相结合。
借助上面的内容，确定代码质量“热点”并进行重构。

现在是长版本了...警告，请放心！


刚性是（通常）良好

这是一个有争议的观点，因为刚性通常被视为一种力量
告诉你在某些项目的某些阶段确实如此。但是
一旦您将其视为结构性支持，即消除了猜测的框架，则可以大大减少浪费的时间和精力。使它对您有用，而不是对您不利。

刚性=过程/过程。

正是出于化工厂或工厂拥有手册，程序，演习和紧急指导的原因，软件开发需要良好的过程和程序：防止不良结果，提高可预测性，最大化生产率。 ..

刚性要适度！

项目结构的刚性

如果每个项目都具有自己的结构，那么您（和新来者） ）
丢失，每次打开它们都需要从头开始。您
不想在专业的软件商店中使用此软件，也不想在实验室中使用它。

构建系统的刚性

如果每个项目看起来都不同，则很有可能
构建不同的项目。构建不需要太多的研究或太多的猜测。您希望能够做规范的事情，并且
不用担心细节：configure; make install，ant，
mvn install等...

重新使用相同的内部版本系统并随着时间的推移不断发展。
还可以确保稳定的质量水平。

您确实需要快速的README来指出项目的具体情况，并
优美地指导用户/开发人员/研究人员（如果有的话）。

这也大大简化了构建的其他部分
基础结构，即：



持续集成，

连续检查。

因此，请保持您的构建（例如您的项目）为最新状态，但随着时间的流逝它会变得更严格，并且在报告违规情况时会更有效和不好的做法。

不要重新发明轮子，而要重复使用已经做过的事情。

推荐阅读：



持续集成：提高软件质量并降低风险（Duval，Matyas和Glover，2007年）

Contin不连续交付：通过构建，测试和部署自动化发布软件发布（Humble，Farley，2010年）

编程语言选择的严格性

，尤其是在研究环境中，不能期望所有团队（甚至更少的所有开发人员）都使用相同的语言，并且
技术栈。但是，您可以确定一组“官方
支持”的工具，并鼓励使用它们。剩下的没有很好的合理性
（除了原型设计之外）。

使您的技术栈简单易行，并且
所需技能的维护和广度最低限度：一个强大的核心。

编码约定和准则的刚性

编码约定和准则使您可以同时形成两个团队的身份
以及共享的行话。您不希望每次打开源文件时都犯错
。

非理性规则会使生活变得更困难或禁止明确执行行为
由于单一的简单违规而被拒绝是一个负担。但是：


经过深思熟虑的基本规则集消除了很多抱怨和思考：
在任何情况下都不应打破；
建议的规则提供了额外的指导。 >通用语言，这是我团队可识别的风格。当废话代码
签入时，它就像好莱坞明星的唇疱疹一样突出：
它会自动触发评论并采取行动。
实际上，我已经有时甚至提倡使用
pre-commit钩子拒绝不合格的提交。如前所述，它
不应过于疯狂并妨碍生产率：它
应该推动它。慢慢地介绍这些内容，尤其是在
开始时。但这比花费大量时间修复错误代码以使您无法解决实际问题更可取。


某些语言甚至通过设计来强制执行此操作：


Java的目的是减少您可以使用
编写的枯燥乏味的代码（尽管无疑许多人都这样做了）。
通过缩进的Python块结构是这种感觉的另一种想法。
借助其gofmt工具，Go可以完全消除固有的任何争论和努力（和自我！）。样式：在您提交之前运行gofmt。

请确保代码不会滑过。代码
惯例，持续集成和连续
检查，结对编程和代码审查是您抵御​​此恶魔的武器。代码就是文档，而这又是约定鼓励可读性和清晰度的另一个领域。

文档的刚性

文档与代码紧密结合。代码本身是
文档。但是必须明确说明如何构建，使用和维护事物。

使用单一控制点进行文档编制（例如WikiWiki或
DMS）是一件好事。为项目创建空间，为更多的随机玩笑和实验提供空间。让所有空间重用通用规则
和约定。尝试使其成为团队合作精神的一部分。

大多数适用于代码和工具的建议也适用于
文档。

代码注释中的刚性
上面提到的/>代码注释也是文档。开发人员喜欢表达自己对代码的感受（如果您问我，主要是骄傲和沮丧）。因此，当更多的
正式文本可以用更少的
专有词表达相同的意思时，他们在注释（甚至代码）中用不确定的术语表达这些
并不稀奇。戏剧。出于趣味和
历史上的原因，可以让一些人溜走：这也是发展团队文化的一部分。但是每个人都知道什么是非常重要的
可以接受，什么不可以，而评论的声音就是：
噪音。

提交日志中的刚性

提交日志并不是烦人且无用的“ SCM生命周期中的“步骤”：您不要跳过它以按时回家或继续执行下一个任务，或者赶上那些去吃午餐的哥们。它们很重要，就像（大多数）好酒一样，时间越长，它们就变得越有价值。所以做对了。当我看到同事们为巨大的提交或非显而易见的黑客编写单行代码时，我感到非常惊讶。始终清楚地
由您的代码和您输入的一行提交日志表示。不仅如此。

每行代码都有一个故事和一个历史。差异可以说出它的历史，但是您必须写出它的故事。


为什么我要更新此行？ ->因为界面已更改。

为什么界面已更改？ ->因为定义了它的库L1
已更新。

为什么要更新该库？ ->因为
功能F需要的库L2取决于库L1。

X的功能是什么？ ->请参阅问题跟踪器中的任务3456。


这不是我的SCM选择，也可能不是您实验室的最佳选择
；但是Git正确无误，并试图通过使用short logs和
long logs来使您写出比大多数其他SCM系统更好的日志。链接任务ID（是，您需要一个），并留下shortlog的通用摘要，然后在长日志中展开：写
变更集的故事。

它是一条日志：它是在这里跟踪和记录更新。


经验法则：如果以后要搜索有关此更改的内容，您的日志是否有可能回答您的问题吗？


项目，文档和代码都还活着

使它们保持同步，否则它们将不再形成该共生实体
。当您拥有以下功能时，它会产生奇迹：


清除SCM中的提交日志，带有指向您的
问题跟踪器中的任务ID的链接，
此跟踪器的票证本身链接到您的SCM中的变更集（可能还链接到您的CI系统中的内部版本），以及链接到所有这些文件的文档系统。

代码和文档需要

测试中的刚性


经验法则：



任何新代码都应随附（至少）单元测试。
任何重构的旧代码都应随单元测试一起提供。



当然，这些需要：


实际测试一些有价值的东西（否则会浪费时间和精力），
要写得很好并带有注释（就像您签入的任何其他代码一样）。

它们也是文档，它们有助于概述代码的合同。
。特别是如果您使用TDD。即使您不这样做，您
也要让他们安心。当您
结合新的代码（维护或功能）和watch望塔
以防止代码腐烂和环境故障时，它们就是您的安全网。当然，您应该走得更远并进行集成测试，并针对您修复的每个可复制错误进行
回归测试。

使用工具的刚性

对于偶尔的开发人员/科学家来说，这没关系想要在源代码上尝试一些新的
静态检查器，使用另一个生成图形或模型，
或使用DSL实现新模块。但是最好是所有团队成员都应该拥有一套
规范的工具
。

此外，让成员使用他们想要的东西，只要它们都是：



生产性的，
不定期需要帮助

不定期调整您的一般基础结构，

不会破坏您的基础架构（通过修改常见的
区域，如代码，构建系统，文档...），

不影响他人的工作，

能够及时

如果不是这种情况，则强制其回退到默认值。


刚性与多功能性，适应性，原型设计和紧急情况
/>
灵活性很好。让某人偶尔使用骇客，
快速，肮脏的方法或喜欢的宠物工具完成工作
很好。永远不要让它成为习惯，也永远不要让这段代码成为实际的代码库来支持。


团队精神很重要

养成一种意识以您的代码库为荣


树立以代码为荣的感觉


使用墙板



领导者连续集成游戏的棋盘
用于问题管理和缺陷计数的墙板


使用问题跟踪器/错误跟踪器




/>
避免责备游戏


使用持续集成/持续检查游戏：它
促进良好的竞争和富有成效的竞争。
保持跟踪缺陷：只是保持良好的内部管理。
要确定根本原因：只是面向未来的过程。
不要指责：反而会适得其反。

这是关于代码，而不是有关开发人员的信息

使开发人员意识到其代码的质量，但要使他们
将代码视为独立的实体而不是外部
他们自己的本性是不容置疑的。

这是一个自相矛盾的事情：您需要鼓励在健康的工作场所使用无我编程，但要出于激励目的而依靠自我。


从科学家到程序员

不重视并为代码感到骄傲的人们不会产生好的
代码。为了使此属性浮出水面，他们需要发现其价值如何
可能会很有趣。纯粹的专业精神和对做事的渴望还不够
：它需要激情。因此，您需要将您的科学家变成
程序员（广义上）。

有人在评论中指出，在一个项目及其代码10到20年后，任何人会感到依恋。也许我错了，但是我想
他们为代码的结果，工作及其遗产感到骄傲，
而不是为代码本身或编写代码的行为感到自豪。

根据经验，大多数研究人员都认为编码是必须的，或者最好是将娱乐分散注意力。他们只是想要它工作。那些已经精通该程序并且对编程感兴趣的人更容易说服采用最佳实践和转换
技术。您需要将它们放到一半。


代码维护是研究工作的一部分

没有人会阅读笨拙的研究论文。这就是为什么它们要经过同行评审，校对，精炼，重写和批准的时间，然后又再次被批准直到可以发布。
论文和代码库也是如此！

要明确指出，不断重构和刷新代码库
可以防止代码腐烂并减少技术负担，并促进未来发展。
/>为其他项目重新使用和修改工作。


为什么所有这些？对于代码质量。或者是
质量规范...？

这些准则旨在推动您的团队朝着这个目标前进。有些
方面只是通过向他们展示方式并让他们这样做来做到这一点
（这更好），而另一些方面则牵着他们的手（但这就是
如何教育人们和养成习惯） ）。

您如何知道何时可以达到目标？如前所述，您
需要在团队中建立自豪感并展现进步
好的结果是关键。定期测量代码质量，并显示间隔之间的进度及其重要性。进行回顾，以
反思所做的事情，以及它如何使事情变好或变坏。

有很好的工具可以进行连续检查。声纳是
在Java世界中很流行的一种，但是它可以适应任何技术；
还有很多其他技术。将您的代码放在显微镜下，
寻找这些讨厌的令人讨厌的错误和微生物。


但是如果我的代码已经被废了怎么办？

全部以上内容很有趣又可爱，就像去Never Land一样，但是
当您已经有了（一堆蒸腾的和
很臭的）废话，并且一个团队不愿改变时，就不那么容易了

这是个秘密：您需要从某个地方开始。


个人轶事：在一个项目中，我们使用的代码库最初的重量为65万+ Java LOC，200,000多行JSP，
40,000+ JavaScript LOC和400+ MB二进制依赖项。 br /> 150,000行JSP和38,000个JavaScript LOC，具有依赖项
几乎只有100MB（这些不再在我们的SCM中！）。

我们如何做到的？我们只是完成了以上所有操作。还是努力尝试。

这是团队合作的结果，但是我们会慢慢引入我们的过程
法规和工具来监视我们产品的心率，
却急于削减“胖”：胡扯的代码，无用的
依赖项...我们并没有停止所有开发来做到这一点：
偶尔会有相对和平与宁静的时期，我们可以自由地
疯狂地破坏了代码库并将其拆开，但是大多数时候，我们会通过以下方式来全部做到这一点：每次获得机会时，默认情况下都默认为“查看和重构”模式
：冲刺，
在星期五下午...

其中有一些很大的“工作” ...将我们的build
系统从一个8500+ XML LOC的巨型Ant构建转换为一个
多模块Maven构建就是其中之一。然后，我们有了：


清晰的模块（或者至少它已经好很多了，我们
仍然有未来的大计划），自动依赖性管理（便于维护和更新，并且
删除无用的deps），
更快，更容易和可复制的构建，
每日质量报告。

另一个即使我们
试图减少依赖性，也注入了“实用工具带”：Google Guava和Apache Commons
减少了代码的数量并减少了代码中的错误的出现
很多。

我们还说服了IT部门，也许使用我们的新工具
（JIRA，Fisheye，Crucible，Confluence，Jenkins）要比现有的工具好。我们仍然需要处理我们鄙视的一些问题（QC，
Sharepoint和SupportWorks ...），但这是整体改进的
体验，还有更多空间。

现在，每天都有一到几十个
提交的细流，这些提交仅用于修复和重构事物。我们
有时会破坏东西（您需要单元测试，最好在重构之前将它们编写
），但是总体而言，对于我们的士气和产品而言，收益是巨大的。我们一次达到了
代码质量百分比的一小部分。
看到它增加很有趣！！！


注意：同样，刚性也需要动摇，以便为新的和更好的东西腾出空间。在我的轶事中，我们的IT部门在某种程度上强加于我们的事情是对的，而对另一些事物则是错的。也许
它们曾经是正确的。事情会改变的。证明它们是更好的途径，以提高您的生产率。试运行和原型在这里
。


超绝妙的增量式意大利面条式代码重构周期，可提供出色的质量

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

一旦您在工具栏上拥有一些优质的工具，就可以：



使用代码质量检查器分析代码。

棉绒，静态分析器或您所拥有的产品。


确定关键的热点和不足之处水果。

违规行为的严重性级别很高，而具有大量高严重等级的大型类别则是一个大的危险信号：因此，它们显示为
“热点” “在散热器/热图类型的视图上。


先修复热点。

由于它们具有
，它可以在短时间内最大化您的影响力。最高的商业价值。理想情况下，严重的违规行为应尽快处理，因为它们是潜在的安全性
漏洞或崩溃原因，并且极有可能导致
责任（在您的情况下，



使用自动代码库扫描来清除低级冲突。

它改善了信噪比，使您成为能够
看到雷达上出现的重大违规情况。如果没有认真对待，一开始通常会有大批轻度违规的人
，而您的代码库则在野外留下来。它们不会带来真正的“风险”，但是会损害代码的可读性和可维护性。
在执行任务时遇到它们时，或通过大范围清理任务来修复它们如果可能，自动进行代码扫描。如果您没有良好的测试套件和集成系统，请小心使用大型自动扫描器
。确保与同事达成共识，在适当的时间运行他们，以最大程度地减少烦恼。


重复直到满意为止。

理想情况下，如果它仍然是活跃产品，则永远不应该这样做：它会不断发展。


快速入门技巧房屋保管



处于修补程序模式时，根据客户支持要求：


通常最好的方法是不解决其他问题，可能会不情愿地引入新功能。
采用SEAL风格：进入，杀死bug，退出并交付您的
补丁。这是外科手术和战术上的打击。



但是在其他所有情况下，如果打开文件，请尽力： br />
：一定要对其进行审查（记录笔记，文件问题报告），

也许是：对其进行清理（样式清理和轻微违规），重构它（重组大的部分和它们的邻居）。



不要仅仅因为花了一个星期在文件与文件之间花了一个星期而
结束了跨越多个
功能和模块的数千个修复程序的大规模变更-使得将来的跟踪变得困难。
代码中的一期=跟踪器中的一张票。有时，变更集可能会影响多个
门票；但是如果它经常发生，那么您可能做错了。


附录：管理可视化编程环境

定制编程系统的围墙花园

像OP的G2这样的多种编程系统是不同的野兽。 >通常，它们不让您访问源代码“
”的文本表示形式：它可能以专有二进制格式存储
，或者确实以文本格式存储了东西但隐藏了
/>它们离您很远。定制的图形化编程系统实际上在研究实验室中并不罕见，因为它们简化了重复数据处理工作流程的自动化。


没有工具

除了自己以外，就是这样。您经常会受到他们的
编程环境，他们自己的调试器，他们自己的
解释器，他们自己的文档工具和格式的束缚。他们是
围墙花园，除非它们最终引起人们的兴趣
，只要他们有足够的动力进行反向工程其格式并
构建外部工具（如果许可证允许）。


缺乏文档

通常，这些是利基编程系统，它们在相当封闭的环境中使用。使用它们的人经常签署NDA
，从不谈论自己的工作。为他们编程
社区是很少的。因此资源稀缺。您
被官方参考卡住了，就是这样。具有讽刺意味的（常常令人沮丧的）一点是，这些
系统所做的一切可能很显然，可以通过使用主流和通用的编程语言来实现，而且效率可能更高。但这需要更深入的编程知识，
而您不能指望生物学家，化学家或物理学家（仅举几个例子）对编程有足够的了解，甚至更少拥有
实施（和维护）复杂系统的时间（和愿望），
可能会长期存在，也可能不会长期存在。出于相同的原因，我们使用DSL，所以我们有这些定制的编程系统。


个人轶事2：实际上，我本人就是其中之一。我没有按照OP的请求进行链接，但是我的
项目是一组相互连接的大块数据处理和数据存储软件（主要用于
bio -信息学研究，医疗保健和化妆品，还用于
商业智能或任何暗示对任何类型的大量研究数据进行跟踪并准备
数据处理工作流程和ETL）。这些应用程序之一是
，非常简单，它是一个可视化的IDE，使用了通常的花哨功能：
拖放界面，版本化的项目工作区（使用文本
和XML文件进行元数据存储） ，有许多可插入的驱动程序用于
异构数据源，以及用于设计管道以处理来自N个数据源的数据的可视画布，最终生成M
转换后的输出，以及可能的生动可视化效果和复杂的（以及交互式）在线报告。您典型的定制视觉
编程系统，在设计适合用户需求的系统的前提下，患有一些NIH综合征。

而且，正如您所期望的那样，它是一个很好的系统，虽然有时会有点过头，但它的
需求却非常灵活，因此您想知道“为什么
不使用命令行工具？”，不幸的是总是
领导从事大型项目的中型团队，让许多不同的人以不同的“最佳”实践来使用它。


太棒了，我们注定要失败！ -我们该怎么做？

最后，以上所有这些仍然成立。如果您不能从该系统中提取大部分程序以使用更多主流工具和语言，则“只是”需要使它适应您系统的约束。

关于版本控制和存储

最后，即使在最受限制和围墙的环境中，您也几乎可以始终对内容进行版本控制。大多数情况下，这些
系统仍然带有其自己的版本控制（不幸的是，
通常是相当基本的，并且提供还原为以前的版本
而没有太多的可视性，只是保留了以前的快照） 。它不是像您选择的SCM那样完全使用差异变更集，
，它可能不适合同时提交变更的多个用户
。但是，如果他们确实提供了这样的功能，也许您的
解决方案是遵循我们上面广受欢迎的行业标准准则，
并将其转换为该编程系统！是一个数据库，它可能会公开导出
功能，或者可以在文件系统级别备份。如果
使用自定义二进制格式，也许您可​​以简单地尝试使用对二进制数据有良好支持的VCS对它进行版本控制。您将没有细粒度的控制，但至少会发现您遇到灾难的可能性
，并且一定程度地灾难了
恢复合规性。

关于测试

在平台本身中进行测试，并使用外部
工具和后台作业来设置常规备份。很可能，
启动这些测试的方式与启动使用此编程系统开发的程序的方式相同。

当然，这是一项破解工作，绝对不能
是“常规”编程常见的标准，但是其思想是在尝试维持专业软件的外观的同时适应
系统。

这条路漫长而陡峭...

与小众环境和定制的编程系统一样，
正如我们上面所暴露的，您处理的是奇怪的格式，只有有限的或
（完全不存在）一套可能笨拙的工具，以及在社区中的空白
。

建议：请尝试在上述
之外实施上述准则您的定制编程系统，尽可能多。这样可以确保
您可以依靠“通用”工具，这些工具具有适当的支持和
社区驱动力。

解决方法：如果无法选择，请尝试对其进行改造
将全局框架放入“框”。这个想法是将行业标准最佳实践的
蓝图叠加在您的编程系统之上，并加以利用。该建议仍然适用：
定义结构和最佳做法，鼓励遵守法规。

不幸的是，这意味着您可能需要下潜并进行大量的腿部锻炼。 。所以...

著名的遗言和谦卑的请求：



记录您所做的一切。

分享您的经验。

开源任何您编写的工具。

通过所有这些，您将：


不仅增加了在类似情况下获得人们支持的机会，而且还提供了帮助其他人，并围绕您的技术堆栈进行讨论。

谁知道，您可能正处于一个新的，充满活力的晦涩语言X社区。没有，就开始吧！
也许里面很漂亮，但到目前为止没有人知道，所以
帮忙拆除这堵丑陋的墙，让其他人看看！

#2 楼

第一步将是引入版本控制系统（SVN，Git，Mercurial，TFS等）。

编辑：关于VSC-每个源代码控制包都可以管理二进制文件，尽管有一些限制。市场上的大多数工具都具有使用自定义差异查看器和编辑器的能力，并使用此功能。二进制源文件不是不使用版本控制的借口。

关于如何处理遗留代码也有类似的帖子，可能是一个很好的参考-有关使用遗留代码的建议

#3 楼

当我必须处理意大利面条式代码时，我要做的第一件事就是模块化。查找可以画线并提取（或多或少）代码库独立部分的地方。由于高度的互连性和耦合性，它们可能不会很小，但是如果您寻找它们，则会出现一些模块线。

一旦有了模块，就不会面临清理整个凌乱程序的艰巨任务再也无法完成。现在，您需要清理几个较小的独立凌乱模块。现在选择一个模块，并以较小的比例重复。找到可以将大型函数提取为较小的函数甚至是类的地方（如果G2支持它们的话）。

如果该语言具有足够强大的类型系统，这将容易得多，因为您可以获得编译器为您完成了许多繁重的工作。您在某个地方进行了更改，这将（有意地）破坏兼容性，然后尝试进行编译。编译错误将直接把您带到需要更改的地方，而当您停止获取它们时，您已经找到了一切。然后运行程序并测试所有内容！重构时，连续测试至关重要。

#4 楼

我不知道这是否是您的选择，但我会开始尝试说服他们雇用更多的专业开发人员。这样，他们可以集中精力解决领域问题（我相信他们在那里就足够了。）

我相信他们是非常聪明的人，但是要成为一名优秀的开发人员需要很多时间。他们准备花很多时间参加不是主要业务的活动吗？恕我直言，这不是获得最佳结果的方法。

#5 楼

哇。听起来您面临着巨大的挑战！我将按照以下方式进行操作：首先，确定优先级。您首先要实现什么？对于项目的当前状态，最重要的是什么？您将从中获得最大的收益以及到达那里所需的时间。
确保您拥有版本控制系统。例如Git或Mercurial。
建立并运行某种持续集成系统（例如Jenkins）。
建立并运行错误跟踪系统。我认为Mantis相当不错。
研究静态代码分析（如果您正在使用的语言有可用的东西）。
在变量的命名，通用的代码约定和代码库中的准则方面，尝试在所有方面实现尽可能高的一致性。

让系统处于测试状态。我认为，这对于像这样的大型遗留系统极为重要。使用测试用例记录现有行为，而不管行为是否怪异（通常，为什么代码看起来确定为什么是好还是不好，或两者兼而有之； P）。迈克尔·费瑟斯（Michael Feathers）有效地使用旧版代码是为此的绝佳资源。

#6 楼

他们说解决问题的第一步就是承认自己有一个。考虑到这一点，您可能首先要生成一个依赖关系图，该图说明当前代码库的巨大纠结。生成依赖关系图的好工具？已有数年历史，但其中包含一些可帮助创建此类图形的工具的指针。我会用一张巨大的，丑陋的大图来显示尽可能多的线索。讨论由过多的相互依赖关系引起的问题，或者可能会从Buckaroo Banzai碰到一行：正常变化，当它下降到它的尽头时，
头部的所有部分看起来都一样。不，不，不，不要拉扯。您永远不会
知道它可能附带的内容。


从那里开始，制定一个计划来理清混乱。将代码分成尽可能独立的模块。对如何做到这一点持开放态度-与您交谈的人们比您更了解代码的历史和功能。但是，目标是要解决一个大问题，并将其转变为一些较小的问题，然后可以对其进行优先级排序并开始清理。

需要重点注意的事情：


在模块之间创建干净的接口并开始使用它们。旧代码可能有必要在一段时间内继续不使用那些好的新接口，这就是您要解决的问题。但是，请大家同意只使用新的接口。如果接口中有他们需要的东西，请修复接口，不要绕过它们。
寻找重复使用相同功能的情况。努力统一。
时不时提醒所有人，这些改变旨在使生活更轻松，而不是更困难。过渡可能会很痛苦，但这是出于良好的目的，所有人参与的人数越多，收益就会越快。

#7 楼

在深入研究Gensym G2之后，看来解决该问题的方法将高度依赖于代码库的大小，如下所示：



或此：



与此相反，由99瓶啤酒提供：

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

在对于后者，您正在使用的源代码实际上是一个已知数量，而其他一些答案则为处理它提供了非常明智的建议。

如果大多数代码库是后者，甚至是一个相当大的块，您将遇到一个有趣的问题，即由于极度专业化而可能无法重构的代码，或者更糟的是，看起来像它的东西可能是可移动的，但是除非正确处理在文档中，您不知道是否要删除关键的代码（考虑一下scram操作的内容），乍一看似乎并不如此。

ElYusubov指出，尽管显然您的首要任务是在线进行某种版本控制，但从8.3版开始，确实支持版本控制。由于G2是几种不同语言方法的组合，因此您可能会发现使用G2随附的版本控制是最有效的方法，而不是尝试查找其他内容并使它工作。

接下来，尽管有些人可能会提倡开始重构，但我坚决主张在开始接触任何代码之前，请确保您完全了解要使用的系统，尤其是在处理由未经软件工程方法方面的正式培训（或背景）的开发人员。这样做的原因有多种，但最明显的原因是您正在使用的应用程序可能要投入超过100个人年的工作量，因此您确实需要确保您知道它在做什么以及需要多少工作。其中有文档。正如您没有说过，将系统部署到哪个行业，根据我对G2的了解，似乎可以肯定地认为它很可能是一项关键任务应用程序，甚至具有潜在的生命安全隐患。因此，准确地了解它在做什么将非常重要。它有未记录在案的代码，无法与团队中的其他人一起使用，以确保已建立文件以确保人们可以确定代码的作用。

接下来，开始围绕尽可能多的代码库和可视化图包装单元测试。对于如何使用G2做到这一点，我必须承认有些无知，但几乎值得创建自己的测试框架来实现这一点。这也是开始介绍团队中的其他成员以使他们使用与代码质量有关的一些更严格的工程实践的理想时机（即，所有代码都必须具有单元测试和文档）。

一旦在相当数量的代码上进行了单元测试，就可以按照haylem建议的方式开始进行重构。但是，请记住要记住，您正在处理的问题是开发专家系统并进行重构，这可能是艰巨的战斗。实际上，在这种环境下，有些事情是有时不编写极端通用代码的。

最后，请确保您仍密切注意其他团队成员所说的话，仅仅是因为代码和图表的质量不是最好的，不一定会对他们产生不良影响。最终，暂时而言，他们可能比您更了解应用程序的功能，这就是为什么坐下来并确保在进行全面更改之前确保了解应用程序的重要性。 />

#8 楼

通常，您预先听到的投诉与重要问题无关。毕竟，在任何软件项目中听到这些抱怨都是很正常的。

很难理解代码吗？检查一下大量的代码库？检查一下

真正的问题是人们离开了，而当新人加入组织时，就会出现一种典型的迷失方向。此外，还有一个不切实际的期望和代码质量问题。

我将按以下顺序处理：


服务器和本地版本的备份
设置错误跟踪器
设置版本控制系统
设置常见问题解答/ Wiki
所有科学家/程序员的首次汇报

提醒他们80/20规则。 20％的错误负责80％的问题。
关注最大的问题，并保留增强请求等。
这里的目的不是要吓people一大堆人，而是要列出一些可以实现的小胜利。毕竟，您还必须证明自己的价值。


设置构建系统

开始着手获取可靠的构建（这可能需要一段时间）
识别和命名每个项目
识别循环依赖项
如果某些开源项目有二进制文件，请尝试获取源代码


识别G2如何代码可以模块化，例如API，服务
确定如何测试和记录G2代码。
设置代码审查系统
第二次报告

理想的模块是什么样的？
如何关闭旧代码
如何在旧代码周围包装新模块（请参阅Strangler模式http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice -for.html）


确定一个精干的团队，由更优秀的程序员组成，并与他们合作包装模块。
现阶段存在代码审查，以改善沟通和文档编制。在此阶段保持简单。梳理任何过程问题。
向其他程序员推广该系统。让精明的团队成员成为其他团队的同伴导师。请记住，缩放是这里的问题。您实际上是担任管理角色。

#9 楼

诸如此类的问题是Software Carpentry项目存在的全部原因。

在过去的14年中，我们一直在教科学家和工程师基本的软件开发技能：版本控制，测试，如何模块化代码等等。我们所有的资料都可以通过知识共享（Creative Commons）许可免费获得，并且我们每年举办几十个为期两天的免费研讨会，以帮助人们入门。

基于此，我认为最好的出发点可能是罗伯特·格拉斯（Robert Glass）出色的（简短的）软件工程的事实和谬误：基于证据的方法是一种使科学家信服我们的好方法。对于特定的实践，人们最愿意采用的两个是版本控制和单元测试。一旦这些就绪，他们就可以解决Michael Feathers在“有效地使用旧版代码”中描述的那种系统重构。
我不再推荐The Pragmatic Programmer（很多建议，新手很难付诸实践），而且我认为McConnell的《代码完成》一开始就太多了（尽管一旦他们掌握了基础知识，给他们六个月或一年的时间是一件很棒的事情）。

我也强烈建议保罗·杜布瓦（Paul Dubois）的出色论文“在科学程序中保持正确性”（科学与工程计算，2005年5月至6月）描述了一种“深度防御”方法，该方法以逻辑，连贯的方式结合了十二种不同的实践。 >

#10 楼

我认为首先您必须清除您的情况。他们想从您那里得到什么？


他们不太希望您学习一门古老的语言，因为现在这似乎是一种死胡同：发现任何人知道的机会越来越少或想学习G2，因此当当前的科学家离开或全部修补的代码越来越失败时，这些知识将被埋葬在崩溃的代码堆中。
科学家（或其中一些）是否准备好了？学习一种新的语言和许多编程范例？还是他们希望从长远来看将编程和科学活动区分开来，并且如果需要的话，也许还有更多的程序员？这似乎是对专业知识的合理而有效的分离。

我认为这里的核心要求是“将知识保存在系统中”，因此您必须去挖掘它！

首要任务是编写文档。

分析结构和需求，好像这将是一项新任务，但是要借助现有系统。他们会很高兴，因为您先问而不是示教-您会很快获得足够的知识，但是从程序员的角度来看，它是更有组织的背景知识：“这里发生了什么？”这些文档（系统静态结构，工作流，组件，问题）对他们而言将立即有价值，并且可能会向您显示比您更多的相关信息（某些人可能拥有“ AHA！”并立即开始修复某些代码）...

然后您应该开始询问他们想去哪里？

如果他们准备离开G2，他们想看什么系统（平台，语言，界面，总体结构）？您可能会尽可能地在系统周围编写具有目标结构但保留原始组件的外部包装程序，从而慢慢启动一种框架，该框架允许在此目标环境中实现新组件。您必须找到核心服务（持久数据连接和“工具包”：核心计算，图形，...库），然后以新平台和语言为它们提供熟悉的环境，从而允许您或它们：将旧代码一个接一个地处理，并在新环境中重新实现（并清洁！）。准备就绪后，他们就会知道新的语言。并且服务层（大多数情况下是由您自己制作，很抱歉）已经可以托管新组件。否则他们应移动组件（清洁）。无论如何，该语言只是数据和算法树的序列化...

分析和编写文档，读取，使用和宣传GoF设计模式时！ :-)

...我的2美分

#11 楼

我刚刚为我的同事做了一系列关于Robert Martin的SOLID原则的演讲。我不知道这些原则如何很好地转化为G2，但是由于您正在寻找5-7个核心基础知识，因此这些基础知识似乎是一整套成熟的基础。如果要将其四舍五入到7，则可以从DRY开始并抛出Fail-Fast。

#12 楼

唯一的生产问题听起来像是变更管理问题。如果是这种情况，并且软件可以执行此操作，那么我要给出的第一条建议就是抵制过快地执行任务的冲动。 ，但是如果这是您第一次必须处理此类问题，并且进展缓慢，并且无法充分强调进行受控的更改。但是在对它进行足够的反向工程之前，您知道可以充分测试替代版本，因此需要非常小心。

#13 楼

在这种情况下工作的最重要原则是：


耐心等待。花了20年才挖的洞不会在几周内被填补。
保持积极。抵制抱怨和抱怨的诱惑。
务实。看看您一天可以完成的积极变化，今天就可以做到。有版本控制系统了吗？实施并培训人员。然后查看并查看是否可以自动化测试（单元测试或类似测试）。冲洗。重复。
做个模特。通过敏捷向人们展示（而不是仅仅告诉）敏捷如何工作。上面的前三点是成为好人的关键，而好人是成为有效的敏捷人的前身。我认为，令人钦佩的开发人员不仅聪明，而且也很优秀，可以为员工和同事树立榜样。
绘制您的领地。我有一种映射巨型遗留代码库的技术。我克隆了仓库，制作了工作副本，然后尝试更改某些内容，看看还有什么坏处。通过调查耦合（通过全局状态，或损坏的API，或缺少一致的API或要针对其编程的任何抽象或接口），并通过阅读在更改事物时会中断的代码，我发现了问题，提出了一些问题，团队其他成员的见解（哦，我们补充说，因为5年前的Boss X要求这样做，但它永远行不通！）。随着时间的流逝，您将获得该地区的思维导图。知道它的大小后，您将足以制作地图并回家。鼓励其他人映射您的巨型代码库的范围，并建立团队的技术知识。有些人不赞成“文档”，因为它不敏捷。随你。我也在科学环境中工作，文档对我来说是最重要的，敏捷的宣言也该死。
构建小应用程序。当使用遗留代码库时，我发现我陷入了困境。我通过构建一些小助手应用程序使我恢复了精神。也许这些应用程序将帮助您阅读，理解和修改庞大的G2代码库。也许您可以制作一个迷你IDE或解析器工具，以帮助您在环境中工作。在许多情况下，元编程和工具构建不仅可以帮助您摆脱旧代码库强加给您的巨大僵局，还可以使您的大脑不受G2语言限制地飞行。用您可以最快和最好的语言来编写工具和帮助程序。对我而言，这些语言包括Python和Delphi。如果您是Perl专家，或者您实际上喜欢C ++或C＃编程，请使用该语言编写帮助工具。教团队的其他成员构建少量的辅助应用程序和工具以及“组件”，您最终会发现您的旧版代码库毕竟并不那么令人生畏。

#14 楼

修订控制：向域专家展示能够还原，查看谁更改了内容等的好处。（对于全二进制文件，这比较困难，但是如果内容确实是代码，则肯定存在某种可以启用差异的G2到文本转换器。）
连续集成和测试：让领域专家参与创建端到端测试（更容易，因为他们必须已经在某处具有输入和预期的输出）且体积小涵盖几乎所有功能和用例的单元测试（较难，因为意大利面条代码可能涉及许多全局变量）。
将通用代码重构为可重用的例程和组件。没有修订控制权的非软件人员可能一次复制并粘贴100行以创建例程。找到它们并对其进行重构，表明所有测试都通过了，代码变得更短了。这也将帮助您学习其体系结构。如果到了必须开始做出艰难的体系结构决定的时候运气好的话，则可能会降低到100KLOC。进来并谈论好的软件方法论。确保找到一个您同意的意见的好人，并让管理者在顾问的必要性上有所作为，即使领域专家不同意。 （他们应该同意-毕竟，他们雇用了您，所以很显然他们意识到他们需要软件工程专业知识。）当然，这是一种浪费金钱的窍门，但是原因是，如果您-新的热门年轻人程序员-他们需要做某事，他们可能会忽略它。但是，如果管理层向一名顾问支付5000美元，让他们告诉他们他们需要做什么，他们就会对此更加信任。优点：让顾问为您提供两倍于您真正想要的更改的建议，然后您可以成为“好人”，并与领域专家一起，妥协仅改变顾问建议的一半。

#15 楼

“程序本身是复杂的化学加工厂的物理模型。 gadawful GUI ...“ – Erik Reppen



假设您软件的主要目标是模拟（或优化，运行参数估算）复杂的化工厂或一个工厂的一部分...那么我想提出一个截然不同的建议：

您可能会考虑使用高级数学建模语言从手工编码的软件中提取本质，核心数学模型，这可能很好。

建模语言的作用是将问题的描述与用于解决问题的算法脱钩。这些算法通常适用于给定类别的大多数模拟/优化（例如化学过程），在这种情况下，实际上不应重新发明和维护它们。

在您的行业中广泛使用的三个商业软件包是：gPROMS，Aspen Custom Modeller，以及（如果您的模型不包括沿空间域分布的现象）有基于Modelica的软件包，例如Dymola 。

所有这些软件包都以一种或另一种方式支持“扩展”，因此，如果模型的某些部分需要自定义编程，则可以将它们封装到对象（例如.DLL）中。可以由模型中的方程式引用。同时，您的模型的大部分内容仍然简洁明了，以易于科学家直接阅读的形式进行了描述。这是捕获公司知识和IP的更好的方法。

这些程序中的大多数还应允许您“从小开始”并将整体代码的小部分（子模型）移植到它们的内部。格式，可以从外部调用。这可能是维护工作系统并一次验证一个系统的好方法。

完全免责声明：我在gPROMS背后的公司工作了8年，担任软件工程师。在那段时间里，我看到了（有时是并入了）自定义软件（例如来自学术界）的示例，这些示例开始时小而整洁，实现了一些聪明的解决方案或算法，但随后几年又进行了扩展和修改，在没有用户指导的情况下爆炸了。保持软件清洁的软件工程师。 （我是跨学科团队的忠实拥护者。）

因此，我可以凭经验说，某些关键选择在软件开发的早期阶段就表现不佳（例如语言或密钥库）会长期困扰并造成痛苦……他们已经“塑造”了周围的软件。在我看来，您可能会在这里面临很多年的纯代码清理。 （我不愿意使用数字，但我想使用10人以上的年，如果您无法将代码从G2移植到支持良好的自动重构工具（例如Eclipse / Java快速智能工具）的情况下，可能会更多。 br />
虽然我的默认状态是“重构并保持正常工作的系统”，但我还认为，一旦问题变得“太大”，那么更彻底的更改/重写会更快。 （并且可能带来其他好处，例如，跳到更先进的技术。）我说，虽然有一些移植到新软件平台的经验，但是从我的经验来看，移植到数学建模包会更加生动。

为了提供一些观点，您可能会对尺寸减小感到惊讶。例如。实际上，这200,000个LoC可以用大约5,000行方程式表示（好的，我想在这里，但我可以尝试从企业朋友那里得到您的真实证明）；加上一些用C编写的相对较小的功能模块（例如，物理属性计算-尽管根据化学过程的不同，可能还会有现成的包装）。这是因为您实际上只是丢弃了算法解决方案代码，而让通用的“堆栈”数学求解器来完成艰苦的工作。运行模拟后，您可以使用它们做更多的事情，例如优化流程-无需更改代码行。

最后我要说的是：如果各种数学模型的唯一可靠文档（和算法）本身就是代码本身，那么您将需要科学家和原始作者的帮助，以尽快地将这些模型提取出来，而不是在某些模型可能继续发展的过程中走了几年。他们应该发现数学建模语言是捕获这些模型的一种非常自然的方式-他们甚至可能（震惊）喜欢（重写）它。


最后，由于我的回答可能不合常理，我只想在这里已经引用的好书清单中再增加一本书：Robert Martin的Clean Code。充满了简单（合理）的技巧，这些技巧易于学习和应用，但对于在公司中开发新代码的人们来说可能会大为不同。

#16 楼

我会抛弃以下内容：


这里有一个程序员。搞政治。他们知道自己的交易。你知道你的。标记该领土，即使您必须在上面撒尿。他们是科学家。他们可以尊重或应该尊重这种事情，因为他们自己经常不断地做同样的事情。尽您所能，立即标记边界。这就是我要解决的问题。这是我不负责的事情。
科学家编写/测试算法。想要以1-3种语言编写自己的算法的科学家，每个人都可以同意您将其转换为核心代码。这样就可以测试他们的东西了。除此之外，他们将不得不帮助您隔离重要的科学知识和良好的知识-他们对建筑所做的工作。代码库已连接。需要进行大量的削减和烧伤。给他们选择权，让他们使用他们最了解的东西来制作适合您的工作版本，以便您可以做自己最擅长的事情。将他们的知识放在他们负责但可以合作的盒子中。理想情况下，在大型重构上一切顺利时，对话将更多地是关于您可以使用界面进行哪些激动人心的事情，而不是drBobsFuncStructObjThingMk2_0109触手Z9惹恼全局变量X19a91时所做的事情。
使用事件驱动如果可能的话，具有一流功能的友好语言。当所有其他方法都失败时，如果您深陷于毫无血腥意义的代码中，那么触发一个事件或使用一个实际上有意义的接口和状态机制将回调扔给某个对象可能会节省大量的时间，而这些代码根本没有血腥意义，而且很可能永远不会将。科学家似乎喜欢Python。用它来粘合低级数学密集型C东西并不难。只是说“
”，寻找已经解决此问题或类似问题的人。花一些时间认真研究。这些人从某人那里听说过G2。
设计模式。适配器。使用它们。在这种情况下经常使用'em。
了解科学知识。了解的越多，就越能确定代码的意图。

#17 楼

首先进行分析。

在决定要教什么之前，我会做一些分析。找出最大的痛点在哪里。使用这些优先级来确定要进行哪些操作。

一次仅介绍一些更改（在类似情况下，我每2周进行2-3个练习）。

我会根据SDLC编程风格的变化程度将实践限制为〜3；直到他们开始对他们感到满意为止（我会推动每1至2周引入1个新更改，因为他们会更熟悉学习新方法的想法）。确定成功的标准也是一个好主意。练习应该完成什么（即使是像团队士气这样的软目标）。这样一来，您就可以证明它是否有效。


为什么要限制更改的数量？开放供人们学习，人们学习新概念并应用它们的程度和速度是有限的；尤其是如果他们没有CS基础或以前参加过软件开发生命周期。

添加每周总结会议，讨论这些实践如何影响他们。

会议应用于讨论进展顺利和需要解决的问题。让他们发表意见并保持合作。讨论并制定计划以解决他们遇到的问题，并预览即将发生的下一个更改。使会议集中在实践及其应用上。宣传他们从应用实践中应该看到的好处。

某些实践优先。

正确使用版本控制系统（IMO）胜过一切其他。紧随其后的是模块化，耦合/内聚和功能/错误单跟踪的课程。

删除无效的实践。

不要害怕摆脱无效的做法。如果成本高昂，几乎没有收益，请取消该做法。

改进是一个过程。

表明持续不断的改进是一个过程。确定最大的痛点，应用解决方案，等待/指导，然后重复。最初，您会感到非常痛苦的缓慢，直到您建立起一定的动力为止。让每个人都专注于即将到来的改进和已经成功的改进。

#18 楼

听起来您的第一步是将需要购买新软件方法的资金卖给团队。根据您的陈述，团队中没有共识，您将需要它能够缓慢地“升级”代码。

我会（如果可以的话）亲自吸取教训，并介绍您要解决的每个关键概念，以解决软件行业中的问题。

例如两名开发人员使用不同的副本，最终部署了一个未经测试的混合发行版本->引入了版本控制，分支和测试。 >介绍DDD。

如果没有与您充分分享艰苦的教训，那么请展示您自己的示例，说明在不遵守该学科的情况下怎么了。

#19 楼

如前所述，源代码控制是步骤1。虽然与您一起工作的人可能不是专业的开发人员，并且他们不会对很多企业或敏捷的大型企业做出回应。它们也不是低级代码猴子，而是通过强迫它们“按自己的方式”做事而无法像对待猴子那样对待它们。如果他们还没有使用源代码控制，那么仅仅确定正确的代码版本（如果可能）以及所有可能的交付结果将花费很长时间。然后，您将承担着教您的同事如何使用源代码控制并说服他们相信自己的时间值得的任务。从好处开始！

在执行此操作时，请找到其他低挂的水果并解决这些问题。

最重要的是，听取他们的意见，并努力改善他们的处境。不必担心会给自己加盖印记。

祝你好运！