分类目录归档：代码

Claude Code 开发者首曝源自内部的13条实操配置

Published 2026年1月5日 / by 高成 / Leave a Comment
Leave a reply

如果你觉得 Claude Code 仅仅是一个更聪明的终端聊天机器人，那你可能只发挥了它不到 10% 的潜力。
作为一个开发者，我们都在寻找那个能让效率产生质变的“奇点”。最近，Claude Code 的核心开发者 Boris 罕见地公开了他个人的实战配置清单——这不仅仅是一份设置指南，更是一套经过高强度工程验证的“人机协作方法论”。从并行 5 个进程的极限多任务处理，到 CLAUDE.md 的团队记忆构建，再到让 AI 能够“自我纠错”的闭环验证机制，Boris 用实际行动证明：决定 AI 编程上限的，不是模型本身，而是你构建工作流的方式。
无论你是正在在此工具上摸索的工程师，还是试图引入 AI 提效的技术管理者，这份去除了繁文缛节的13 条核心实战心法，都将帮你跳过摸索期，直接复刻大神级的开发环境。准备好重塑你的 Coding 习惯了吗？让我们开始吧。

1. 终端多任务并行配置
操作： 在终端中并行运行 5 个 Claude 进程。
技巧： 使用 1-5 编号区分标签页，并配置系统通知（System Notifications），以便在后台进程需要输入时及时获得提醒。

https://code.claude.com/docs/en/terminal-config#iterm-2-system-notifications

2. 端云协同工作流
操作： 本地终端与 Web 端 (claude.ai/code) 并行，运行 5-10 个实例。
技巧：
后台挂起： 在终端编码时，使用 & 参数将本地会话切换到 Web 后台运行。
上下文迁移： 使用 –teleport 参数在本地终端和 Web 环境之间无缝传输会话上下文。
移动端监控： 通过 Claude iOS 应用查看长耗时任务的运行状态。

3. 核心模型选择
配置： 使用 Claude 3.5 Opus 模型并开启 Thinking (思考模式)。
理由： 虽然 Opus 速度较慢，但其需要的干预更少且工具使用更精准，对于复杂编码任务，整体效率优于小模型。

4. 团队共享记忆 (CLAUDE.md)
配置： 在 Git 根目录维护 CLAUDE.md 文件。
用法： 记录项目规范和错误教训。一旦发现 Claude 犯错，将正确做法写入此文件，避免全团队重复踩坑。确保定期更新并提交到仓库。

5. 自动化知识更新
配置： 集成 GitHub Actions (/install-github-action)。
用法： 在代码审查（PR）过程中，通过在评论中标记 @.claude，自动将审查意见提取并更新到 CLAUDE.md 中，实现工程经验的自动累积。

6. 计划与执行模式切换
流程：
计划模式： 起手双击 Shift+Tab 进入。与 Claude 反复沟通直到确认方案（特别是针对 Pull Request）。
执行模式： 确认计划后，切换到自动接受修改模式，让 Claude 一次性完成编码。

7. 高频操作自动化 (Slash Commands)
配置： 将日常重复的“内部循环”工作流定义为斜杠命令，存放在 .claude/commands/ 目录下并提交 Git。
案例： 使用 /commit-push-pr（内联 Bash 脚本）预计算 Git 状态并执行提交推送，减少与模型（https://code.claude.com/docs/en/slash-commands#bash-command-execution）的来回对话交互。

