最近有点空，琢磨着跟大家聊聊“正身明法”这四个字。听起来挺玄乎，好像是古代官场上的什么规矩，用在咱们现在生活里也挺受用的，尤其是在做项目或者管团队的时候。
我一开始接触这词儿是在看古代官制史料的时候。那时候的官员，要做到“正身”，就是自己得立得住，行为端正，不能贪赃枉法。这“明法”就更直接了，得把国家的法律、规矩摸得门儿清，做到心中有数，办事才能有理有据。
咱们别扯太远的，就说说我前阵子搞那个内部系统重构的事儿。当时团队里有点乱，大家都忙自己的，代码风格不统一，遇到问题互相推诿。我琢磨着，这就是“身不正”加“法不明”的现实体现。
第一步，我先得“正身”。说白了，就是我这个项目经理得拿出个样来。我给自己定了个规矩：任何代码提交，我第一个Review，而且必须保证结构清晰，注释到位。我写了个小工具，专门检查代码的规范性，自己先用着，发现什么问题，立马改自己的。
我记得有一次，有个核心模块的逻辑卡住了，技术骨干小张提了个方案，看着好像能跑起来，但总觉得有点别扭。我把手头不急的活都放下，花了一整天时间，把小张的方案从头到尾捋了一遍。我没直接否定，而是跟他一起画流程图，梳理数据流向。
在这过程中，我发现他绕了个弯子处理一个异常分支，要是按他说的做，后期维护起来绝对是灾难。我直接跟他说：“这个实现虽然能暂时解决问题，但明显不符合我们之前定的那个数据一致性原则，相当于‘身不正’了。”
第二步，就是“明法”。这个“法”不是天生的，得我们自己立起来。我召集大家开了个会，把之前散落在各种文档里的代码规范、接口标准、错误处理机制，全部统一起来，写了个《项目开发手册V1.0》。
这手册写起来简直是个体力活。我把过去一年里所有返工最多的地方都挑出来，把处理它们的最佳实践写成了标准。比如，数据库操作必须用ORM框架的封装方法，禁止直接写SQL；日志级别必须严格区分，Error和Warning的用途写得清清楚楚。
起初大家很不适应，觉得管得太死。我就组织了几次小型的“法律学习会”，不是培训，就是拿着最新的手册，对比着以前的老代码，讲讲为什么以前那样写容易出问题，现在的新规矩怎么能避免这些坑。
比如，我们以前处理用户权限校验，图省事，直接在业务逻辑里硬编码了几个角色ID。手册里规定，权限校验必须调用统一的Auth服务接口，并用枚举值代替ID。我当时花了一周时间，带头把好几个模块的硬编码替换成了枚举调用。
这种身体力行的做法，效果立竿见影。大家看到我这个领导都这么较真，也就慢慢收敛了作风。过了两个月，代码质量明显提升，新进来的同事上手也快多了，因为“法”摆在那儿了，照着做就行，不用猜。
正身就是领导带头遵守规矩，做个表率，让自己的行为合乎标准。明法就是把团队的规矩白纸黑字写下来，让大家都知道该怎么做，标准在哪儿。这两者结合起来，团队的战斗力才能真正提升起来，做事才能既快又稳，不留后患。
