Questions tagged «maintainability»

下面的示例完全是人为的，其唯一目的是使我理解我的观点。 假设我有一个SQL表： CREATE TABLE rectangles ( width int, height int ); 域类： public class Rectangle { private int width; private int height; /* My business logic */ public int area() { return width * height; } } 现在假设我有一个要求向用户显示数据库中所有矩形的总面积。我可以通过获取表的所有行，将它们变成对象并对其进行迭代来做到这一点。但这看起来很愚蠢，因为我的桌子上有很多矩形。 所以我这样做： SELECT sum(r.width * r.height) FROM rectangles r 这很容易，快速并且利用了数据库的优势。但是，它引入了重复的逻辑，因为我的域类中的计算也相同。 当然，对于这个例子，逻辑的重复根本不是致命的。但是，我的其他域类也面临同样的问题，它们更为复杂。

21 architecture  maintainability 

我具有强大的OO背景，并且我最近开始在一个组织中工作，尽管该代码是用Java编写的，但与过去相比，我对良好的OO设计的重视程度要低得多。有人告诉我，我引入了“太多的抽象”，而我应该以一直采用的方式编写代码，这是Java中的一种过程样式。 TDD在这里也不太常用，但是我想拥有可测试的代码。在大型“神类”（这似乎是该团队的常态）中以静态私有方法掩埋业务逻辑不是很可测试的。 我很难向同事清楚地传达自己的动力。有谁对我如何说服我的同事使用OO和TDD导致更容易维护的代码有任何建议？ 这个问题有关技术债务是关系到我的问题。但是，我试图避免首先产生债务，而不是在另一个问题所涵盖的事实之后偿还债务。

21 java  object-oriented  teamwork  communication  maintainability 

假设您在一家公司工作，而您所要做的就是为他们开发软件。您不了解总体情况，也可能不了解。您所拥有的是通过问题跟踪系统分配给您的任务。您得到了任务，使它们按照任务描述它们的方式工作，然后将其发回。像加2个整数： function add(a,b){return a + b;} 但是后来，随着项目的进行，您注意到随着add变得越来越复杂，您意识到它应该需要某种形式的体系结构，而不仅仅是添加参数并返回值的函数。但是，您不知道。首先，他们所需要的就是这么简单add。您没想到add会变得如此复杂。 该项目具有更多功能，而您最初没有想到这些功能。最后，您将不断堆积各种技巧和功能，以免破坏/重写现有代码。 您如何处理这些情况？作为“最低开发商”，您如何应对技术债务？ 澄清： 您是层次结构中最低的“实施者”。 您看到了问题，但对此没有发言权。 我不是在量化技术债务或寻找工具。 关于第三个“重复” 重构和重写-您被锁定在任务上。您无需支付额外费用。 体系结构概述-您了解整个系统，但不了解体系结构。 代码冻结-不是您的电话。您不是管理者。 模块化-不了解架构。模块随需求的变化而变化。 自动化测试-不存在。

20 architecture  software  scalability  maintainability  technical-debt 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 可维护性是专业软件开发的主要利益。确实，维护几乎始终是软件生命周期中最长的部分，因为维护从项目发布一直持续到基本上结束。 此外，维护中的项目占项目总数的绝大多数。根据http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/，维护项目的比例约为2 / 3。 我最近遇到了一个问题，那个家伙发现他的工作主要是维护工作，对此感到非常惊讶。然后，我决定在法国软件开发专业人员社区的主要站点（http://www.developpez.com/）上进行讨论（法语）。讨论的标题是“学生是否对专业软件开发的现实进行了足够的培训？” 并且主要是关于可维护性。有人指出，至少在法国，人们没有足够的准备面对两方面的维护： 维护现有代码 制定可维护的代码 我在这里的问题与该讨论相呼应，旨在寻找一种教授维护性的好方法。 我们如何教授可维护性？ 您会建议哪种运动？ 如果您在可维护性方面受过良好的培训，那么您选择了哪种课程？ [编辑]经过一些误会，我认为我必须澄清我的问题。作为项目负责人和软件开发人员，我经常与受训人员或应届毕业生一起工作。我曾经刚毕业。问题是学生通常不熟悉诸如SOLID之类的原理，这些原理会增加项目的可维护性。我们常常最终在使项目发展方面遇到重大困难（可维护性低）。我在这里寻找的是一个成功的关于可维护性的重要性以及如何针对此特定点编写更好的代码的成功教学的具体学术示例。或可能提出的改善学生训练方式的建议。

18 programming-practices  education  maintenance  maintainability 