8. 子代理 (Sub-agents) 协同
用法： 针对特定任务使用专门的子代理。
案例：
code-simplifier：在编码完成后清理和简化代码。
verify-app：提供详细的端到端测试指南。

    https://code.claude.com/docs/en/sub-agents

    9. 代码格式化钩子
    配置： 使用 PostToolUse 钩子。
    作用： 自动处理 Claude 生成代码的格式化（最后 10% 的工作），确保代码符合规范，避免 CI 流程因格式问题报错。

    10. 权限安全管理
    策略： 不使用 –dangerously-skip-permissions（跳过所有权限检查）。
    推荐： 使用 /permissions 命令预先批准环境中安全的常用 Bash 命令。将配置保存至 .claude/settings.json 并与团队共享，既安全又减少干扰。

    11. 外部工具集成 (MCP)
    配置： 通过 .mcp.json 配置 Model Context Protocol (MCP) 服务器。
    用法： 赋予 Claude 使用外部工具的能力，例如搜索信息推送到 Slack、运行 BigQuery 查询数据分析、或抓取 Sentry 错误日志。

    12. 长耗时任务处理
    策略：
    (a) 提示 Claude 在任务后通过后台代理自我验证。
    (b) 使用代理的停止钩子（Stop Hooks）进行确定性验证。
    (c) 使用 ralph-wiggum 插件保持活跃。
    沙盒模式： 在隔离环境中使用 –permission-mode=dontAsk，允许 Claude 无需确认即可连续运行。

      https://github.com/anthropics/claude-plugins-official/tree/main/plugins/ralph-wiggum

      https://code.claude.com/docs/en/hooks-guide

      13. 核心原则：闭环验证
      关键： 必须给 Claude 提供验证其工作结果的方法（反馈机制）。
      效果： 拥有验证机制可将最终代码质量提升 2-3 倍。
      手段： 使用 Claude Chrome 扩展测试 UI、运行 Bash 命令、执行测试套件或在模拟器中测试应用。

      https://code.claude.com/docs/en/chrome

      看完这 13 条配置，你会发现 Boris 的核心哲学其实非常朴素：不要把 Claude Code 当作一个听话的打字机，而要把它视为一个需要上下文、需要反馈、甚至需要被“管理”的超级工程师。
      在这套配置中，最令人深思的或许不是那些复杂的斜杠命令，而是最后一点——“验证机制”。当我们将权限、记忆（CLAUDE.md）和验证工具（测试套件）赋予 AI 时，它产出的代码质量竟能提升 2-3 倍。这提醒我们，在 AI 编程时代，人的价值并没有被抹杀，而是发生了转移：我们从枯燥的代码实现者，变成了系统的架构师和 AI 的验收官。
      现在的你，手中已经握有了这份“终极说明书”。不必急着一次性应用所有配置，建议从建立一个共享的 CLAUDE.md 或编写第一个 /slash-command 开始。你会惊讶地发现，当你开始用“团队伙伴”的标准来配置 Claude 时，它回馈给你的惊喜将远超预期。
      现在的你，准备好为你的 AI 队友配置第一个“外挂”了吗？

      技术团队运用度量驱动开发提升质量：策略与实践

      Published 2023年11月1日 / by 高成

      背景介绍

      公司要发展是为了保持竞争力、实现可持续发展并满足市场需求。随着市场环境的不断变化，公司需要不断创新、拓展业务范围、提高产品质量和服务水平，以适应不断变化的市场需求和客户需求。只有不断发展的公司才能在市场中立于不败之地，实现可持续发展。而业务是公司发展的基础和核心，公司通过不断拓展和优化业务来实现发展目标。
      随着业务多模式发展，二手车业务已经从相对简单的业务逐步转变为包含交易业务交易、O2O、信息业务等。随着业务的发展，用户在业务中的生命周期获得了延长，用户端和商家端在业务上结合得越发紧密。在此基础上，还有新旧业务功能持续集成，以此来产生协同效应。越来越多的业务流程也导致了管控难度的提升以及流程上下游之间衔接点的增多。在这个业务发展的背景下，技术系统在支撑业务功能迭代时发现，由于业务的广度和深度的增加，技术系统在实现业务目标时，服务与服务之间的调用链路增长，关系增多，业务目标服务与服务之间的转化难度也在逐步提升，技术系统领域的复杂度也产生了新的增长。这些技术系统的问题会直接反映在业务目标的转化上，体现在是否更快速、更高效。

      意义价值

      技术团队的目标是开发新功能和保障技术系统稳定运行。业务的实现严重依赖于技术系统的运行状况，而越是复杂的技术系统，就越需要技术团队来掌控其运行状态。只有当技术团队很好地掌握了技术系统的运行状况时，才能助力业务目标的实现。提高技术团队的掌控能力需要深入洞察技术系统的运行状态。随着技术系统的复杂度不断提高，技术团队面临着三个关键性洞察力问题。从业务视角来看，技术层面的监控系统缺乏对业务的深度监测和评估，链路监控无法实现对业务转化链路的串联监测，而仅有的基础资源类监控指标无法反映业务结果。

      业务部门的技术团队作为为商业侧服务的技术团队，其目标都是支撑业务实现商业价值。技术团队的核心问题在于提升商业转化路径上各个业务节点的技术质量。技术团队在技术层面需要提升对技术系统的洞察力，在业务层面需要确保商业转化路径的质量。上述两个方面的诉求归根结底都与技术系统的质量相关，既横向保障业务在商业转化路径上的质量，又纵向保障技术系统在系统调用链路上的质量。综上所述，技术团队的任务是实现商业价值，而商业价值的实现路径需要有很好的质量保障。技术团队需要解决的问题是提升系统的洞察力，以夯实实现商业价值的基础。

      实践操作

      实现商业价值

      那么业务侧的技术团队如何实现商业价值？技术团队可以通过优化业务流程、开发和实施高效的业务流程来提高公司的整体运营效率。也可以通过创新产品或服务、研发新技术或新产品来满足市场需求，从而带来商业价值，或者通过降低成本、优化技术方案来降低公司的运营成本等多种方式来在实现商业价值中做出贡献。通过拆解技术团队的日常工作，技术团队在实现商业价值中的核心是两个事项：编写代码和运行代码，然后实现新功能、改进现有功能、修复错误、提高性能或降低成本等。所有这些产生商业价值的事情只有在代码运行时才能提供，而不是在编写时就可以提供。因为即使代码设计模式适用、代码注释详尽、数据算法高效，如果没有运行，对于业务而言仍然没有实现任何商业价值。运行中的代码才是有商业价值的。因此，为了为业务提供最大价值，技术团队需要尽可能深入地了解代码运行时的状态，而技术系统的度量指标通常是实现这一要求的唯一方法。

      行业解决方案

      服务于业务侧的技术团队，希望能够通过对技术系统的持续改进在实现商业价值中做出更多的贡献。结合团队的诉求和现实情况，行业内有各种各样的监控系统，能够实现技术系统端到端的监控，比如Prometheus等。同时，汽车之家内部也有一些自研的监控系统，基本能够实现全覆盖的监控。然而，技术系统的持续改进与带来商业价值之间总是缺乏一个有效的链接。我们逐渐认识到单纯部署一个或是几个监控系统不能解决我们的诉求，我们需要的是一种能够建立在基于数据的决策思想之上的方法，旨在提高软件质量、性能和可维护性，在整个软件开发生命周期中持续收集、分析和利用各种度量和指标，通过与业务侧深度协作，通过有益的决策来推动持续改进。这与度量驱动开发（Metrics-Driven Development，简称MDD）的理念不谋而合。
      度量驱动开发主张整个应用开发过程由指标度量驱动，通过实时度量指标来驱动快速、精确和细粒度的软件迭代。度量驱动开发的理念，不但可以让技术团队实时感知技术系统的状态，及时跟踪定位并解决问题，而且可以帮助业务和运维团队一起关注相关的业务指标。

      度量驱动开发（Metrics-Driven Development）的理念理早是在2011年3月12日Etsy公司举办的一次技术交流会上，由Etsy核心平台部负责人Mike Brittain提出的。

      应用可观测性

      业界对于度量驱动开发有许多应用的案例和实践，来自Gartner的《2023年重要战略技术趋势》中的“应用可观测性”也介绍了类似度量驱动开发一致的理念。

      “应用可观测性是指，以高度协调和整合的方式 在业务职能部门、应用和运维(I&O)团队中应用可观测的数据，尽可能缩短行动与响应之间的延迟，实现业务决策的主动规划。”
      引用

      Prometheus

      Prometheus官网的宣传标语是From metrics to insight（从指标度量到洞察力）。

      度量驱动开发

      度量驱动开发的理念是需求阶段就考虑设置关键指标监控项，随着应用上线，通过指标了解系统状态，通过对现状的数字化和可视化，帮助业务对未来进行规划和预测，进而实现业务改善。而且度量驱动开发是一种文化的纽带，对于敏捷开发、持续集成、持续交付，以及各个职能岗位提升合作共赢的意识具有很大的帮助。

      • 对业务而言，可以实时掌控业务各项指标，通过数据做出决策。
      • 对研发而言，可以实时感知应用各项指标、聚焦应用优化。
      • 对运维而言，可以实时感知系统各项指标、快速定位问题。

      度量驱动开发可使所有可以测量的东西都得到量化和优化，进而为整个开发过程带来可见性，帮助相关人员快速、准确地做出决策，并在发生错误时立即发现问题并修复。我们希望通过感知技术系统的运行状态，并且不断根据运行时的数据提供改进策略，将上线、监控、调试、故障调查及优化等纳入设计阶段，而不是等到系统部署后再去补充。相对于通过制定各种复杂、严格的研发规定，以及各种评审会议来确保技术系统的安全可靠、稳定运行，度量驱动开发的理念的特别之处在于，通过采集必要的监控信息，通过持续交付方式进行快速迭代并进行反馈和修正，所有决定都是基于对不断变化的情况的观察做出的。

      团队实践探索

      技术团队在采用度量驱动开发的实践探索过程中，总体分为4个阶段，首先，依据业务的范围进一步圈定核心领域。其次，通过核心领取构建度量指标体系。再次，通过对于度量指标的监控协同业务侧推动部分指标的改善，我们在此采用了最小可行产品（Minimum Viable Product，MVP）的策略，通过构建具有最少功能的版本，尽早地推出产品以测试反馈并验证概念的可行性。最后在验证效果后建立可视化的技术系统来推动整体的实践探索更具易用性、扩展性的落地和发展。

      度量驱动开发那么首先需要解决的问题就是度量，也就是度量指标体系的构建，回顾探索实践的过程，在实践探索的过程中遇到的困难的也是度量指标体系的构建。度量指标体系的构建我们的目标是做到覆盖尽可能全面的覆盖，我们对于全面覆盖总结为横向和纵向2个方向上的覆盖。首先，横向需要满足业务的广度尽可能的纳入更多的核心关键业务，其次，纵向需要将业务-技术纵深进行深入的挖掘覆盖尽可能多的核心关键技术系统。

      团队在度量指标体系的构建中，围绕业务流程的服务树，通过业务流程中各个关键节点的指标的下钻和穿透到极致，再通过参考Google SRE中提出的系统监控的四个黄金指标，构造业务-技术的全覆盖度量指标体系。

      • 延迟（Latency）：衡量服务请求所需时间。例如，从技术视角所关注的HTTP请求平均耗时，而在业务视角下为用户完成下单操作的所需时长。
      • 流量（Traffic）：衡量服务的容量需求。例如，从技术视角下每秒处理的HTTP请求数或者数据库系统的事务数量，业务视角下用户完成下单的数量。
      • 错误（Errors）：衡量服务错误发生的速率。例如，技术视角下HTTP 500错误数等显式失败，返回错误内容或无效内容等隐式失败，业务视角下用户下单失败数量等。
      • 饱和度（Saturation）：衡量当前服务的饱和度。例如，技术视角下内存、CPU、I/O、磁盘使用量，业务视角下的任务的完成率、优惠卷的使用量等。

      技术在系统建设阶段完成了一个覆盖业务上用户端到商家端，技术上客户端到服务端的全景监控系统的建设，核心功能包括数据可视化、业务链路定制和监控预警。首先，我们复用公司的数据处理能力，包括数据收集、清洗、转换和存储等基础数据处理服务，通过复用它们，我们能够迅速获取数据处理能力，确保数据的准确性和一致性。另外，我们通过接入前端性能监控、云监控以及质量罗盘等监控系统，我们实现对整个技术系统的实时监控。在系统建设的技术选型上，我们选择了低代码平台作为开发工具。低代码平台提供了可视化开发环境，减少了开发工作的复杂性，不仅加快了构建和迭代速度，还提高了系统的灵活性和可扩展性。全景监控系统的建设不仅有助于团队更好地理解和管理其业务和技术系统，还为未来的创新和扩展奠定了坚实的基础。

      实践成果

      完成度量指标体系构建

      完成基于业务的度量指标体系构建，完成设计近400个相关数据指标，实现了业务流程和技术系统的全面覆盖，具有重要意义。这一成果为业务提供了全面的数据洞察，帮助业务和技术人员更好地理解业务进展和技术系统，从而做出更明智的战略决策、提高效率、优化资源分配、改善客户体验，最终实现竞争优势和可持续增长。这些指标不仅提供了深刻的业务洞察，还为数据驱动的决策和创新奠定了坚实的基础。

      形成改善的度量指标

      商业价值提升，用户买卖车信息的处理效率提升240%，用户卖车信息的从车辆信息的提交再到将车辆信息通知商家进行处理这其中要经历很多业务流程以及技术系统，通过对车辆信息数据处理流程时长的监测发现问题点，通过与业务方协作的方式，改进车辆信息数据的处理流程，提高了数据留转与处理的时效，通过技术系统的改善提升了业务的运转效率，提升了商业价值。
      商业价值挽回，拦截异常车况报告解析订单2000单，在车况报告解析积压和延时的及时预警发现问题点，通过对异常情况的的及时跟进处理拦截异常订单，实现商业价值的挽回。

      未来展望

      度量驱动开发（Metric-Driven Development，MDD）在软件工程领域扮演着关键的角色。它强调了度量数据在软件开发过程中的重要性，这些度量数据可以是关于代码质量、性能、可维护性、进度等各个方面的信息。首先，度量驱动开发有助于质量的改进。通过定期收集和分析度量数据，技术团队可以更好地了解软件质量的状态。这包括了解代码质量、性能表现、可维护性等各个方面。当度量数据揭示出问题或潜在的缺陷时，团队可以采取措施来改进质量，确保软件达到高标准。其次，度量数据可以用于目标设定。技术团队可以根据度量数据来设定明确的开发目标。例如，他们可以使用性能度量来设定性能目标，代码质量度量来设定代码质量标准。将这些目标加入到技术团队开发过程中的指导原则，有助于确保项目朝着期望的方向前进。此外，度量数据可以提供决策支持。项目管理和决策制定者可以根据度量数据做出明智的决策。例如，他们可以根据度量数据决定是否进行技术债务的偿还、是否进行性能优化、是否进行安全漏洞修复等关键决策。持续改进是度量驱动开发的核心原则之一。通过分析度量数据，团队可以识别问题的根本原因，并采取措施来不断改进开发流程、工具和实践，以提高效率和质量。最后，度量数据还有助于提高透明度和沟通。团队成员可以共享度量数据，让每个人都了解项目的状态和质量，有助于更好地协作解决问题。

      通用化建设

      下一个阶段重点建设的方向是监控工具的通用化建设，通用化的工具建设将更加灵活，允许团队根据其特定需求进行定制和扩展，能够满足不同团队和业务的需求。通用化的工具建设将更易于扩展，支持集成新的数据源、第三方插件和自定义脚本，以适应不断变化的技术栈和复杂性。这将为团队提供更大的灵活性，使他们能够构建适合其独特需求的度量驱动开发的解决方案，从而更好地理解和管理他们的技术系统和业务。

      智能化建设

      人工智能在软件领域有广泛的应用场景，比如AIOps等，未来支持度量驱动开发的工具系统需要更加自动化和智能化。机器学习和人工智能技术将用于分析监测数据，自动检测问题、异常和趋势，并提供实时的反馈和建议。通过机器学习和人工智能技术的应用将更有助于更精准的定位问题，更快地响应和解决问题，减少人为干预的需求，提高效率、可用性和安全性，降低成本，推动团队更好地进行资源利用。

      写在最后

      正如现代管理学大师彼得·德鲁克所说的“如果你无法度量它，就无法改进它”，度量帮助我们更深刻认识软件工程领域中的方方面面，设定改进方向，并衡量改进效果。

      参考文档

      Metrics-Driven Development https://legacy.devopsdays.org/events/2012-italy/proposals/MetricsDrivenDevelopment/
      An Intro to Metrics Driven Development: What Are Metrics and Why Should You Use Them? https://www.freecodecamp.org/news/metrics-driven-development/
      Metrics-Driven Development https://sookocheff.com/post/mdd/mdd/
      Metrics-Driven Development https://www.infoq.com/articles/metrics-driven-development/

      关于系统重构的10点经验总结

      Published 2017年9月21日 / by 高成

      做我们的日常工作中系统重构都应该是最让人头疼的工作了，无论是错综复杂还是经意简单的系统在发展的过程中都会经历重构，而系统重构也是任何一个技术团队都无法回避的问题，在我服务的多家公司几乎每家公司都经历了一次甚至多次系统的重构，本文就我在多年的重构工作中总结出来的几点建议分享给各位朋友，希望能够给朋友们带来帮助。

      1、重构确定并且聚焦目标

      首先我相信我们大家都确信系统重构是会有巨大的成本投入的，业务可能需要暂缓、新系统引入的问题（BUG）带来业务的不稳定、研发人员以及配合人员的投入还有各种隐性成本等等，我们服务的是一家商业公司获取利润是最终目的，在投入具体成本做一个项目就肯定要获得收益的。重构的目标一定要能够获得更大的提升无论是业务流程还是系统性能或是其他方面，如果仅仅一个很小的改善完全没有如此的大费周章，权衡好成本是否能够获得良好的收益。

      无论如何进行系统重构都是一次伤筋动骨的过程，是涅槃重生还是飞蛾扑火，完全取决我们项目执行的过程中是否明确了目标且一直聚焦于目标的实现，保持目标的聚集是能否取得良好结果的必要促销，如果我们仅仅确立了目标没有聚集于目标在多个非重要的节点投入较大资源必然会导致我们对目标的投入降低，工作中的原始资本投入都是8个小时，当然如果每个人都愿意乐于加班的话另外讨论，而我们的实际情况往往是8个小时都是不够用的，这就更加需要我们明确目标聚焦目标，把有限的资源投入到最重要的事情中，才能获得既定目标的良好结果。

      2、重构要有可量化的指标

      团队确认了重构的目标之后，下一步一定要将目标量化，确定好目标之后也就能够确认边界，围绕在边界内要将需要实现的事项一一罗列出来，并且尽可能对每个实现制定可以用数据清晰表现出来的指标，比如用户操作的响应时间缩短到100毫秒、单元测试的覆盖率达到80%、发现问题时长降低到30分钟以内等等，有了明确的数据指标我们才能评估最终是否获得了良好收益，这些目标必须要在重构团队，包括产品、研发、测试等等，甚至包括业务方在内达成一致，是团队的目标清晰明了，防止出现过度或是不达标是最终不能获得良好收益。

      3、重构要有更好的质量

      既然决定了要对系统进行一次重构，那么我们肯定要做到的就是要比之前做的更好，如果之前接口响应时间在100毫秒，而经过重构之后反而减低到了200毫秒以上那么岂不是很难看，大家辛苦付出的努力是不是也更加不值得。而进行重构往往是一件十分引人注目的事情，一个微小的问题反而容易在众人注目下变得非常严重的问题。为了减少引起不必要的麻烦，重构团队就更加要注重各个方面的问题，无论是系统性能、用户体验还是BUG数量等

      4、重构之前要和业务方沟通

      技术团队进行系统重构的工作的时候往往忽略掉了业务方，认为这是技术团队内部的事情，不需要知会业务方，这个想法是非常错误的，进行重构的目标就是为了改善改进业务流程，而不去和业务方提前沟通进行闭门造车，最后的结果很可能和进行重构的初衷背道而驰。进行系统重构首先我们必须了解现有系统的业务需求，是否有待改进的业务需求点，是否有新的业务诉求等这些需求往往会影响到我们重构的进度和目标，甚至出现南辕北撤的事情。
      技术团队和业务方往往对待问题的出发角度不同，思考问题的方式也不同，在进行重构之前和业务方沟通获得业务方的支持，往往能够事半功倍。
      例如，我的团队在进行一块业务系统重构的时候进入到了系统切换的试运行的阶段，由于拿出的方案给到业务方无法被业务方接受，业务方提出的解决方案我们还需要进行再次开放对整个项目进度影响了足足一个月时间之多。吸取教训的我们在进行下一个项目的时候提前和业务方进行了沟通，业务方从他们的角度给予了很多的意见和建议以及业务未来的发展方向的指引，我们发现这些建议和意见帮助我们更好理解业务的同时也大大的降低了我们工作量，减少了我们很多冗余的设计。

      5、重构应该才用迭代的方式

      参与过重构项目的朋友都知道，重构项目往往是个时间跨度很长的工作，少则一两个月多则一年半载都有，如果不将整个重构进行合理拆分，而是采用全部开发完成，再进行系统切换的方式会对整个重构引入很大的风险，首先长时间的时间跨度内业务会进行持续变更，其次团队面临长时间没有结果输出面临来自各个方面的压力还有系统问题持续累积，这种蒙头狂奔的方式往往造成了项目失败或是目标便宜，而采用迭代方式进行重构，可以以更小的颗粒度持续交付工作成果，交付-试用-反馈-调整，持续有交付，持续有反馈，持续调整能够保证团队的目标不会偏移，形成一个正向循环，保证最后的重构目标。

      6、重构要清晰了解旧系统

      知己知彼，百战不殆，系统重构是一个与旧系统对抗的过程，不对旧系统的弄的清清楚楚怎么能够比旧系统做的更好呢？其实了解现有系统是一个学习的过程，如果有旧系统的开发人员还在公司那么就事半功倍了，旧系统的开发同学帮忙给做次分享省去了我们重构团队很多的工作，比直接去读代码更能清晰明了的了解到旧系统的相关知识以及有哪些需求点和应该注意的问题等等，通过学习和了解旧系统设定目标基准值避免引入老旧问题也是避免重蹈覆辙的一个好办法。

      7、重构要提前规划系统切换方案

      不知道朋友有没有遇到过重构完系统发现如果进行新旧系统的切换是个难题，反正我是遇到过，由于没有提前做好规划和切换步骤导致最后临时抱佛脚，开始使用各种奇葩办法做系统切换，有的还需要增加额外工作量甚至各种办法的刷脸求人，总之这不是一个很好的体验。系统切换往往是在重构中被我们忽略的一个步骤，但是这是非常重要的一个环节，在做最初的计划就应该考虑到如何进行系统切换，一个设计好的切换方案也应该贯穿重构始终，避免因为切换方案引起服务不可用或是引入系统BUG。尤其是前期整个团队付出巨大努力取得了一定成果的时候在最后一步切换的时候出现问题对团队是个非常大的打击，也使得业务方对团队失去信心，带来很不必要的麻烦。

      8、重构高度重视系统数据

      一次系统重构大多数情况下会涉及到数据结构的修改，对数据结构进行修改必然引入很大的风险，尤其在一些老旧的业务系统重构精简业务去掉冗余数据的时候，往往需要将老数据的业务数据重新写入到新系统的数据库。重构的目标是为了比旧系统更好无论是性能还是业务方面，如果我们对数据的操作导致外部依赖旧系统的业务无法正常运行那将是影响SLA指标的问题还有，说到系统数据有些同学可能仅仅关注的是业务数据其实数据也包含了系统运行所产生的日志数据，无论新旧系统的日志数据都是很重要的，如果因为重构影响到数据的读取、处理、分析那么岂不是得不偿失的事情。

      9、重构要才用成熟的技术选型

      技术选型是重构工作的基石，选择一套成熟稳定的技术方案是重构项目完成的必要条件。有些时候我们引入最新版的数据库虽说会有性能提升但是也会引入一定的不稳定因素，之前我们团队在使用MongoDB的一个新版本的时候发现主从库的数据并不能很好的同步出现过丢失数据的情况，进入社区发现这个版本使用的用户很多都反馈了这个问题，这时候我们不得不选择了大多数人共同的一个选择降低了一个版本来解决问题，相信此类情况比比皆是。在不是很成熟的方案带来并不显著的性能提升反而还会引入不确定的风险的时候我们需要权衡利弊得失，重构更是要保证系统的稳定性。
      技术方案能否有足够强大的支撑也是我们需要考虑的一个方面，现在我们团队面对的重构是从单体式架构往微服务转变，旧系统的版本构建在是PHP语言上，新的系统我们由两个选择继续选择用PHP进行重构或是才用公司统一的微服务框架，我们毫不犹豫的选择了使用公司统一的微服务，这样做有几个显而易见的好处。
      1、和公司内部进行交互更加方便快捷；
      2、可以直接获取成熟的经验；
      3、基础服务有公司级的支持；
      以上的好处显然对我们能否成功重构系统并且获得足够的帮助起到了显著的帮助，反而才用PHP进行微服务，公司内部并无成功经验可以借鉴，业内也并无太多可靠的方案可以进行选择。一个成熟可靠的的技术方案是我们能否更进一步的保障和基石。

      10、重构更加关注重视团队成员

      参与过重构的同学都知道重构工作是一项枯燥乏味的工作，往往周期长、复杂度、 难度大、牵扯广、优先级低而且很有可能是一件费力不讨好的工作，开发一个业 务方期待的新功能、新模块往往比一场翻天覆地的重构更能引起业务方的重视也 更容易获取良好结果与反馈，反而不需要承担大多的压力。而越是面对这样的情 况越是需要加大对团队的鼓励增强团队的信心，消除团队的疑虑困惑，给予团队 持续的鼓励，给整个团队注入正能量，让团队保持积极向上的团队氛围，即使面 对各种困难、问题，也始终对团队保持信心保持乐观，让大家轻松愉快的投入到 重构工作中，尽量不担负额外的压力。

      以内内容均为工作中的总结反思，分享给大家希望以上的这些总结能够对大家有所帮助，文章所讲述的内容如有不足之处还望指出。

      log4php日志框架的配置使用介绍

      Published 2016年6月30日 / by 高成

      随着系统和业务的复杂度提升我们会对日志进行各种分类处理如通过日志的级别分类或是对不同的业务的日志进行分类处理，即使面对以上的需要我们仍然需要有一个统一的日志格式，这样就需要我们有一个标准的日志模块来完成这些工作，然而我们也希望这个日志模块是性能优良且方便易用的。

      Java有一个比较出名的日志组件log4j，PHP语言也有类似的日志框架，同样来自于Apache的log4php是一个多功能的为PHP使用的日志框架。和log4j类似，通过log4php我们也可以控制日志信息输送的目的地是控制台、文件、数据库甚至是套接口服务器、syslog守护进程等，同样我们也可以控制每一条日志的输出格式;通过定义日志信息的级别，我们能够更加有效细致地控制日志的生成过程。更加惊喜的是以上叙述的这些功能甚至不需要我们修改代码，而是通过一个配置文件来灵活地进行配置。

      安装介绍

      log4php提供了两种安装方式，一是通过直接下载源码包，Apache log4php – Download；二是通过PEAR渠道安装。

      PEAR方式安装命令

      pear channel-discover pear.apache.org/log4php
      pear install log4php/Apache_log4php

      目录结构

      ├───apidocs – API生成文档
      └───src

      ├───assembly – Maven的配置
      ├───changes – 更新日志
      ├───examples – 各种用法示例
      ├───main
      │       └───php – 主要源码
      ├───site – 网站源码
      └───test – 单元测试

      配置介绍

      log4php支持XML、PHP以及Properties三种配置文件，我们今天主要通过Properties方式的配置文件来讲解，此种方式的配置较为全面。如果不在日志记录前调用Logger::configure()方法进行配置，log4php使用默认方式进行配置

      日志输出方式

      名称                                     介绍
      LoggerAppenderConsole         控制台，标准输出或标准错误流。
      LoggerAppenderEcho             控制台，通过PHP的echo方式输出
      LoggerAppenderFile               文件
      LoggerAppenderDailyFile        文件（通过日志生成新文件）
      LoggerAppenderRollingFile     文件 (通过尺寸设置生成新的日志文件).
      LoggerAppenderMail              通过电子邮件发送日志，整个日志在一个电子邮件发送。
      LoggerAppenderMailEvent      通过电子邮件发送日志，每条日志通过单独的电子邮件发送。
      LoggerAppenderMongoDB      MongoDB
      LoggerAppenderNull              忽略所有的日志事件
      LoggerAppenderPDO             数据库
      LoggerAppenderPhp              通过使用PHP trigger_error（）函数PHP用户级的消息
      LoggerAppenderSocket          通过套接口输出日志
      LoggerAppenderSyslog          syslog

      日志内容输出格式方式

      名称                                   介绍
      LoggerLayoutHTML              输出到HTML表格中
      LoggerLayoutPattern            灵活格式，通过一个字符串配置
      LoggerLayoutSimple             简单格式，不可配置
      LoggerLayoutSerialized         输出序列化对象
      LoggerLayoutTTCC               包括时间，主题，类别和嵌套诊断上下文的 （不建议使用）
      LoggerLayoutXml                 输出到XML文件

      示例说明

      示例一

      配置示例

      ;定义输出方式名称default
      log4php.appender.default = LoggerAppenderEcho
      log4php.appender.default.layout = LoggerLayoutSimple

      ;定义一组新的输出方式名称为test
      ;日志输出方式设置
      log4php.appender.test = LoggerAppenderDailyFile
      ;日志内容格式设置
      log4php.appender.test.layout = LoggerLayoutPattern
      ;日志内容参数设置（日期 PID 日志级别 日志名称 日志文本 换行符）
      log4php.appender.test.layout.ConversionPattern = “%d{Y-m-d H:i:s.u} [%t] %p %c: %m%n”
      ;日志文件名称配置
      log4php.appender.test.datePattern = Ymd
      ;日志文件路径配置
      log4php.appender.test.file = /var/log/daily_%s.log

      ;日志输出方式以及输入级别设置
      log4php.rootLogger = DEBUG, default

      如果设置为已下值，日志可同时使用default和test两个输出定义进行记录
      log4php.rootLogger = DEBUG, default,test

      代码示例

      <?php

      require_once dirname(__FILE__) . ‘/log4php/main/php/Logger.php’;
      Logger::configure(dirname(__FILE__) . ‘/log4php.properties’);
      $logger = Logger::getLogger(‘exception’);
      $message = ‘hello world!’;
      $logger->error(‘error,’ . $message);//会产生记录
      $logger->info(‘info,’ . $message);//会产生记录
      $logger->trace(‘trace,’ . $message);//不会产生记录，因为设置的日志级别DEBUG，只有高于等于DEBUG级别的日志才会记录

      输出示例

      2016-12-15 16:25:55.55 [121215] ERROR exception: error,hello world!
      2016-12-15 16:25:55.55 [121215] INFO exception: info,hello world!

      示例二

      配置示例

      ;定义输出方式名称default
      log4php.appender.default = LoggerAppenderEcho
      log4php.appender.default.layout = LoggerLayoutSimple

      ;定义一组新的输出方式名称为test
      ;日志输出方式设置
      log4php.appender.test = LoggerAppenderDailyFile
      ;日志内容格式设置
      log4php.appender.test.layout = LoggerLayoutPattern
      ;日志内容参数设置（日期 PID 日志级别 日志名称 日志文本 换行符）
      log4php.appender.test.layout.ConversionPattern = “%d{Y-m-d H:i:s.u} [%t] %p %c: %m%n”
      ;日志文件名称配置
      log4php.appender.test.datePattern = Ymd
      ;日志文件路径配置
      log4php.appender.test.file = /var/log/test_daily_%s.log
      ;日志输出方式以及输入级别设置
      log4php.logger.test = INFO, test

      ;定义一组新的输出方式名称为pro
      ;日志输出方式设置
      log4php.appender.pro = LoggerAppenderDailyFile
      ;日志内容格式设置
      log4php.appender.pro.layout = LoggerLayoutPattern
      ;日志文内容式参数配（日期 PID 日志级别 日志名称 日志文本 换行符）
      log4php.appender.test.layout.ConversionPattern = “%d{Y-m-d H:i:s.u} [%t] %p %c: %m%n”
      ;日志文件名称配置
      log4php.appender.pro.datePattern = Ymd
      ;日志文件路径配置
      log4php.appender.pro.file = /var/log/pro_daily_%s.log
      ;日志输出方式以及输入级别设置
      log4php.logger.pro = INFO, pro

      代码示例

      <?php
      require_once dirname(__FILE__) . ‘/log4php/main/php/Logger.php’;
      Logger::configure(dirname(__FILE__) . ‘/log4php.properties’);

      /*
      * 使用名称为test的方式处理日志
      */
      $logger = Logger::getLogger(‘test’);
      $message = ‘hello world!’;
      $logger->error($message);//会产生记录

      /*
      * 使用名称为pro的方式处理日志
      */
      $logger = Logger::getLogger(‘pro’);
      $message = ‘Hey, beautiful!’;
      $logger->error($message);//会产生记录

      输出示例

      /var/log/test_daily_20161215.log文件

      2016-12-15 16:25:55.55 [121215] ERROR test: hello world!

      /var/log/pro_daily_20161215.log文件

      2016-12-15 16:25:55.55 [121215] ERROR test: Hey, beautiful!

      log4php的配置文件十分灵活和简单，以上的只是很简单的两个示例，还不能全面的展示出来log4php配置方面的简单易用以及灵活性，仍然希望这能够对大家有所帮助，log4php的官方提供了良好的文档以及十分丰富的API，几乎满足了我们对于日志模块需要的全部需求，大家也可以通过查阅相关文档调整配置做出自己需要的日志模块。

      log4php文档地址：http://logging.apache.org/log4php/index.html

      希望这篇文章对你有所帮助，如果没有任何帮助抱歉浪费了你的阅读时间但是我不负任何责任，如有不足支持还望指出

      给开发工程师关于日志记录的建议

      Published 2016年2月25日 / by 高成

      摘要

      对于工程师而言懂得记录合理正确的日志是件很艰巨的任务。日志是记录必要的信 息和数据，方便问题定位和追踪,给我们足够的依据解释和发现问题，以及帮我们清晰 反映出应用的运行状况,这或许能够决定一个工程师是升职还是被开除。记录日志也是 有一定原则或是技巧的，并不是把所有内容有加以记录就可以了，一是可能收到运维工 程师的抗议;二是记录过多内容反而不容易查找关键信息，说来我们的日志记录的简单 可依赖即可，简单可以依赖的关键性数据。

      一.日志要分级

      日志一定要分级。多个级别的日志等级TRACE、DEBUG、INFO、NOTICE、 WARNING、ERROR、FATAL等，不同级别的日志应当分类处理,在大型应用的海量 日志面前不分级的日志处理起来非常麻烦，我们必须要对日志进行分级分类处理，清楚的明白哪些级别的日志需要时刻关注，影响到了应用的正常运行，有些日志只是帮我们在记录应用的运行状态。

      二.日志记录必要的信息即可

      日志记录必要的信息即可，无意义的信息必须要排除在日志之外，开发工程师作为对程序最了解的人如果在记录含糊不清的日志只会增加我们查询关键信息的困难，且过多的内容记录也会招致运维工程师的反感和增加应用运行的成本，我们要明白当应用出现问题的时候日志是你唯一可以依赖的，请让保存记录最关键的信息。

      三.日志要让其他人也能看懂

      为什么要记录日志，是因为有一天我们要去读他,而读他日志的不一定是谁，有一定加密属性的日志读起来总会给我们带来很大困惑，请善待日志的读者，因为每个人都会是日志的读者。
      1.排版整洁有序，格式统一规范。随笔式的日志看起来会很麻烦，给日志读者增加很多困难。
      2.采用关键字来突出显示如：时间、操作名称等，让读者能够轻松通过关键字来精确定位日志内容。

      四.关于程序中加入日志的方法

      千万不要自己写个记录日志的方法！千万不要自己写个记录日志的方法！千万不要自己写个记录日志的方法！重要的事情说三遍，绝对不要这么做，即便是用打印输入或者是自己 写入到日志文件中，第一个这么做的朋友也会影响其他同事——首先，这会让你的代码不那么美；其次也会给你的运维工程师带来很大麻烦。每个人都自己写个日志会很容易造成日志 个格式不统一，这会给日志的收集分类带来很大麻烦，PHP有不少第三方的log类库弥补了上述缺陷，如log4php、plog、Analog等还有内置error_log、syslog函数功能强大且性能 极好，用Java开发也有很多选择，例如Log4j、SLF4J、和Logback等其他语言如Python、ruby也有相应的日志类库或是组件，请调用标准类库来完成日志记录。

      五.日志要做到方便解析

      日志记录下来一定要做到可以方便解析,因为有些时候需要做到报警或是数据提取,这 些功能往往是需要自动化实现的,如果没有一个方便解析的日志实现起来就增加了很多成本。如下,日志记录了时间、日志级别、脚本、IP地址，以及数据：
      2015-12-15 12:00:00ERRORlist.php127.0.0.1PAGE=1&NUM=500 解析以上日志是不是需要正则表达式或是更麻烦的程序逻辑来处理？答案是肯定的，如果换一种方式，很可能需要很少的工作就能达到我想要的效果。如下:
      2015-12-15 12:00:00||ERROR||list.php||127.0.0.1||{‘PAGE’:1,’NUM’:500} 这样解析起来awk -F‘||’就可以轻松解决了。

      总结

      希望这篇文章对您在开发过程中记录日志有所帮助，如果有什么遗漏之处还望见谅。看了这篇文章之后发掘没有任何帮助，抱歉我概不负责。

      python import this python 哲学

      Published 2012年9月17日 / by 高成


      Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
      [GCC 4.3.3] on linux2
      Type "help", "copyright", "credits" or "license" for more information.
      >>> import this
      The Zen of Python, by Tim Peters

      Beautiful is better than ugly.
      Explicit is better than implicit.
      Simple is better than complex.
      Complex is better than complicated.
      Flat is better than nested.
      Sparse is better than dense.
      Readability counts.
      Special cases aren't special enough to break the rules.
      Although practicality beats purity.
      Errors should never pass silently.
      Unless explicitly silenced.
      In the face of ambiguity, refuse the temptation to guess.
      There should be one-- and preferably only one --obvious way to do it.
      Although that way may not be obvious at first unless you're Dutch.
      Now is better than never.
      Although never is often better than *right* now.
      If the implementation is hard to explain, it's a bad idea.
      If the implementation is easy to explain, it may be a good idea.
      Namespaces are one honking great idea -- let's do more of those!
      >>>

      Beautiful is better than ugly.
      优美胜于丑陋。
      Explicit is better than implicit.
      明了胜于晦涩。
      Simple is better than complex.
      简单胜过复杂。
      Complex is better than complicated.
      复杂胜过凌乱。
      Flat is better than nested.
      扁平胜于嵌套。
      Sparse is better than dense.
      间隔胜于紧凑。
      Readability counts.
      可读性很重要。
      Special cases aren’t special enough to break the rules.
      即便假借特例的实用性之名，也不可违背这些规则。
      Although practicality beats purity.
      虽然实用性次纯度。
      Errors should never pass silently.
      错误不应被无声的忽略。
      Unless explicitly silenced.
      除非明确地沉默。
      In the face of ambiguity, refuse the temptation to guess.
      当存在多种可能，不要尝试去猜测。
      There should be one– and preferably only one –obvious way to do it.
      应该有一个 – 最好只有一个 – 明显的能做到这一点。
      Although that way may not be obvious at first unless you’re Dutch.
      虽然这种方式可能不容易，除非你是 Python 之父。
      Now is better than never.
      现在做比不做好。
      Although never is often better than *right* now.
      虽然过去从未比现在好。
      If the implementation is hard to explain, it’s a bad idea.
      如果这个实现不容易解释，那么它是个坏主意。
      If the implementation is easy to explain, it may be a good idea.
      如果这个实现容易解释，那么它或许是个好主意。
      Namespaces are one honking great idea — let’s do more of those!
      命名空间是一种绝妙的理念，我们应当多加利用。

      MongoDB之no db response数据库没有响应

      Published 2012年1月17日 / by 高成 / MongoDB之no db response数据库没有响应有 1 条评论

      今天查看PHP的error log有很多错误产生，有Fatal error也有Warning，本着错误的级别先开始处理Fatal error除了几条还被搜索机器人抓取的不在使用的页面产生这种错误外，发现了一个多行的Fatal error仔细查看下是：

      [17-Jan-2012 11:16:19] PHP Fatal error:  Uncaught exception 'MongoCursorException' with message 'no db response' in XXXXX.php:194

      乍一看是为捕获抛出的异常，异常的错误信息是’no db response’数据库没有响应，接下去查看代码：

      省略...
