我们可以详细说明“实践”一词，尽管我真正渴望写的是每个开发人员都应该知道的最低限度的工具，服务和实践，并且每个新经理或软件公司所有者/经理应安装和维护这样他/她就可以帮助他的团队。
最终，它是我们必须保存和共享代码的中心位置。 它管理整个团队中的版本控制和分发等方面。 令人惊奇的是，即使在今天，您仍然可以看到开发人员使用共享文件夹，电子邮件或每个项目设置自己的代码存储库来共享代码（浪费资源）。 这些做法我们应不惜一切代价予以劝阻。 选择代码版本控制系统存在一些基本问题。
（类型）其中哪一个？ 确实，我们有很多VSS，CVS，SVN， Git ， Mercurial等。总的来说，近年来SVN和Git趋向于趋势化。 最终，您将根据现有的专业知识和要求来选择一个。 如果您完全缺乏以前的经验，请选择一种趋势（SVN或Git）。 如果您有自己的个人喜好，并且知道什么是好的和坏的，您可以自由选择并支持它。 目前，SVN将是一个不错且安全的选择（IMHO）。
（$$）这些服务/服务器中的大多数都是开源的和免费的，因此您不必花费任何额外的钱来下载和安装它们（SVN，CVS，GIt）。
（备份）在安装并使用服务后，我们应该意识到我们需要设置备份策略和过程，通常将此任务分配给任何管理员。 因此，需要适当的备份和维护！
（人们）无论我们是否要在公司中购买或安装最好的代码存储库/版本系统，如果大多数人不遵循，那将是另一种资源浪费。 将工具带入公司环境是第一步，第二步是使人们开始使用它–在这里，您将获得所有收益！
（远程访问）中央代码存储库使您能够启用远程工作（如果需要或愿意的话）。 人们可以在家中或在客户所在地下载部分工作代码，并花一些时间-不受本地公司资源的限制。
问题与错误追踪器
问题跟踪器是一种软件服务（通常是Web应用程序），可以帮助我们创建，监视，管理和过滤在软件解决方案的开发，操作或维护过程中发现的不同问题和总线。 任何软件产品或服务都可以被视为有生命的有机体，从其创建的最初阶段就需要特别注意，以产生错误或问题。 即使当您在产品中发布它时设法使它起作用，我们也总是发现新问题，新问题或新想法。
为了管理发现，修复，确定优先级和过滤所有这些问题的长期过程，我们通常退回使用问题和错误跟踪器，所有相关方都可以使用它。 在这样的系统中，我们让开发人员，管理人员甚至最终客户都参与其中，以支持最终产品的问题和问题生命周期。
开发人员拥有一个工具，可以将问题与工作任务相关联，保留其修复工作的历史记录，并可能在出现问题时进行反应修复。 管理人员可以随时了解解决方案的成熟度，从而监控系统的“运行状况”。 这样，他们就可以有效地计划，提供更好的估算并为将来的版本和变更请求提供有效的成本估算。 最后但并非最不重要的一点是，最终客户能够监视工作进度，及早参与产品，并能够登录并提交他/她认为需要立即关注的优先事项列表。
我需要指出的是，问题跟踪器通常可以用作记录工作时间的有效方法，通常公司可以通过与其他系统（例如SAP或siebel等）的接口使用该功能。记录时间并创建每周月度报告，您将获得有关您的团队/部门（免费）。
没有任何系统具有零个错误，尤其是在它的最初生命中，并且如果没有问题和错误跟踪程序的帮助，我们就无法记录，存档，搜索和保留此演变的历史记录（通过修复，问题或更改请求）。
选择问题跟踪器有一些基本问题：
（类型）其中哪一个？ 我们仍然有多种解决方案。 在系统运行方面，它们的功能或多或少是相同的。 每个产品在某些方面都提供了更多区别（例如，更好的报告，更好的ui，价格，兼容性以及与其他系统的集成），从而与众不同。 我个人最喜欢的，也是我在大多数公司中看到的一个，是Atlassian的JIRA。 我个人认为这是一站式服务，是一种出色的产品。 我还要看一下IDEA的YouTrack，它以较低的价格提供了出色的功能。 Trac或bugzilla是有趣的免费开源替代品。
（$$）在此类别中情况有些复杂。 优秀的专有产品和免费开源列表。 我猜这真的是金钱问题。 但是，我强烈建议您投资一些好的东西，而不是仅仅因为它不可用或不方便而使用它。
（备份）在安装并使用服务后，我们应该意识到我们需要设置备份策略和过程，通常将此任务分配给任何管理员。 因此，需要适当的备份和维护！
（人们）如前所述-使用问题跟踪服务需要更改以前从未见过的团队的工作思路。 我认为，这是改变，很快就能收回回报，而且该公司通过自动化过去手动执行的程序和任务，正在Swift减少工作日志上的工时。
（远程访问）远程访问是一项重要资产，任何人（您想要）都可以控制和访问此服务的不同部分（每个项目，每个公司，每个客户），并且可以远程处理有关最终产品的重要工作。
企业–中央Wiki
创建软件意味着交换与最终产品或所用技术有关的信息。 即使在今天，软件部门内部甚至软件开发团队内部的信息流仍然是一个大问题。 任何级别的问题信息流都可能导致任何团队和产品的不一致，问题或质量低劣的工作。 我们需要确保我们拥有可用的工具和实践，这些工具和实践将使软件开发过程中的所有参与方能够轻松，灵活地共享信息，记录发现并共同共享内容。 我们生活在博客，推特和网络服务的时代。 大量内容正在通过Web应用程序记录，保存和存档。 Google正在为搜索网页和相关资源建立索引。 因此，既然我们每天都在做，那么为什么不在公司内部遵循相同的模式呢？
根据我个人的经验，可以使用中央Wiki服务使人们可以轻松地记录和共享与特定项目相关的知识，或者与我们以前编写多页和数兆字节的Word文档相比，更容易获得一般知识。 您的收件箱中有多少人收到了标题为“ System Specification version1”的巨大Word文件，其中包含更改曲目的功能以及成千上万条注释，并且结构不断变化。 Word / Office文档通常是针对文档的打印结果的格式，不鼓励查看或使用其自身的电子格式。 我不是反对文字文档，而是反对书面信息，与其他人共享信息以及必须共享相同资源的同一实例，合并更改或跟踪它们，而我只是共享一个虚拟页面/位置Wiki（例如博客）并立即开始撰写和共享。
我强烈鼓励大家开始尝试将技术分析或业务分析文档转换为此类服务，方法是将其转换为Wiki页面和Web资源。 您会惊讶于所有相关方（分析师–开发人员–经理–客户）与旧办公室共享方式相比，查找，有效阅读甚至评论添加信息的便捷性！ 这确实是一次变化，我始终记得向不同的管理团队提出这样的建议，同时又回想起一些奇怪的事情–您提出的是我们的“舒适区”提议。 但是要说的实话–开始在Wiki中捕获信息，停止滥用word或开放办公室–仅在最后阶段生成word文档或pdf。
（类型）（$$）其中哪一个？ 主要是大多数人都做同样的事情。 很多选择。 诸如Confluence之类的专有解决方案有很多趋势，但是您可以使用MediaWiki等免费解决方案轻松满足您的需求。
（备份）与上面相同！
（人们）如前所述（再次），您需要说服人们理解组织内信息流的重要性。 很多人习惯了旧的方式，到处都是excel和word文档。 最终，我们为这种不舒服的工作方式找到了解决方案。
（远程访问）像博客或任何Web资源一样，可以轻松地将Wiki共享（或根据需要将其限制）给各种人或团体。
请记住，在某些情况下，这些服务的组合提供了本博客文章未涵盖的功能和自动化级别。 例如，问题跟踪系统可以将问题/错误与版本控制系统自动检索的部分代码自动关联。 或者，您可以使用指向您Wiki的问题的链接来扩展设计/解决方案或问题的解释！
构建服务器（持续集成）
Martin Fowler对持续集成的定义给出了最简单，最准确的描述之一：
“持续集成是一种软件开发实践，团队成员经常集成他们的工作，通常每个人至少每天集成一次-导致每天多次集成。 每个集成都通过自动构建（包括测试）进行验证，以尽快检测到集成错误”
就那么简单。 构建器和集成服务器是一项软件服务（通常是应用服务器上托管的Web应用程序），将提供以下功能：自动和定期构建存储在存储库中的代码，运行测试或其他质量插件，并每天生成有关以下内容的报告：代码的“健康”。 团队成员将能够监视并获得有关集成生命周期各方面错误的特殊情况的通知，例如，构建错误，特定更新后测试失败的次数，分析代码后的质量指标。 维基百科上有一篇相当不错的文章 。
选择连续集成/构建服务器存在一些基本问题。
（Type-$$）其中哪一个？ 我们很幸运（再次）指出，商业和开源都有各种潜在的解决方案。 当涉及到开源时，您将看到Hudson / Jenkins / CruiseControl / Continuum等服务 。 我曾与大多数公司在不同的公司工作过，我会说，他们所有人都承诺提供基本功能。 为了做出选择，您将需要检查技术的不同功能/发布和更新周期/与其他系统的集成。 当涉及到商业软件包有一个又大集他们提供解决方案-一些会的TeamCity / 竹等，你会发现很多周围的净上市例如这个可能的解决方案博客文章的一个 。
（备份）如前所述。 安装服务并使用它之后，我们应该意识到我们需要设置备份策略和过程，通常将此任务分配给我们的任何管理员。
（人员）集成服务器是为团队工作的组件，您要确保的主要事情是确保它正常工作，并且软件开发生命周期中的人员都应注意其工作结果（通知，报告和监视工具） 。 将持续集成集成到您的软件开发过程中，您就朝着主动确保软件质量迈出了一步。 管理层应该仔细评估。
测试（工具和实践）
测试是软件开发过程中最重要的活动之一。 最终，很多人（甚至今天）都认为这是浪费资源和时间。 为了减轻这些痛苦，改变我们对这项重要（质量明智）活动的态度，我们可以做一些事情。
实践–测试应得到项目管理层和高层的支持。 当涉及到“实际执行”时，测试并不是从技术层面开始的。 当测试阶段被缓慢地正确地集成到项目计划中时，就开始了测试阶段，这取决于软件开发过程的态度，并得到了经理和PM的信任。 在任何软件开发团队中，没有“魔术按钮”（我们现在称之为测试）。 在我的职业生涯中，我已经看到了以下错误。
- 项目和任务估计不包括（适当地）进行单元测试（主要由开发人员完成）或功能测试（由测试团队完成，如果有的话）进行适当测试的时间 。 通过不分配时间，开发人员被迫在同一时隙中完成其任务的实施和测试，从而跳过了不太紧急的子任务（测试）。 您不能轻易说服软件项目的项目经理或预算经理将测试视为一项活动。 结果在第一个版本发布或服务/产品投入生产后就很明显，从而导致从有问题的解决方案的极端编程立即转换为极端测试（这再次完全错误–参见魔术按钮效果）。
- 开发人员会变得懒惰：最终我们不能一直责怪管理人员。 软件开发人员有时会懒惰，因为他们认为测试同样出色–在他们的任务清单上是二等公民。 最终，这种态度应由高级管理层和每个部门遵循的整体软件开发实践来强制执行。 例如，当您通过在连续集成服务器上执行测试来引入自动化测试时，并且监视开发人员确实执行过测试的代码区域时，您可能会对不注意的人采取正确的态度。 有时，软件及其设计的复杂性就像是开发人员抱怨的另一个原因（我无法测试），这是高级开发人员和架构师应注意并尽快修改代码的潜在部分的原因–模块化并使用适当的技术，以在开发人员级别帮助/自动化/鼓励测试实践。
工具–可以应用几种工具和实践来实施和简化测试工作。 我将提供到目前为止我在与Java相关的职业中所见过的事情的简短列表。您可能会在这里找到许多其他链接，以了解其他编程语言或框架。
开发人员框架和工具
Web测试/功能测试自动化
代码覆盖率–到目前为止，我们已经讨论了将测试集成到项目管理和日常编码中的基本步骤。 我们如何才能判断自己是否走在正确的轨道上？ 我们要测试多少？ 潜在客户所施加的质量限制又如何呢（例如：我们要求80％的业务代码必须包含在测试或类似请求中）。 这是实践中覆盖代码的地方。它是监视并有效地微调我们的测试活动的工具。 有某些工具和框架可以分析我们的源树并测试源树，并提供有关要测试的实际业务量的指标。
在Java世界中，您可能会看到以下工具：
继续阅读第二部分 。
参考： 在任何软件开发机构/部门中都应存在的服务，实践和工具-我们的JCG合作伙伴 Paris Apostolopoulos的第1 部分和第2部分在Papo的日志中 。
翻译自: https://www.javacodegeeks.com/2011/10/services-practices-tools-that-should.html
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