我们团队中的一位开发人员认为，有必要为方法签名中的每个参数编写一个Javadoc注释。我认为这不是必要的，实际上我认为这甚至是有害的。 首先，我认为参数名称应具有描述性和自我记录性。如果您的参数的用途不是很明显，那么您可能做错了。但是，我确实知道，有时不清楚参数的用途，因此在这种情况下，应该编写一个Javadoc注释来解释该参数。 但是我认为没有必要对每个参数执行此操作。如果该参数的作用已经很明显，则javadoc注释是多余的；您只是为自己创造了额外的工作。此外，您还为需要维护代码的任何人创建了额外的工作。方法会随着时间而变化，维护注释几乎与维护代码一样重要。您有多少次看到“ X是Y导致Z原因”这样的注释，只是看到该注释已过时，实际上该方法甚至不再使用X参数？它总是发生，因为人们忘记了更新评论。我认为，误导性评论比根本没有评论更具危害性。因此存在过度注释的危险：通过创建不必要的文档，您可以 但是，我尊重团队中的另一个开发人员，并接受他也许是对的，但我错了。这就是为什么我会向其他开发人员提出您的问题：确实有必要为每个参数编写一个Javadoc注释吗？在此假设该代码是我公司内部的代码，任何外部方都不会使用。

18 java  documentation  source-code  comments  maintainability 

我尝试为我的GUI应用程序编写UI单元测试，但我遇到的问题是，尽管在我最初编写它们时它们可以很好地工作，但是它们却很脆弱，并且每当设计更改时（即经常）它们就会损坏。我正在努力寻找一套指导方针，以使我能够进行GUI的可维护单元测试。 就目前而言，我发现的一件事是，测试表明“该组件应在某处显示其输入数据”是很好的（并且使用HTML非常容易）。检查组件特定部分的特定状态的测试通常很脆弱。试图遵循用户行为和基本业务逻辑（这是最重要的部分）的测试，如单击-单击-单击-预期，通常会变得很脆弱。如何编写好的测试？ 更精确地说，我想了解一些模式有什么可我在UI测试，不完全是如何对其进行测试。命名约定和固定标识符很好，但是不能解决核心问题，即GUI发生了很大变化。我想测试最不可能改变的行为。如何找到合适的东西进行测试？

16 unit-testing  language-agnostic  user-interface  maintainability 

背景 我正在进行中的C＃项目。我不是C＃程序员，主要不是C ++程序员。因此，我基本上被分配了简单的重构任务。 该代码是一团糟。这是一个巨大的项目。由于我们的客户要求频繁发布具有新功能和错误修复的程序，因此所有其他开发人员在编码时都被迫采取暴力手段。该代码极难维护，所有其他开发人员都同意。 我不是在这里辩论他们是否做对了。在重构时，我想知道我是否以正确的方式进行操作，因为重构后的代码似乎很复杂！这是我作为简单示例的任务。 问题 有六类：A，B，C，D，E和F。所有的类都有一个功能ExecJob()。所有六个实现都非常相似。基本上，起初A::ExecJob()是写的。然后需要一个稍有不同的版本，该版本B::ExecJob()通过对的复制粘贴修改进行实现A::ExecJob()。当需要另一个略有不同的版本时，C::ExecJob()编写此类代码。所有六个实现都有一些通用代码，然后有一些不同的代码行，再有一些通用代码，依此类推。这是实现的一个简单示例： A::ExecJob() { S1; S2; S3; S4; S5; } B::ExecJob() { S1; S3; S4; S5; } C::ExecJob() { S1; S3; S4; } SN一组完全相同的语句在哪里。 为了使它们通用，我创建了另一个类并将通用代码移到函数中。使用参数控制应执行的语句组： Base::CommonTask(param) { S1; if (param.s2) S2; S3; S4; if (param.s5) S5; } A::ExecJob() // A inherits Base { param.s2 = …

16 self-improvement  refactoring  maintainability 

我认为自己是编程语言爱好者。当我发现错误的代码（尤其是我自己的代码）时，很难理解，更改和测试。 我的同事们并不了解，或者不在乎。我为自己无法提高代码质量而感到沮丧。 当代码质量和可维护性不符合我的标准时，感到沮丧是正常的吗？如果是这样，您如何处理？

12 code-quality  maintainability 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 我主张对源代码进行评论并记录软件产品。根据我的个人经验和观察，在必须开发软件或维护软件的过程中，对经过严格注释的源代码进行的工作以不同的方式帮助了我。 但是，还有一个阵营说评论最终毫无价值，或者其价值值得怀疑。许多不加评论的编码支持者认为： 如果一段代码写得很好，那是自我解释，因此不需要注释 如果一段代码不是不言自明的，则对其进行重构并使其变得不言自明，以便它不需要任何注释 您的测试套件就是您的实时文档 随着时间的流逝，代码和注释不同步，这成为令人头疼的另一个原因 敏捷表示工作代码比大量文档更重要，因此我们可以放心地忽略编写注释 对我来说，这只是教条。再次，我个人的观察是，由才华横溢，经验丰富的开发人员团队编写的软件最终最终会产生大量不言自明的代码。 同样，Java API，Cocoa API，Android API等表明，如果您要编写和维护高质量的文档，则可以实现。 综上所述，基于个人信念的有关文档优缺点的讨论以及对源代码的评论通常不会以良好的结局而无法得出令人满意的结论。 因此，我正在寻找有关软件文档（尤其是注释源代码）对其质量和可维护性及其对团队生产力的影响的影响的学术论文和实证研究。 您是否偶然发现了此类文章？如果有的话，结果如何？