$query = array('type' => 5);
$cursor = $collection->find($query);
foreach($cursor as $key => $val) {//出错的行
	省略...
}
省略...

      变量$cursor为查询MongoDB的返回结果，但是抛出的异常是’MongoCursorException’异常信息是’no db response’，查看PHP手册解释是：This may not even be an error, for example, the database command “shutdown” returns no response. However, if you were expecting a response, this means the database didn’t give one.坑爹的PHP手册上来就说：This may not even be an error（这甚至有可能不会是一个错误），for example, the database command “shutdown” returns no response.（例如，数据库输入’shutdown’命令而没有获得相应）。
      访遍Google、百度没有获得满意的答案，不过问题应该已经比较清晰出现在了MongoDB或是网络上面，于是继续想办法查找问题中，截止到博文发布还没有找到问题原因！

      GoAccess，Apache/Nginx 日志统计分析软件

      Published 2011年12月13日 / by 高成 / GoAccess，Apache/Nginx 日志统计分析软件有 2 条评论

       

      什么是GoAccess？

      GoAccess是运行在Unix系统终端，开源、实时分析Apache日志（其实也能够分析Nginx日志）并且能够动态呈现的软件。它为系统管理员提供了一个快速、有价值的HTTP统计，动态的可视化的服务器报告。

      它是做什么以及如何工作？

      从本质上讲，GoAccess的工作方式是，它将解析众所周知的Apache访问日志文件 access log，GoAccess通过解析日志收集的数据，将会显示它的控制台或某个终端。收集到的信息或生成的报告将显示给在视觉、交互窗口的系统管理员用户。报告包括：

      • 综合统计
      • 访客排行榜
      • 请求文件排行榜
      • 请求的静态文件排行榜，如图片、JS文件、CSS文件等
      • 访问来源
      • 404页面
      • 访问者的操作系统
      • 访问者的浏览器
      • 浏览器和蜘蛛（搜索爬虫）
      • 主机，反向DNS，IP位置
      • HTTP状态码
      • 推介网站
      • 搜索关键词
      • 显示时不同的配色方案
      • 无限制日志文件的大小（决定了GoAccess的打开速度）

      日志文件格式

      GoAccess可以解析Apache的日志格式，通用日志格式（CLF）和组合日志格式（XLF/ ELF），包括虚拟主机. 它也能够解析Nginx日志. (如果你按照Apache日志的格式配置了Nginx日志)

      GoAccess主页 http://goaccess.prosoftcorp.com/

      安装方法

      1、安装GoAccess需要一些系统支持库

      Ncurses 提供字符终端处理库，包括面板和菜单
      GLib C语言的函数库（大于2.0的版本）
      GeoIP 通过IP，定位他的经纬度，国家/地区，省市，甚至街道等位置信息。(如果不需要这个不是必须的，配置时候去掉这个选项 –enable-geoip)

      CentOS下yum安装

      yum install ncurses-devel
