Questions tagged «maintenance»

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 纽约-爆炸使摩天大楼震颤，一条已有83年历史的蒸汽管发出了强有力的信息，即纽约和美国其他城市下方的管道，电线和铁条的英里数正在老化，并且可能变得危险地不稳定。 2007年7月关于曼哈顿爆裂的蒸汽管的故事 我们听说过软件腐烂和技术债务。 我们已经收到以下消息： “鲍勃叔叔”马丁-谁警告过我们“ 弄乱的后果 ”。 迈克尔·C·费瑟斯（Michael C. Feathers）-谁为我们提供了“有效使用旧版代码”的指南。 因此，软件工程界当然可以意识到这些问题。 但是，我觉得我们整个社会都不喜欢这些问题如何困扰工作系统和应用程序。 正如史蒂夫·麦康奈尔（ Steve McConnell）所说： ...与金融债务不同，技术债务不那么明显，因此人们可以轻松地忽略它。 如果这是真的，我相信是这样，那么我担心政府和企业可能会推迟对黑客的定期维护和防御，直到为时已晚。[很像纽约市和蒸汽管。] 我的问题： 有没有一种方法可以避免使用等效于NYC和蒸汽管道的软件？

15 maintenance  legacy  technical-debt 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 如标题所述，可选参数（例如C＃中使用的那些参数）是否有用，还是对应用程序维护的障碍，应避免使用，因为它们会使代码更难于理解？

15 language-features  maintenance 

如果我使用switch语句来处理枚举（属于我的班级）中的值，并且每个可能的值都有一个大小写，是否值得添加代码来处理“默认”大小写？ enum MyEnum { MyFoo, MyBar, MyBat } MyEnum myEnum = GetMyEnum(); switch (myEnum) { case MyFoo: DoFoo(); break; case MyBar: DoBar(); break; case MyBat: DoBat(); break; default: Log("Unexpected value"); throw new ArgumentException() } 我不认为这是因为永远无法到达此代码（即使使用单元测试也是如此）。我的同事不同意并认为这可以保护我们免受因将新值添加到MyEnum而导致的意外行为。 社区，你怎么说？

15 unit-testing  maintenance  enum 

您是否曾经遇到过代码重复的案例，在这种情况下，在查看代码行时，您无法对其进行专题描述以忠实地描述其在逻辑中的作用？您做了什么处理呢？ 这是代码重复，因此理想情况下，我们需要进行一些折光处理，例如使其具有自己的功能。但是由于代码没有一个很好的抽象来描述它，所以结果将是一个奇怪的函数，我们甚至无法为其找到一个好名字，而且从逻辑上看，它在逻辑中的作用并不明显。对我来说，这损害了代码的清晰度。我们可以保留清晰度并保持原样，但随后会损害可维护性。 您认为解决此类问题的最佳方法是什么？

14 design  maintenance  refactoring 

我有很强的Java / Groovy背景，并且已被分配给一个为管理软件维护大量C代码库的团队。 Java Web服务已经外部化了一些痛点，例如处理数据库中的Blob或生成PDF和Excel中的报告。 但是，作为Java开发人员，我对代码的某些方面感到有些困惑： 它很冗长（尤其是在处理“异常”时） 有很多巨大的方法（很多2000行以上的方法） 没有高级数据结构（我很想念List，Set和Map） 无需关注（SQL在代码中充满欢乐） 结果，我觉得企业隐藏在大量的技术代码中，而我的大脑（由面向对象和少量的功能编程所塑造）并不轻松。 该项目的好处是代码简单明了：没有框架，没有运行时的字节码操作，也没有AOP。并且服务器可以通过使用比Java吐出“ hello world”所需的内存更少的内存，在一台计算机上同时回答10000多名用户。 我想学习如何根据公认的现代原理编写C代码。关于如何编写和构造现代C，是否有任何公认的原则？ 有点像“有效Java”书的等效内容，但适用于C。 根据答案和评论进行编辑： 我将尝试使我的思维方式适应C代码，而不是尝试将其镜像到OOP。 我已经开始从评论中扫描推荐的编码风格指南（GNU编码标准和Linux内核编码风格）。 然后，我将尝试向我的同事提出这种代码样式。最困难的部分可能是说服同事，将巨大的方法拆分为较小的部分，并且借助一种方法可以避免重复相同的4行错误处理代码。

