项目管理工具、组织模式、软件工程史，以及几个跨世纪的时间炸弹。

一、工程实践

Monorepo架构

Monorepo 把多个包放进同一仓库，共享工具链和原子提交。前端常用 pnpm/yarn workspace，再加 Nx 或 Turborepo 做增量构建。好处是跨包重构能一次改完，CI 可按影响面构建。代价是权限、克隆体积和流水线复杂度上升。传统多仓适合边界清晰、发布节奏完全不同的团队。

选型先看包是否经常一起改。workspace 解决依赖提升，增量构建解决每次全量打包。代码所有者要按目录划分。版本发布可用 changesets。不要把无关语言项目硬塞进来。缓存命中率是健康指标。Monorepo 不是银弹，它把协调从 Git 子模块挪到工具层。没有严格的包边界，仓库只会变成更大的泥球。

数据结构与算法 字符串匹配-KMP算法

KMP 字符串匹配的关键，是用 next 数组把模式串自身的前缀后缀信息记下来。比对失败时不再把主串指针回退一格，而是让模式串跳到 next[j]，从而把暴力法的 O(n*m) 压到 O(n+m)。

构造 next 时把模式串对自己做一遍 KMP：当 p[i]==p[j] 时同步前进；不等时 j 回退到 next[j]。注意 next[0]=-1 与 next[j]=j 这类边界，否则容易死循环。

实战里可先用“部分匹配 + 失败跳转”手推一遍，再对照代码。面试常考为什么 next 要减一、为什么不能回退主串、以及与 BM/Sunday 的适用场景差异。

软件开发模型

软件开发模型用来约束需求、设计、实现与验证的节奏。瀑布模型强调阶段门禁，适合需求稳定、验收标准清晰的项目；迭代与增量模型把大系统拆成可交付切片，便于尽早暴露集成风险。

螺旋模型把风险分析嵌进每一轮循环，适合不确定因素多的研发。敏捷则以短周期反馈为主，用待办优先级和持续集成压缩变更成本。选型时不必迷信某一种名称，关键是看变更频率、团队规模和交付约束：监管严、文档重就偏计划驱动；市场窗口短、需求易变就偏迭代。无论哪种模型，都要把测试前移，并保留可回滚的发布路径。

软件设计阶段

软件设计通常按层次推进：需求沉淀用例与约束，架构选定风格与质量属性，数据库出 ER 与表，接口写契约，详细设计补类图时序，UI 出原型，部署画拓扑与回滚。

各阶段产物要可验证，而不是装饰性文档。接口变更先改契约再改实现。数据库迁移脚本与模型同步。非功能需求（延迟、安全）在架构阶段写进验收。

小团队可裁剪，但不能跳过“边界与失败语义”。评审看风险而不是看图多不多。设计结束的标志是：实现者能独立开工，测试能写出用例，运维知道怎么发布。

二、工具

Jira

Jira 是议题跟踪与项目协作工具，用 Issue 类型区分需求、缺陷和任务，用工作流约束状态流转。看板或 Scrum 板把待办、进行中、完成可视化。字段、权限和通知方案决定一个团队能不能把工具用起来，而不是界面漂不漂亮。和 Confluence、Bitbucket 或 GitHub 打通后，提交信息能回写到工单。

落地时工作流要短，状态不要多到没人记得含义。负责人、截止日期和验收标准必须填。子任务拆到可在一个迭代内完成。报表看周期时间和阻塞原因，而不是只看燃尽是否好看。权限按项目角色配，避免全员管理员。Jira 再强也替代不了站会：票是记录，沟通仍要发生在人与人之间。

禅道

禅道是国产项目管理软件，覆盖产品、项目、测试和质量。需求从产品端进入，分解成任务进迭代，测试用例和缺陷再回流。它把研发过程按角色拆开：产品经理管需求，项目经理管任务，测试管用例。对习惯瀑布加迭代混合的团队比较容易对上。

用起来要先统一需求粒度，避免一张票从调研写到上线。缺陷必须能回到具体需求和版本。燃尽和延期原因要每周看一次。权限按产品线划分，防止串项目改状态。和代码仓库、CI 的关联能减少手工填版本号。工具不能代替评审：需求仍要当面确认验收标准，否则禅道里全是“已完成”但线上行为对不上。

Source Insign

Source Insight 是面向 C/C++ 的代码阅读器，强项是解析工程后的跳转、调用树和上下文高亮，适合啃大型嵌入式或驱动代码。它不是完整 IDE，编译和调试仍交给各自工具链。

把源码根目录加进工程，等它建索引后再浏览。自定义解析规则能改善宏比较多的代码。与 Git 配合时注意它缓存的是快照，更新代码后要刷新工程。许可证按席位管理。现代替代有 clangd、Understand 等，但在老 Windows 工作流里 Source Insight 仍然快。用它定位关系，用编辑器改代码，比强行把它当唯一开发环境更顺。

