15 人左右的公司，都是开发无专门的测试岗。
目前遇到问题为，主产品在迎接 新需求或者变化的时候，如何难以保证代码不被误修改 （目前无严格的 PR ，每次提交的文件太多了，审核的人看不过来）。本身大的是一个产品，业务发展接入的三方多，中间件加入的多，导致代码仓库一团大便。
想通过下述的方式自上而下依次区分，请大家看下哪里考虑不周到：
1. 仓库
根据微服务的逻辑，每个服务对应一个仓库。尽量抽离出各个项目公用的模块为仓库，确保开发只能查看和修改自己权限内的模块。
缺陷：仓库多了太难找，分散多了可能又需要有个文档集中记录说明下。
2. maven 的模块
在上述逻辑内，根据业务分为不同的业务。项目有时需要根据客户的需求进行本地化部署，不需要的功能方便及时摘取。
3. java 的 package
每次新提的需求尽量在一个 java 的包内，然后再分别有 controller 和 service 之类的信息。review 的时候确认都在同一个包内。即使写的是烂代码，也在一定范围内。当修改功能涉及其他 package 时，在通过设计模式对原代码修改开放。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.