13 c  maintenance 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 在最近的三份工作中，我是代码维护者。在这三种情况下，我都已经为该项目编写了大部分代码后才被雇用。 我是一个自学成才的程序员。在开始我的第一份专业工作之前，我大概有十几个项目可以成功启动并交付。 编写新代码和维护现有代码是两个完全不同的工作。就像将航空工程师和飞机技师进行比较。 当您是由一名工程师设计的飞机机械师，而该工程师没有试图使飞机以任何逻辑或易于维护的方式设计时，这种情况尤其糟糕。 我开始感觉像在项目刚开始时就在身边，您必须是那些以某种方式超越了计算机科学领域其他人员的特殊人员之一。处于那个位置需要什么？ 我觉得这个问题确实没有简单的答案，但是有人可以给我一些见解吗？您曾经在一个新项目的底层吗？到达那里需要什么？

13 education  refactoring  training  maintenance  industry 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我们公司即将获得一个巨大产品的源代码。 开始移交时要考虑哪些事项，以确保我们拥有一切并能够在将来维护该产品？

12 documentation  maintenance  knowledge-transfer 

在现有代码库的项目中，您如何处理编码标准/样式指南中的演变？假设您的团队中的某人在编程语言中发现了一种更好的对象实例化方法。并不是说旧的方法是不好的或越野的，而是新的方法不再那么冗长，而感觉却更加优雅。所有团队成员都非常喜欢。您会更改所有现有代码吗？ 假设您的代码库大约有500.000多行代码。您是否仍要更改所有现有代码？还是只让新代码遵守新标准？基本上失去一致性？ 您如何处理项目编码标准的演变？

12 coding-standards  coding-style  maintenance 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 实际上，此问题与要采取的谨慎措施有关，以提高质量的用户体验并减少可避免的支持电话。

12 maintenance  bug  user-experience 

我目前的工作主要是为我们正在处理的各种应用程序编写GUI测试代码。但是，我发现我倾向于在测试中复制和粘贴很多代码。原因是我正在测试的区域趋于足够相似以至于需要重复，但还不够相似以至于无法将代码封装到方法或对象中。我发现，当我尝试更广泛地使用类或方法时，测试变得更加笨重，有时甚至一开始就很难编写。 取而代之的是，我通常从一个部分复制大量测试代码并将其粘贴到另一部分，然后进行我需要的任何细微更改。我不使用更结构化的编码方式，例如使用更多的OO原理或函数。 其他编码人员在编写测试代码时有这种感觉吗？显然，我想遵循DRY和YAGNI原则，但是我发现测试代码（无论如何都用于GUI测试的自动测试代码）会使这些原则难以遵循。还是我只需要更多的编码实践和更好的整体服务系统？ 编辑：我正在使用的工具是SilkTest，这是一种称为4Test的专有语言。同样，这些测试主要针对Windows桌面应用程序，但是我也使用此设置对Web应用程序进行了测试。

12 testing  code-quality  maintenance  test-automation 

