Questions tagged «maintenance»

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 有些人有这个问题，他们一言不发。写下他们的想法和决定是最有效的方法。 那么-在编码过程中在一些Notepad ++文件中写下我的想法和决定是否正常并且可以接受？ 有时应该是可以接受的，例如在重新创建技术文档或对更复杂的算法进行推理时，但是有时可能很奇怪，例如当我在考虑设计选项并试图做出判断时。 这种做法对生产率的影响尚不清楚。从一方面来看，使用内在单词的推理可能比使用书面单词的推理更快。另一方面，更复杂的问题需要编写。此外，如果人们坚持使用更多的设计选项，那么在撰写决策时感觉会更好，因此鼓舞士气。

22 design  maintenance  concepts  coding 

我在一家中型公司工作，但IT力量很小。 去年（2011年），我编写了一个受大量最终用户欢迎的应用程序。去年年底，我们赶到了最后期限，但最终并未将某些功能（从现在开始我称为funcA）添加到应用程序中。因此，此应用程序自2011年底以来一直在现场/生产中运行，我可能会添加，没有任何问题。 昨天，一群最终用户开始抱怨应用程序中从未使用过的funcA不再起作用。我们在这家公司的工作重点是，如果某个应用程序被破坏，则必须在确定优先级的项目之前先对其进行修复。 我已经比较了代码和查询，自2011年以来没有区别，这就是proofA。然后，我能够让一位最终用户承认它从未使用过proofB，但是从那以后，那个最终用户又回过头来说它以前已经在工作……我相信最终用户的群体已经吸收了她。我还查看了该项目的注释，该注释包含有关该项目的要求和每日更新，其中特别指出“ proofC由于时间限制而未实现”。 我已经与其中许多人进行了交谈，我看到它们可能会在哪里混淆，因为它们与编程背景相距甚远，但是我也知道它们足够聪明，可以在小组中采取行动，从而绕过项目优先顺序以获取他们想要使他们的工作更轻松的功能。 最糟糕的部分是，即使没有代码或查询的更改，现在团队思考开始起作用，而我的老板和IT主管实际上开始相信他们。就检查逻辑状态而言，它非常干and，直到1 = 1时，funcA将不起作用。 因此，这是对方案的描述的结尾，但是由于此原因，我试图在性能指标上不加赘述，这实际上将使我不得不解决不存在的生产问题，而该问题很可能会接管1个月。

22 project-management  requirements  maintenance 

关于残破的窗口，是否有时最好将重构留给以后的活动？ 例如，如果将一个向现有内部系统添加一些新功能的项目分配给了一个到目前为止尚未与该系统合作的团队，并且给出了一个可与之合作的时间表，那么是否有理由这样做？为了在这种情况下规定截止日期，将主要的重构推迟到现有代码吗？

21 project-management  refactoring  maintenance 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我已经担任维护程序员两年了，想知道是否有维护工程师加薪之类的事情？我问，因为责任并没有扩大，您仍在做几乎相同的事情，也许随着时间的流逝会更快一点。如果有可能，那么获得它的途径是什么？

21 maintenance 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我是猫王，努力学习成为爱因斯坦。我为Mort工作。 这个疯子白痴在说什么！？！？（您只需要阅读前几段） 如果您不想阅读该链接，那么基本上，我是一名专业程序员，而我的老板是（这非常准确）： 缺乏计算机科学学位但对Office和VBA十分熟悉的专业业务线程序员，通常编写在同事之间共享的生产力应用程序 话虽这么说，我的大部分工作是将他拼凑的代码准备好并投入生产。但是，非常差的风格和杂货主义使这变得困难。他不愿意阅读编程书籍或不愿意让我帮助他重构代码，这使情况更加复杂。 还有其他一些策略可以帮助不是专业程序员的人，也永远不会成为专业程序员编写对我而言更易读和易用的代码吗？

20 development-environment  teamwork  maintenance 

据我了解，术语“反向移植”用于描述在将来的版本中应用的修补程序，该版本也移植到了先前的版本中。维基百科的定义如下： 反向移植是对软件进行某些修改（补丁）并将其应用于比其最初创建的版本更早的软件的操作。它构成了软件开发过程中维护步骤的一部分。 例如： 在V2.0中发现并修复了问题。移植了相同的修补程序并将其应用于V1.5。 在相反方向进行操作时，该术语是什么？ 在V1.5中发现并修复了该问题。移植了相同的修补程序并将其应用于V2.0。 术语“反向移植”是否仍然适用？还是有诸如“转发”之类的术语（听起来很像“端口转发”）？

20 terminology  maintenance 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我是一名Java开发人员，拥有超过一年的经验，这使我比初级人员高一些，但是还不是中级开发人员。最近，为我提供了一个长期项目，该项目涉及研究现有银行应用程序代码4个月，然后在需要时进行更改。作为一个经验不足的程序员，我正在寻找开发方法，我不知道这样的项目会给什么。 对于初学者来说，您是否认为处理大型且可能不太好的书面申请是一种好习惯？

18 learning  skills  maintenance  legacy-code 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 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 

我尤其对以下方面感到好奇： 您怎么知道您的测试用例是错误的（或已过期）并且需要修复（或丢弃）？我的意思是，即使一个测试用例变得无效，它仍然可以通过并保持沉默，这可能使您错误地认为您的软件可以正常工作。那么，您如何认识到测试套件中的此类问题呢？ 您怎么知道您的测试套件已不再足够，应该添加新的测试用例？我想这与需求更改有关，但是是否有任何系统的方法来检查测试套件的适当性？

17 testing  maintenance 