yum install glib2-devel

      Ubuntu下apt安装

      apt-get install libglib2.0-dev
apt-get install libncursesw5-dev

      2、安装GoAccess

      CentOS下安装

      wget http://sourceforge.net/projects/goaccess/files/0.4.2/goaccess-0.4.2.tar.gz
tar zxvf goaccess-0.4.2.tar.gz
cd goaccess-0.4.2
./configure --enable-utf8
make
make install

      Ubuntu下安装

      apt-get install goaccess

      GoAccess使用介绍

      启动参数介绍：

      • -b 流量消耗统计，如果想要提高解析速度，不要开启这个选项。缺省值为不开启此选项
      • -f 日志文件路径。
      • -s HTTP 状态码报告，为了能够更好的解析日志，选项被默认关闭。
      • -e 指定IP地址的访问统计。
      • -a 通过代理的请求统计。

      菜单介绍

      • F1 帮助菜单
      • F5 刷新
      • q 退出当前口窗、菜单、或是当前查看的选项
      • o 打开当前的选项、菜单
      • c 改变窗口配色（目前只有两种 默认和绿色）
      • SHIFT + TAB 从当前选定模块向后切换
      • RIGHT 打开当前选中模块，查看详细信息
      • s 通过日期排序，只会在访问请求模块起作用
      • S 通过点击次数排序，只会在访问请求模块起作用
      • / 查看详细信息的窗口进行搜索
      • n 通过/进行查找后，查找下个匹配的内容的位置，如果没有则在窗口底部显示“search hit BOTTOM”
      • t 在查看详细信息窗口，移动指针到最顶部
      • b 在查看详细信息窗口，移动指针到最底部

      使用实例

      • 最简单、快速的使用方式
      goaccess -f /data1/logs/blog.wuwangwo.net/access.log
      • 产生完整、全面统计数据的使用方式
      goaccess -f /data1/logs/blog.wuwangwo.net/access.log -a -s -b
      • 通过管道的方式将更多access log 通过GoAccess解析
      zcat access.log.*.gz | goaccess

      或者

      zcat -f access.log* | goaccess
      • 另外一种通过管道使用GoAccess解析日志的方式
      sed -n '/05\/Dec\/2010/,$ p' access.log | goaccess -s -b
      • 低优先级运行GoAccess的方式
      nice -n 19 goaccess -f access.log -s -a -b
      • 如果你只把GoAccess安装到了一台服务器上
      ssh user@server 'cat /var/log/apache2/access.log' | goaccess -s -a -b

      注意事项

      1. 每一个详细信息窗口，只显示300条数据
      2. GoAccess 通过管道解析日志时将禁用实时解析的功能

      总结

      GoAceess 不是很大的一款软件却有着强大的功能即使软件可能还有些BUG，软件的更多介绍信息请查看GoAccess的官方网站«./GoAccess»，当前版本的官方手册页面 Man Page