如何提高对学生的可维护性的培训？[关闭]

可维护性是专业软件开发的主要利益。确实，维护几乎始终是软件生命周期中最长的部分，因为维护从项目发布一直持续到基本上结束。

此外，维护中的项目占项目总数的绝大多数。根据http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/，维护项目的比例约为2 / 3。

我最近遇到了一个问题，那个家伙发现他的工作主要是维护工作，对此感到非常惊讶。然后，我决定在法国软件开发专业人员社区的主要站点（http://www.developpez.com/）上进行讨论（法语）。讨论的标题是“学生是否对专业软件开发的现实进行了足够的培训？” 并且主要是关于可维护性。有人指出，至少在法国，人们没有足够的准备面对两方面的维护：

• 维护现有代码
• 制定可维护的代码

我在这里的问题与该讨论相呼应，旨在寻找一种教授维护性的好方法。

• 我们如何教授可维护性？
• 您会建议哪种运动？
• 如果您在可维护性方面受过良好的培训，那么您选择了哪种课程？

[编辑]经过一些误会，我认为我必须澄清我的问题。作为项目负责人和软件开发人员，我经常与受训人员或应届毕业生一起工作。我曾经刚毕业。问题是学生通常不熟悉诸如SOLID之类的原理，这些原理会增加项目的可维护性。我们常常最终在使项目发展方面遇到重大困难（可维护性低）。我在这里寻找的是一个成功的关于可维护性的重要性以及如何针对此特定点编写更好的代码的成功教学的具体学术示例。或可能提出的改善学生训练方式的建议。

我们如何教授可维护性？

这是一个实践问题。

我能想到的以受控方式实践它的最直接的方法是，模拟典型的维护项目如下。

获得一些做得很好的项目（Project A），并在其中引入一些问题：注入一些错误，一堆重复的代码和死代码，删除一些功能，单元测试和文档等等。您甚至可能会有专门的知识为此命名，例如Project A损坏的版本。

建立问题追踪器，并填写与您造成的特定损失相对应的请求。建立开发过程的基本规则和实践-VCS提交，代码审查，质量检查等-考虑从Joel测试中提供的检查清单中获取帮助。

• 课程工作1.
  修复错误，添加缺少的单元测试，文档和功能。
• 课程2.
  重构。
• 课程3.
  维护/改进明年学生要使用的原始项目
  - 项目A版本2.0和项目A-损坏的版本2.0。
  _{通过改进损坏的版本，我的意思是对其进行更好的教育性损坏。:)}

在上述实践中，应特别注意代码审查的实践。这可能是确保代码易于维护的最有效方法，例如，如相关问题中的最高答案所示。

免责声明：我刚刚获得了CS学位。我不是老师

这听起来似乎很明显，但是我认为教授代码维护的最佳方法是让学生执行代码维护。这就是我要做的：

1. 考虑一个中等复杂的问题，两个实现在语义上是相同的，但是一个实现比另一个实现更具可维护性。
2. 要求进行许多更改/功能添加，这些更改/功能添加在更好的代码库上更容易实现。一半的学生必须在易于维护的代码基础上实施这些，另一半则在难以维护的代码基础上实施。
3. 为了公平起见，您可能需要重复角色相反的过程。
4. 比较好代码库和坏代码库之间成功实现的更改的平均数量，以及实现它们所花费的时间。让学生分享他们的经验，表达他们的不满，并大体上谈论他们所做的工作。

这样做的想法不仅是让学生使用他人的代码，而且还使他们对可维护代码产生赞赏，这有望提高他们的设计技能。

可维护性是一种美德，而不是一种技能。创建可维护项目的方法很多，但是没有一种保证可以产生这些项目的公式。

如果您珍视诸如善良和慷慨之类的美德，那么您会寻找在日常生活中实践同样美德的方法。可维护性是相同的：如果您和您的组织重视可维护性，那么在设计和实施项目时，您会把它牢记在心。花费一些额外的时间来构建某些东西是合理的理由，因为您知道维护性受到赞赏。相反，不鼓励在不重视组织的组织中花费额外的时间以保持可维护性。

如果要教人们使​​事物具有可维护性，则应首先明确组织要重视可维护性。在项目的需求中指定它。使它成为成功进行代码审查的标准之一。简而言之，使可维护性成为您文化的一部分。

接下来，愿意投入一些资源来改善现有项目的可维护性。确定项目中那些会不断出现错误，修复错误或进行更改非常困难且需要很长时间的部分，然后重新设计或重构以便于维护。

最后，通过将新开发人员分配给每天已经练习过的团队，将他们灌输到您的可维护性文化中。没有比给他们很多好的榜样和指导更好的方法来帮助某人采用一种价值观。

我不喜欢与软件开发有关的术语“可维护”。现实是，所有软件都是可维护的，因为它可能需要进行维护工作，因此，相对而言，真正的问题是维护软件是昂贵还是便宜。我知道这听起来像是在回答之初就非常脚的陈述，但是我的观点很快就会变得更加清楚。

软件开发专业的IT学位的问题在于，他们实际上只会教给学生关于编写软件所需的最低知识。专业技能和知识是通过在学习后的头几年完成的学习而获得的有资格获得学位。这是当一个毕业生开始在一个执行压力很大的环境中进行对客户真正重要的项目时，他们的期望是创建符合专业标准的产品。令人遗憾的是，许多公司不鼓励维护软件专业标准的文化，而最终导致开发和维护成本高昂的项目。不幸的是，对于我们的毕业生而言，他们在职业生涯的早期阶段就在这种环境中学习了许多不良习惯，而且要学会克服这些习惯可能要花很长时间……如果有的话。