gStack

gstack 常用来把正在运行的进程调用栈打印出来，帮助判断程序卡在系统调用、锁等待还是用户态死循环。它比事后 core dump 更轻，适合线上先看一眼再决定要不要深入剖析。

使用前确认权限与符号表，stripped 二进制只能看到地址。多线程程序要看所有线程，主线程卡住不代表工作线程也闲着。输出应和日志时间对齐。频繁采样会有停顿，生产上要控制次数。它解决的是“现在卡在哪”，根因还得靠代码与锁图。能用语言级 profiler 时优先用，gstack 更像应急望远镜。

三、管理与经营

责任经营制

责任经营制把经营单元当作相对独立的利润中心：收入、成本、库存和客户体验都有明确负责人，而不是只考核销售额。它强调“谁决策谁承担结果”，避免职能墙把问题推到下一个环节。

落地需要可拆分的核算口径：内部结算价、公共费用分摊规则、以及允许单元自主采购或外包的边界。口径不清时，报表漂亮但没人愿意接难单。

信息化侧要提供按单元切片的经营看板，而不是全公司一张总表。审批流也要跟着授权走，否则责任被下放、权限仍集中，制度只会停在口号。

阿米巴模式

阿米巴模式把组织拆成可独立核算的小团队，像细胞一样按市场原则内部交易。每个单元看见自己的收入与费用，用单位时间附加值衡量贡献，而不是只看人头或工时。

它依赖透明的内部定价和及时的经营会计。定价不公会让上游囤单、下游拒单；会计滞后则让一线无法当天纠偏。文化上还要防止单元优化局部、损害整体客户体验。

系统实现重点是细粒度的组织维度、内部结算凭证和日结报表。先选一个交付清晰的业务线试点，再复制规则，比一次性全公司切分更稳妥。

OGAS

OGAS 常指苏联时期提出的全国自动化管理系统构想，试图用计算机网络把计划、生产和统计连成一体。它在技术史里被当作“超前的国家级信息系统”，受限于通信、算力和体制，最终没有按蓝图建成。今天再提这个词，多半是在讨论大型实时控制系统、工业互联网或国家级数据平台时，拿它当早期参照。

对工程的启发不是复刻那套机构，而是认清规模带来的问题：标准不统一、反馈延迟、局部优化伤害全局。现代 MES、ERP 和数字孪生要解决的仍是数据采集、一致口径和决策闭环。做系统时先把可观测的指标和责任边界划清，再谈“全国一张网”。历史文本适合当背景，落地仍要回到具体协议、数据库和权限模型。

电子软著和纸质软著是什么？有什么区别？

软件著作权登记证明软件的权属，常见有电子证书和纸质证书两种形态。电子证下载快、便于上传应用商店；纸质证由登记机构制发，周期更长，适合需要原件归档或投标的场合。二者法律效力应看登记机关，而不是下载速度快慢。

申请材料通常包括源代码和文档鉴别材料，注意版本与实际发布一致。民间加急代办不能替代官方登记，上架审核时可能不被认可。名称、权利人和首次发表日期要和包名、公司主体对齐。电子软著丢了可再下载，纸质遗失按机构流程补办。具体时限以中国版权保护中心当时规则为准，不要只信中介口头承诺。

四、历史遗留问题

2038问题

2038 问题来自 32 位 time_t：从 1970-01-01 起的有符号秒数会在 2038-01-19 溢出。嵌入式设备、旧版 Linux、部分数据库字段和协议时间戳一旦仍用 32 位，到期后可能把日期显示成 1901 年或直接崩溃。

修复路径是把时间类型升到 64 位，并检查序列化、文件格式和跨语言接口是否仍按 4 字节传输。只升级编译器不够，持久化层和第三方 SDK 也要一起盘点。

现在就要在测试环境把系统时钟拨到临界点附近跑回归，尤其是证书校验、定时任务和日志轮转。越早发现依赖 32 位时间的模块，迁移成本越低。

千年虫

千年虫指用两位数字表示年份时，1999 翻到 2000 会被当成 1900。财务结息、保险条款、嵌入式控制器和批处理作业都可能因此算错账期或拒绝合法日期。

当年的修复手段主要是扩字段、窗口化世纪判断，以及在外围加转换层。遗留系统里仍能见到两位年份文件和“年份减 1900”的整数存储，新接口如果沿用旧约定会把问题带回来。

今天更现实的风险是历史归档无法正确排序、报表跨世纪汇总出错。导入旧数据时要显式补齐世纪，并写断言校验日期区间，而不是默认“两位年一定是 19xx”。