11 productivity  documentation  code-quality  maintainability  engineering 

哪个将更易于维护？ if (a == b) c = true; else c = false; 要么 c = (a == b); 我尝试在“代码完成”中查找，但是找不到答案。 我认为第一个更具可读性（您可以从字面上大声读出来），我也认为这使其更易于维护。第二个当然更有意义并减少了代码，但是我不确定它对于C＃开发人员是否可维护（我希望在Python中会更多地看到这种用法）。

11 .net  code-quality  readability  maintainability  clean-code 

给定一个旨在为应用程序添加新功能的小型项目，所引入的更改涉及一些现有代码，涉及在某些领域中进行更新。在实施期间，我发现其中一些更新的代码具有重构的候选对象。 这是否是一个适当的重构时间，从而又需要对受影响的那些组件进行回归测试（因此可能引入的范围最初不是项目的一部分）？还是我应该推迟，完成功能，也许有一个单独的项目进行重构（尽管我有点犹豫，因为业务用户可能不会完全赞助一个不添加任何功能的项目，除非他们重视代码的可维护性...）？

11 testing  refactoring  decisions  maintainability  scope 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我在另一个开发人员接手的程序中遇到以下条件： if (obj.Performance <= LOW_PERFORMANCE) { obj.NeedsChange = true; } else { obj.NeedsChange = false; } 我相信这段代码是多余的和丑陋的，因此我根据比较将其更改为我认为是简单的布尔分配： obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE; 看到此消息后，查看我的代码的人评论说，尽管我的更改在功能上是正确的，但可能会使其他人困惑。他认为使用三元运算符可以使此分配更加清晰，而我不喜欢添加更多的冗余代码： obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE) ? true : false; 他的理由是，如果这样做会使另一个开发人员不得不停下来并确切地想出自己所做的事情，那么以最简洁的方式做某事是不值得的。 真正的问题是，这三种为布尔值赋值的方法中哪一种obj.NeedsChange最清晰，最可维护？

10 clean-code  maintainability  boolean 

我想添加一个在这种情况下在Netbeans中创建的项目，但是这个问题对于大多数IDE来说都是通用的。很简单，我应该在存储库中包含什么。例如，Netbeans创建一个nbproject文件夹，eclipse创建一个.settings文件夹等。如果我将这些包含在我的存储库中，则包含或不包含项目特定设置的优点/缺点是什么？ 在这种情况下，这是一个个人项目，因此我不认为其他人会开始进行该项目，但是最好添加最少的项目设置，这样项目本身就可以轻松在不同的机器上开始工作。

10 programming-practices  git  project  maintainability 

在可以忽略性能影响（最大每秒10-20个事件）的应用程序框架中， 什么是更可维护且更灵活的方法，可以用作模块之间进行通信的首选介质-事件还是期货/承诺/单子？ 人们常说，事件（发布/订阅，中介）允许松散耦合，因此-应用程序更易于维护...我的经验否认这一点：一旦您拥有20多个事件，调试就会变得很困难，重构也会变得更加困难-因为很难看到：谁，何时何地使用什么。 承诺（我用Java语言编写）比事件要丑陋得多。但是：您可以清楚地看到函数调用之间的连接，因此应用程序逻辑变得更加简单明了。我怕什么 但是，Promises会带来更多的困难吗？ ps：答案不一定基于JS，非常欢迎其他功能语言的经验。

10 architecture  maintainability  async  event-programming  monad 

我有一个逻辑密集型算法，需要用两种语言进行编码（实际上，我已经令人满意地用一种语言完成了编码，并且即将开始用另一种语言进行编码）。逻辑密集型是指算法不平凡，需要仔细理解，并且重要的是，可能存在将来必须修补的错误（由于复杂和粗心，您知道）。 另外，我想确保当这些代码易手时，它一定不会使新的程序员不知所措。 在这种情况下，有哪些方法可以帮助维护代码库并使它们保持同步？我的意思是软件工具，最佳做法等。 仅供参考，两种语言是C ++和Java。适用于Windows / Linux的C ++和适用于“其他所有东西”的Java（包括Android）。

10 maintenance  maintainability