Questions tagged «maintenance»

我希望这不是一个普遍的问题。我真的可以使用一些经验丰富的建议。 我刚刚在一家规模很小的科学家商店中担任唯一的“软件工程师”，他们在过去的10到20年中花了很多时间编写了庞大的代码库。（它是用一种几乎过时的语言编写的：G2-用图形来思考Pascal）。该程序本身是复杂的化学加工厂的物理模型。编写该程序的团队具有难以置信的深厚知识，但是很少或没有正式的编程基础培训。他们最近学到了一些关于不存在的配置管理的后果的艰难教训。代码本身中大量未记录的“污泥”的积累也极大地阻碍了他们的维护工作。我会避免给您这种情况的“政治”（总是 政治！），但足以说，就未来的道路需要什么没有达成共识。 他们要求我开始向团队介绍现代软件开发的一些原理。他们希望我介绍一些有关编码约定，生命周期管理，高级设计模式和源代码控制的行业标准实践和策略。坦白地说，这是一项艰巨的任务，我不确定从哪里开始。 最初，我倾向于在The Pragmatic Programmer或Fowler's Refactoring（“代码气味”等）的一些中心概念中对它们进行辅导。我也希望介绍一些敏捷方法。但最终，要想发挥作用，我认为我需要磨练5-7个核心基础知识。换句话说，他们可以实际开始实施的最重要的原则或实践是什么，这将使他们获得最大的“收益”。 因此，这就是我的问题：您将在最有效的策略列表中包括哪些内容，以帮助理顺意大利面（并在以后防止出现这种情况）？

470 project-management  agile  development-process  maintenance  sdlc 

我刚刚开始我的职业生涯，当时是一家中型公司的Web开发人员。一开始，我就完成了扩展现有应用程序的任务（多年来，由多个程序员开发的编码不佳的代码以不同的方式（零结构）处理相同的任务）。 因此，在我成功地使用所需功能扩展了该应用程序之后，他们给了我任务，以完全维护该应用程序。这当然不是问题，或者我想。但是后来我得知我被禁止改进现有代码，并且只在报告错误时才专注于错误修复。 从那时起，我像上面一样，又有三个项目，现在也要维护。我有四个项目，可以从头开始创建应用程序，我也必须维护它们。 目前，对于要维护的每个应用程序，用户（阅读管理员）的日常邮件使我略为发疯。他们希望我直接处理这些邮件，同时还要处理其他两个新项目（在那之后已经有五个项目在排队）。可悲的是，我尚未收到关于自己编写的任何内容的错误报告。为此，我只是偶尔收到了让我们做180度不同的变更请求。 反正这正常吗？我认为我所做的工作相当于整个开发人员团队。 当我最初希望情况有所不同时，我是白痴吗？ 我想这篇文章已经变成了大声疾呼，但是请告诉我，对于每个开发人员来说，情况都不一样。 PS我的薪水几乎相等，甚至不低于超市的收银员的薪水。

368 maintenance 

您使用什么工具和技术来探索和学习未知的代码库？ 我在考虑诸如grep，，ctags单元测试，功能测试，类图生成器，调用图，代码度量之类的工具sloccount，等等。我会对您的经验，您使用或编写的助手以及您使用的代码库的大小感兴趣。 我意识到熟悉代码库是一个随时间推移而发生的过程，熟悉度可以表示从“我能够总结代码”到“我可以将其重构并缩小到其大小的30％”之类的任何内容。但是，如何开始呢？

145 source-code  maintenance 

我是一个很好的程序员，或者我以前就这么想过。我一直喜欢编程。我想学习很多有关编程的知识，以使我成为一名更好的程序员。我学习了1年的编程知识，现在我从事程序员工作将近2年。简而言之，我有将近3年的编程经验。 我们的团队由5位程序员组成，其中我们4位是新手，其中1位具有3年以上的经验。我们已经为一个程序工作了将近一年，没有人审查过我的代码，并且给了我一个可以使用的页面。我们从未进行过代码审查，而且我们都是新手，所以我们不知道干净的代码是什么样。我认为程序员可以自己学习？ 我们在没有进行全面测试的情况下将程序部署到了程序中。现在已经很严格了，在对代码进行更改之前，我们需要首先获得批准和代码审查。有人第一次审查我的代码，他说这是一团糟。 我感到很难过和受伤。我真的很喜欢编程，让他们说这样的话真的很伤害我。我真的很想提高自己。但似乎我不是电影中的天才程序员。您能给我建议如何做得更好吗？您是否曾经遇到过批评您的代码的事情并且感到非常受伤？你在那些事件上做什么？