这是一个相当模糊的问题，但这是我在阅读有关适当设计的内容时从未感到满意的答案。 通常，在学习面向对象的编程，抽象，分解等方法时，设计的圣杯以及它们始终声称您使用的是开发技术的原因是，这将使您的程序“易于更改” ，“可维护的”，“灵活的”或用于表达这种有效果的概念的任何同义词。通过将ivars标记为私有，将代码拆分为许多小的自包含方法，使接口保持通用，可以使您完全轻松自如地修改程序。 对于较小的更改，这对我来说效果很好。改变类以提高性能所用的内部数据结构从来都不是主要困难，而且独立于API的用户界面端也没有改变，例如重新设计文本输入系统或检修游戏元素的图形。 所有这些更改似乎天生就是独立的。就所涉及的外部代码而言，它们均不涉及对要修改的程序组件的行为或设计进行任何更改。无论您是以程序编写还是以OO样式编写（具有大型功能还是小型功能），即使您只有中等程度的设计，也可以轻松进行这些更改。 但是，每当更改变得繁琐而繁琐时（即，对API进行更改），我的所有宝贵“模式”都无法挽救。巨大的变化仍然很大，受影响的代码仍然受到影响，并且大量的错误产生工作摆在我面前。 所以，我的问题是这个。适当的设计声称能够促进多大的变化？是否有一些其他的设计技术，或者对我来说是未知的，或者是我没有实现，确实确实使粘滞性修改变得简单，还是那个承诺（我听说过这么多不同的范例）仅仅是一个好主意，完全脱离了软件开发的一成不变的真理？我可以添加到工具栏中的“更改工具”吗？ 具体来说，导致我进入论坛的问题是：我一直在努力实现一种解释性编程语言（在D中实现，但这无关紧要），并且我决定将闭包的参数设为基于关键字，而不是当前的位置。这就需要修改所有现有的调用匿名函数的代码，幸运的是，这很小，因为我很早就开发了我的语言（<2000行），但是如果我稍后再做出决定，那将是巨大的。在这种情况下，是否可以通过适当的预见性设计使修改变得更容易，或者确定（大多数）变化本质上影响深远？我很好奇这是否是我自己的设计技能的失败-如果是的话，我 明确地说，我绝不怀疑OOP或其他常用的模式。但是，对我而言，它们的优点在于代码库的原始编写而不是维护。继承使您可以很好地抽象出重复的模式，多态性使您可以通过人类理解的函数（哪个类）而不是由机器理解的效果（switch语句的哪个分支）来分离代码，而小的独立函数可以让您以一种非常愉快的“自下而上”的风格写作。但是，我对他们的灵活性表示怀疑。

11 design  object-oriented  maintenance  abstraction  changes 

我最近刚在一家新公司工作，当时只有少数程序员。它是一家中等规模的公司，大约有70名员工，但IT部门只有9-10名，而我旁边还有3位“程序员”。但是，这些人的经验非常有限，确实在做很多事情。例如，我们的一个项目是PHP网站。大多数代码存储在20,000行的PHP控制器中，PHP中嵌入了约6000行的JavaScript。 我在这里和那里不断地提出一些小建议，但是没有人在听，每个人都说他们太忙了，无法执行我的建议。问题是，他们不应该那么忙，如果事情做对了也不会。他们将大部分时间都花在修理不断破裂的东西上。如果每个项目构建正确，我自己就能完成。 我应该采取什么方法说服这些人或经理，那就是事情需要改变，而改变事物可以节省很多时间？我是否应该跳过试图说服我的同事而直接去找经理的建议，关于如何在他们开始做正确的事情时该公司如何节省一大笔钱呢？

11 programming-practices  maintenance 

我有大约2年前写的一些软件，并且需要添加一些功能。我已经意识到这是在一个烂摊子，和我有冲动走动的一切，收拾一下，等我读过的软件乔尔约不重新启动的文章，让最新最好的方式前进？

11 refactoring  maintenance 

其中哪一个对可维护性更好？ if (byteArrayVariable != null) if (byteArrayVariable .Length != 0) //Do something with byteArrayVariable 要么 if ((byteArrayVariable != null) && (byteArrayVariable.Length != 0)) //Do something with byteArrayVariable 我更喜欢阅读和编写第二篇文章，但我想起在代码中阅读完整内容是，这样做不利于可维护性。 这是因为if如果第一部分为假，并且并非所有语言都这样做，则您依赖语言来不评估第二部分。（第二部分如果使用null评估，将引发异常byteArrayVariable。） 我不知道这是否真的值得担心，我想就这个问题提供一般反馈。 谢谢。

11 programming-practices  coding-standards  maintenance  readability 

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

10 maintenance  maintainability