大型项目的工程原则与Vibe-Coder生存法则

编写大型项目的时候，正确遵守设计原则就变得非常必要。

开闭原则在5w行以内重要性还没有那么凸显出来，但随着项目体积的累计，尽量遵守开闭原则几乎成了repo的生命线。开闭原则说的是，对修改关闭，对拓展开放。一方面本身SE就遵守项目越大，已经被验证work已经被test的代码就不要再轻易加参数穿插路径去改动了，因为心智负担极大，改动成本极高。vibe coding时代更是如此。很多人说AI今天写代码很厉害了，但是项目庞大起来，AI的上下文有限，在庞大的repo中穿插各种新功能的路径和参数，代码迭代和维护的心智负担会超级超级大。如果能尽量维护开闭原则，一方面对AI上下文的注意力集中有好处（大部分精力专心于产出连贯的新代码），一方面本身也符合SE的本质特点。

大型项目，解耦做依赖注入同样非常必要，我觉得一个很好的规范是，假如你是vibe coder，对自己repo的一个约束可以是：每个文件最多250行，考虑到跨文件可能会造成反向的可读性缺失，允许你最多3个文件可以超过250行但是仍然不能超过600行（但是尽量还是都250行以内）。可读性极强，解耦优秀，单测集测量化覆盖率大于95%。如果设计的时候能按照这样的约束来强迫自己，那么设计出的系统那概率是能经得起迭代和维护的。用文件体积倒逼需求和设计的解耦，用高测试率快速锁定大部分已经写好的逻辑，是个很好的方式。

所有coder平常写代码必须用git，必须做version control，这是死律。if you write code without using git,don’t say you are a coder.我认为正确使用git是工程能力提高的必要条件。我建议找几个小伙伴，找一个空闲的下午，大家边喝咖啡，边一起实操探索git的各种玩法，it only takes half of a day to master git，using this way.此外，我还观察到infra或者开发大佬的github无一例外全年一片绿色，这也是非常重要的。

今天很多人做vibe coder，产出了很多代码，但是没有review就没有进步，没有test就没有质量，wrong plan wrong design，no doc-code sync，no review，no test四者但凡只要占一样，repo都活不过代码行数5w+的那一天。

以上是一些如何做如何迭代如何维护大型项目的心得。