86 teamwork  code-reviews  maintenance 

我是一个拥有大量非技术用户群的项目的维护者。我已经将其维护了大约4年，并根据需要添加了新功能。 我现在想继续进行其他项目，并停止为此应用程序开发。由于用户的非技术性，过去几乎没有代码贡献。我不相信我会找到其他人来接手该项目。 错误，问题和功能请求-这些仍然存在。我仍在回复电子邮件以寻求帮助，因为我不确定是否应该忽略它们，告诉他们我不在使用该应用程序，还是应该响应仅在某些情况下才能发送电子邮件。 什么是“放弃”该项目但仍让用户使用该应用程序的最佳方法？ 更新（2016年7月）-它没有按计划进行。我在自述文件中发布了一个公告，不久之后，我开始收到更实质性的文稿。通过错误修复，功能，文档和问题活动拉取请求。从那时起，该项目感到“焕然一新”，我现在很高兴与新项目一起维护它。我也有合作者。猜测可能是那种影响我对项目的看法的贡献，并且随着贡献质量的提高，它再也感觉不到杂事了。

75 open-source  project  maintenance 

我的印象是，版本控制系统消除了将“更改日志”粘贴到代码各处的需要。我经常看到更改日志的继续使用，包括存储过程开始时的长块大块，其中很大一部分被挡住以更改文件，并用诸如此类的代码乱码： // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 和： // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> 正如我向我解释的，这样做的原因是，花很长时间浏览我们的VCS日志，试图找出谁更改了内容和原因，同时将其保存在代码文件本身的顶部或附近。更改，可以轻松查看谁更改了内容和时间。尽管我明白了这一点，但似乎有些多余，只是有些“语：“嗯，我们不太了解如何正确使用VCS，因此我们根本不会理会这些东西。” 你怎么看？您是否同时使用注释和日志？只是日志？您是否发现，在代码块上方看到约翰·史密斯一周前更改了检查XYZ的方法，而不必在Diff工具中搜索日志并比较代码文件时，是否更容易编写代码？ 编辑：使用SVN，但基本上只是作为存储库。没有分支，没有合并，除了日志和存储之外什么也没有。

75 version-control  coding-standards  maintenance 

假设其中一个程序比较大（例如，在C＃中为900k SLOC），所有程序都已进行了注释/记录，内容井井有条，运作良好。整个代码库由一个不再在公司工作的高级开发人员编写。所有代码都可以按原样进行测试，并且在整个过程中都使用IoC －出于某些奇怪的原因，他们没有编写任何单元测试。现在，您的公司希望分支代码，并希望添加单元测试以检测更改何时破坏了核心功能。 添加测试是一个好主意吗？ 如果是这样，一个人怎么会开始这样的事情？ 编辑 好的，所以我没想到答案会得出相反的结论。无论如何，这个问题可能不在我的掌控之中。我也阅读了“重复的问题”，并且普遍的共识是“编写测试很好” ...是的，但是在这种特殊情况下不太有用。 在考虑为遗留系统编写测试时，我并不孤单。我将保留有关花费多少时间以及新测试发现问题的次数（以及没有发现问题的次数）的指标。我会回来，并从现在开始大约一年后用我的结果进行更新。 结论 因此，事实证明，基本上不可能将任何形式的正统测试都添加到现有代码中。代码正常工作后，您显然无法对测试进行红灯/绿灯测试，通常通常不清楚哪些行为对测试很重要，也不清楚不清楚从何处开始，当然也不清楚何时完成。真的，甚至问这个问题都错过了编写测试的重点。在大多数情况下，我发现使用TDD重写代码实际上比解密预期的功能和追溯添加单元测试要容易得多。解决问题或添加新功能时，情况有所不同，我认为现在是添加单元测试的时候了（如下所述）。最终，大多数代码都会被重写，通常比您预期的要早-我采用这种方法

68 unit-testing  tdd  maintenance 