使用基于事件的组件时，在维护阶段我经常会感到有些痛苦。 由于执行的代码都是分散的，因此很难确定在运行时将涉及的所有代码部分。 当有人添加一些新的事件处理程序时，这可能导致难以解决的细微问题。 从评论中进行编辑：即使有一些良好的实践做法，例如具有应用程序范围的事件总线和处理程序将业务委派给应用程序其他部分的处理程序，有时代码也开始变得难以阅读，因为其中有很多来自许多不同地方的注册处理程序（尤其是在有巴士的情况下）。 然后，序列图开始查看复杂的情况，花费时间确定正在发生的事情在增加，调试会话变得混乱（在处理程序上迭代时，处理程序管理器上的断点，尤其是异步处理程序和在其之上进行一些过滤时感到高兴）。 ///////////// 示例 我有一个正在检索服务器上某些数据的服务。在客户端上，我们有一个基本组件，该组件使用回调来调用此服务。为了向组件的用户提供扩展点并避免不同组件之间的耦合，我们触发了一些事件：一个事件在发送查询之前发生，一个事件在返回答案时发生，另一个事件在失败时发生。我们有一组预注册的基本处理程序，它们提供了组件的默认行为。 现在，该组件的用户（我们也是该组件的用户）可以添加一些处理程序以对行为进行一些更改（修改查询，日志，数据分析，数据过滤，数据按摩，UI花式动画，链接多个顺序查询） ， 随你）。因此，某些处理程序必须在其他处理程序之前/之后执行，并且它们是从应用程序中许多不同的入口点注册的。 一段时间后，可能会发生十几个或更多处理程序被注册的情况，并且使用该处理程序可能既乏味又危险。 之所以出现这种设计，是因为使用继承开始变得一团糟。事件系统以一种组合形式使用，您尚不知道组合将是什么。 示例结束 ////////////// 所以我想知道其他人如何处理这种代码。无论是在编写和阅读它。 您是否有任何方法或工具可让您轻松编写和维护此类代码？

16 maintenance  event-programming 

我在大型项目上进展不大。源头是巨大的，有许多层物体，通心粉代码，多重继承的双钻石图，原始作者离开时冻结的半生不熟的功能，而且没人知道为什么如此设计很多东西。 我想任何有能力的程序员都会遇到一些麻烦，要想尽一切办法解决错误，完成未完成的工作并添加新功能。但是，我怀疑我会比典型的程序员慢。 我如何判断消息来源是否异常糟糕，我是否做到了任何人都能做到的，而消息来源对于这样的项目来说是典型的，而我只是机智或技能不足？

16 code-quality  maintenance 

我想在很久以前编写的某些仍能正常工作的代码中进行一些增强，然后再以其编写的编程语言具有更多功能。从理论上讲，整个项目都使用该语言的最新版本。但是，该特定模块（实际上还有许多其他模块）仍然使用较旧的方言编写。 我是不是该： 不用接触我不需要接触的代码部分，而是利用新的语言功能编写我的补丁程序，这些新功能使编写补丁程序更加容易，但是在模块中其他任何地方都无法使用？（这是我直观选择的解决方案。） 忽略岁月流逝的事实，并在编写补丁时反映出代码其余部分中使用的样式，就像我早在多年前一样正在做同样的事情一样吗？（我直觉上认为这种解决方案很愚蠢，但是鉴于每个人都在谈论“好的代码”而大惊小怪，因此不惜一切代价保持一致性，也许这就是我应该做的。） 更新整个模块以使用较新的语言构造和约定？（这可能是最好的解决方案，但可能需要大量时间和精力，而最好将其花费在其他任务上。）

15 programming-practices  maintenance 

在我们的团队中，除了个别的工作单元（故事），我们还有工作时间更长的主题（史诗）。多个故事成为史诗。 传统上，我们为每个故事提供功能分支，并在它们通过质量检查后直接合并为母版。但是，我们希望开始阻止在Epic中发布已完成的故事，直到Epic被视为“功能已完成”为止。我们只会在整个Epic关闭时才将这些功能发布到生产环境中。此外，我们有一个每晚生成的服务器-我们希望所有封闭的Stories（包括那些不完整的Epics的故事）都将自动部署到该每晚的服务器。 关于如何管理我们的仓库来实现这一目标，有什么建议吗？我考虑过引入“史诗般的分支”，在这里我们将封闭的故事合并到相关的史诗分支中，而不是直接掌握。但我担心的是： 我担心如果史诗分支长时间保持开放可能会发生合并冲突 每晚构建需要将所有史诗分支合并为一个“每晚构建”分支。同样，可能会发生合并冲突，这将自动完成

15 version-control  git  maintenance  branching 

我最近遇到了这个编程习惯用法： const float Zero = 0.0; 然后用于比较： if (x > Zero) {..} 任何人都可以解释一下，这实际上是否比以下方法更有效，可读性或可维护性： if (x > 0.0) {..} 注意：我可以想到定义此常量的其他原因，我只是想知道它在此上下文中的使用。

15 coding-style  maintenance  readability  const 

难题：在使用新功能或修复缺陷的过程中，您会在代码中发现遗留问题。你该怎么办？对其进行修复，并有可能改变代码的行为。直到现在为止，由于某种偶然原因，它一直在工作，或者还没有发现缺陷，或者值得任何人报告。您是否应该不理会它，并允许该问题使以后的代码难以使用？解决问题只会增加原始任务的时间，并迫使您进行回归测试。很少有人会欣赏这项工作。但是，以某种方式修复它似乎正确。问题较少的代码更易于重构和构建。 当我们致力于使Web应用程序现代化时，我一次又一次地发现自己处于这种情况。当我不切实际地处理这些旧错误时，我无法分辨自己是痴迷还是光荣。您如何处理这些情况？ 谢谢，科里

15 code-quality  bad-code  refactoring  maintenance