最好教学生如何编写干净的代码，以及如何识别软件中通常会招致技术债务的问题。以入门为起点，着眼于有关干净代码，重构和精益软件开发的书籍，并教学生在实施代码之前编写单元测试，以确保高度的测试覆盖率。教学生识别代码中的重复和重复模式，以及如何重构代码以消除此类重复。帮助学生理解和应用诸如SOLID和DRY之类的原理。最重要的是，消除这种想法，即仅基于代码的设计和实现就可以维护代码，而是从一开始就在软件生产中灌输手工艺和质量感，力求在实施过程中改进代码，以最大程度地减少技术债务的影响，从而将软件维护成本降至最低。

我认为学习这类技能的最佳方法是进行代码审查和配对编程。在代码审查期间，经验丰富的人员可以指出如何使代码更具可维护性（通常是使代码更具可读性），并说明为什么某些选择可以创建更具维护性的代码的理由。

结对编程是一种更好的方法来教授这种事情，因为它使经验不足的员工可以直接与已经知道如何做好的人一起维护代码。

您还可以阅读一些很棒的书，以编写干净，可维护的代码。干净的代码浮现在脑海。

由于学生很少修改大型代码库，因此很难通过学术界获得这种经验。这些技能大部分将来自在职学习，而代码审查和结对编程确实可以促进这种学习。

好的代码=更少的维护，易于增强/添加功能。

错误代码=维护噩梦

基本上，我们必须向学生指出：“每当项目中有糟糕的代码时，新开发人员便会加入公司，因为代码的原始作者将受到影响，并且软件将受到怎样的影响。”

因此，向学生讲授软件维护的最佳方法之一是展示好代码和坏代码的示例，并要求他们添加功能，然后教他们写好的代码不仅是为了自我满足，而且是为了使对于要维护代码的人来说，这很容易。

行使：

1）有一个预先写好的坏代码（例如重复代码），在项目的9个地方写一个“计算抵押付款”的方法。

要求学生增强此功能，以“向所有抵押付款增加1.2％的附加费”。

现在，学生将看到在所有9个位置定位和修复代码的痛苦。他有很多机会无法找到所有9个按揭付款地点。

2）现在显示具有此方法的Good代码，该方法可以在一个唯一的地方计算抵押付款。向学生证明增强编写好的代码有多容易，并向他解释如何提高代码/项目的可维护性。

顺便说一句，我喜欢您使学生接触到软件可维护性的方法。

@mattmattj：因为有很多答案，而且我发布的链接也有一些很好的指针，所以我将添加一些内容，希望这不是已经发布的答案的重复。

首先，一个必须定义“可维护性”-没有一个所有人都接受的定义-与软件体系结构类似。因此，请选择您认为最重要的一项，并以3-4行为单位进行陈述。然后，您可以讨论一些度量标准，例如-重新收集/理解您自己的代码（或其他人的代码）的时间，每分钟/小时的WTF数量等。保持轻量（幽默）-使它们更容易接受您拥有的内容在那之后说。

一些练习（听起来有些回应有些重叠，请原谅）

将课程分为两部分-为一节提供一个简单的编码作业，需要在1-2天内完成。最高 艰苦的最后期限。他们必须在所有情况下都完成工作-准则-认为合适的“工作代码”。对于另一组学生，则分配相同的作业，但带有（命名）约定的列表以及一些有关设计的指南，以及如果不遵循该规定将如何扣除分数。即使听起来像，这也不是作弊；）现在让他们交换代码，即第1组现在可以处理第2组所做的事情，反之亦然。现在建议对原始编码分配进行修改，并要求他们在同一时间范围内进行编码。重新召集他们，问他们当时有多么容易/困难，并让他们进行讨论/提出意见。这一点肯定会到家了-课堂上50％的人很高兴并且觉得很容易，而50％的人觉得很困难。您还可以要求他们在3周后完成自己的工作，然后看看他们是否可以在一天内完成；）

（一个不错的选择是，您以复杂的方式编写同一段代码，并随同自己的代码一起修改该类）

您在这里奠定了可维护性的基础-修改/更新的每一行代码都会花费公司资金。读取和重新收集代码越容易，修改得越好/越快，这将有助于缩短上市时间。在当今快速发展的技术领域中非常重要。可维护性是系统高效发展的关键。

重要的是要理解未开发项目和未开发项目之间的区别-并非每个项目或系统都是从头开始创建的（很难找到或成为“从头开始”项目的一部分）。解释该字段是“固有的”棕色，并且当它逐渐变得“失控”时（最终仅在漂移太大且“无法维护”时才可能逐渐淘汰），您必须花时间整形它。他们越早接受越好。这是很困难的，因为编程本质上是有创造力的，但是增强别人的代码并不是这样的-扭转它。创造力可以理解代码，然后应用“您的”创造力来增强它-如果维护得更好，将来您将能够更有创造力地增强它。

请随意在上面的链接中引用意大利面的类比...希望这有助于使您有所了解。其他答案有助于填补空白，应该对您的教学有所帮助！祝你好运！