我从事软件开发工作已有10多年了，但我却很少能创建任何“新”东西，这使我感到惊奇。我意识到“新”是一个模糊的术语，但是我将其定义为从明显的新大型项目到现有项目中的新大型功能的任何内容（例如，需要对其设计进行一些思考，并且可能需要2周或更长时间才能完成）。如果需要书面说明，粗略的指导也许是新的东西。我认为大多数程序员都知道我在说什么-您正在开发中，正在快速编写大量代码。 无论如何，回想我所做的事情，我估计我只有不到10％的时间花在“新”工作上。诸如“使现有系统适应在新环境中工作”之类的事情当然需要进行大量规划，但是实际的编码和“新事物”归结为在整个代码中的许多地方进行了微小的更改。同样，对于小型功能请求-如果我知道该怎么做，通常可以在一个小时内完成，如果我不知道，那么很多阅读代码并弄清楚该做什么（这使我感到沮丧，因为我学习了做的更好，而不是阅读）。 总的来说，我觉得我大部分时间都没有创造任何东西。我以为大多数地方都是这种情况-新产品会很快推出，到那时每个人都会很兴奋，并以快速的速度发布代码，但是一旦上线，它就会进入维护模式，随后的更改很少被认为是“新的和创造性的”。 我错了吗？我是准确地描述了大多数编程工作，还是大多数程序员都觉得自己经常在创造新事物？

63 programming-practices  maintenance 

我没有在软件行业工作的经验，没有自学成才的经验，并且在决定工作之前参加过开源。现在，我为钱而工作，我还必须处理一些不愉快的事情，这当然是正常的。 最近，我被分配将日志记录添加到一个大型SharePoint项目中，该项目是由一些显然正在学习编写工作代码的程序员编写的。经过2年的合作，客户转到了我们公司，但是造成了损害，现在我需要以某种方式维护此代码。 并不是说代码太难读。尽管存在问题-每个项目都有一个类，其中包含几种复制粘贴的方法，大量的if嵌套，匈牙利语的系统，未处理的连接-但它仍然可读。 但是，尽管进行诸如添加日志记录之类的简单操作，但我发现自己绝对没有生产力。基本上，我只需要逐步完成代码并添加一些跟踪调用。但是，代码的愚蠢到令人讨厌，以至于在开始的10分钟之内我就感到疲倦。最初，我曾经添加using结构，通过反转来减少嵌套if，将变量重命名为可读的名称，但是该项目很大，最终我放弃了。我知道这不是我应该做的任务，但是至少减少混乱使我获得了某种心理上的回报，所以我可以继续前进。现在，这个技巧停止了工作，我还有60％的工作要做。 我下班后开始头痛，而且不再有以前的满足感，通常这使我可以连续10个小时编写代码，但仍然感到新鲜。 这不仅是一个大麻烦，因为我确实有一个实际的问题： 有没有办法保持生产力而不与风车战斗？ 是否有某种心理把戏保持专注的任务，而不是想着“如何愚蠢的是那个？”每次我在以前的程序员看到另外一个巧招时间？添加日志记录的问题在于，我实际上必须了解代码的作用，而这样做却以令人不快的方式伤害了我的大脑。

63 code-quality  productivity  maintenance 

我几乎没有一年的编码经验。开始工作后，大多数时候我都会处理别人的代码，或者在现有功能上添加新功能，或者修改现有功能。编写实际代码的人在我公司不再工作。我很难理解他的代码并完成任务。每当我尝试修改代码时，我都会以某种方式弄乱正常工作的功能。在处理别人的代码时，我应该牢记什么？

60 architecture  coding-style  coding-standards  coding  maintenance 

在大型公司中，我管理着一个小型应用程序开发团队团队，该应用程序处于生命周期的中点。不幸的是，这意味着通常有30/70的编程任务分配给“其他技术工作”。这项工作包括： 与DBA / Unix /网络/负载平衡器团队一起完成各种任务 在不同地区下达和管理硬件或基础架构的订单 运行尚未迁移到CI的运行测试 分析 支持/调查 可以公平地说，开发人员都愿意编写代码，而不是执行这些平凡的任务，因此，我尝试在团队中平均分配有趣的编程工作。 聘用大多数团队是因为，尽管他们可能不具备编写自己的编译器/游戏引擎/高频交易系统等的精通编程技能，但他们是能够“完成工作”并与其他团队合作的优秀交流者，并在这里浏览复杂的官僚机构。他们是优秀的开发人员，但也是优秀的全方位技术人员。 但是，团队中的一名成员可能具有高于平均水平的编码技能，但低于平均水平的沟通技能。传统上，以前的开发经理倾向于给他编程任务，而不是上面列出的更普通的任务。但是，我认为这对团队中的其他成员并不公平，他们显示出开发大型企业IT部门通常需要的全面技能的能力。 在这种情况下我该怎么办？如果我继续给他更多的编程工作，我知道它会更快地完成（相反，我希望他完成其他工作的速度会更慢）。但这违背了我的原则，并提出了这样一个想法，即您只需对不喜欢的任务表现不好就可以为自己创造一个“舒适的利基市场”。 我想澄清的是，由于怀恨在心，我不是要解决这个问题，或者如上所述，我的肩膀上有一个“碎片”。我正在寻找有关如何保持一支充满快乐和动力的全面团队的建议。通过观察该问题的各种答案，似乎对于实现此问题有很多不同的意见。

52 teamwork  management  communication  maintenance  team-leader 

在过去三年中，我的大部分工作主要围绕维护旧系统，这些旧系统需要修补或偶尔进行改造，然后再出售。 我了解专门的维护程序员在拥有大量项目且开发人员有限的公司中必须发挥的关键作用。 但是，当我判断自己目前的职业发展并与同龄人看时；承包商和企业开发商都一样；我确实感觉自己已经远远落后了，因为我在接触的领域上获得了很大的广度，但是深度并不多。我已经开始建立博客来解决这个问题，从事我自己的git-hub小项目，并重新安排我的生活，让他们有时间定期下班后进行个人编码。 我觉得如果我要去其他公司面试以逃避维护工作，我将不得不把自己表述为熟练的技能水平，因为我不会拥有具有三年工作经验的人需要的知识深度功能开发的路径。因此，从长远来看，我目前的工作经验的一半将变得毫无价值。 但这引出了我的主要问题，如果感觉太围绕我的个人困境，我深表歉意： 专门的维护编程角色最终会损害早期的职业生涯吗？其他程序员是否应该避免此类角色？除非您准备从高中开始，否则从事这方面的工作是否会使您锁定执行类似的任务？

52 maintenance  skills  legacy 

当选择我们想要学习的东西，以及我们的职业和生活时，我们都对它会是什么样子抱有一些期望。现在我从事该行业已经有近十年了，我一直在反思自己的想法（当时我在学习计算机科学时），编程的工作生活将是什么样子，以及它实际上如何变成是。 到目前为止，我的两个最大的震惊（或者应该说是打破期望）是软件涉及的大量维护工作以及总体上缺乏专业精神： 维护：在uni，我们都被告知大多数软件工作是对现有系统的维护。因此，我知道可以抽象地期望这一点。但是我从未想过这到底会是多么令人难以置信。也许这是我精神上的困惑，并希望我能从头开始构建更多新颖的东西。但是，实际上大多数工作都是以维护，错误修复和支持为导向的。 缺乏专业素养：在uni，我始终给人以商业软件工作非常注重流程和严格设计的印象。我有ISO流程的图像，大量技术文档，严格记录了每个功能和错误以及普遍专业的环境。震惊的是，意识到大多数软件公司的运作方式与一个为期一个学期的大型项目的学生团队没有什么不同。我曾经在小型敏捷黑客商店和中型企业中工作过。虽然我不会说它一直都是完全“不专业”的，但绝对可以感觉到软件行业（总体上）与我期望的强大工程学相去甚远。 其他人有类似的经历吗？您对我们职业的期望与现实有何不同？

50 maintenance  development-methodologies 

我必须扩展项目的现有模块。我不喜欢它的完成方式（涉及很多反模式，例如复制/粘贴的代码）。由于多种原因，我不想执行完整的重构。 我是不是该： 使用现有约定创建新方法，即使我觉得错了，也可以避免对下一个维护者造成混淆并与代码库保持一致？ 要么 尝试使用我感觉更好的方法，即使它在代码中引入了另一种模式？ 精确度在第一个答案后进行了编辑： 现有的代码不是一团糟。很容易理解和理解。但是，它引入了许多可以通过良好设计避免的样板代码（结果代码可能会变得更难遵循）。在我当前的情况下，这是一个很好的旧JDBC（内置弹簧模板）DAO模块，但是我已经遇到了这个难题，我正在寻求其他开发人员的反馈。 我不想重构，因为我没有时间。而且即使有时间，也很难证明一个完整的正常工作的模块需要重构。重构成本将超过其收益。请记住：代码并不凌乱或过于复杂。我不能在那里提取一些方法并在这里介绍一个抽象类。这在设计中更是一个缺陷（我认为极端“保持愚蠢简单”的结果） 因此，也可以这样问这个问题： 作为开发人员，您是喜欢维护简单的愚蠢无聊的代码，还是希望有一些帮助程序来代替您的愚蠢无聊的代码？ 最后一种可能性的缺点是，您必须学习一些知识，也许您还必须维护简单的愚蠢无聊代码，直到完成完整的重构为止）

45 refactoring  coding  maintenance  anti-patterns 

我正在管理一个小的开发人员团队。我们经常决定要花一两天的时间来清理代码。 安排定期的时间（例如每2个月1周）来清理我们的代码库是个好主意吗？

42 project-management  programming-practices  refactoring  maintenance