小规模团队（5 人以下）代码管理问题

[god7d]

在小规模团队中，招聘开发的标准应该包含比如不少于 5 年工作经验、代码风格优雅、有一定架构经验等，这样可以保证每个成员都可以独立开发并且保证质量。一般来说，小团队对新手的容忍度较低，只有中型团队以上可以考虑培养新手。

团队开发工作一旦分工完成，成员所负责的代码部分应该不允许他人修改，除非是在得到了充分沟通和授权的情况下。如果其他成员发现其代码问题，应当指出并由该成员自主修改。在团队成员长期稳定的情况下，成员所负责的代码应该与该成员长期绑定，实现成员对代码“终身负责“和风格统一的问题。有的公司规模不小但是流动率超高，每个人都抱着最快完成任务而不在意代码质量的想法，导致项目可维护性极差，甚至无法维护，而重构的代价是比较大的。（不过对于这种公司来说他们的产品可能是一锤子买卖）

对于开发工程师来说，光速交付然后快速重构的模式可能是非常恼人的，因为这样会让人觉得疲惫，且开发过程中不慎愉悦。当然付钱的是老板，很多时候开发工程师并没有选择。不过在一些传统行业中，很多时候软件是具备充足的开发时间的，这时候选择精雕细琢显然是两全其美的事情。

[luomu24]

老实讲，这样的团队和薪资好招到匹配的目标成员吗？

[GP1]

不可能三角了解一下。

[qile1]

阿里的云效有没有用过，只是代码管理应该也省事

[jones2000]

@VictorJing94 金融，量化交易

[cepro]

主要看这 5 人团队是否从事的是同一个工种的工作。比如都是 Android 、都是 Web 前端、都是后端、都是数据分析等。
如果这 5 个人，各自独当一面，只能从人员角度去保证。
如果这 5 个人从事同一类工作，那就考验架构师是否能够解构模块，代码是否具有可读性。即使出现人员离职，最多也就是重构模块，相对来说工作量会小很多。
但无论是哪一种，开发过程的文档都是尽量留下来的，尤其是关键的逻辑和流程。
无论薪资高低，水平高低，人员管理总会有疏漏，关键是要能从你（假设你是管理者）这里，在可接受的时间范围内，把窟窿堵上。

[QKgf555H87Fp0cth]

一些 eslint ，代码风格修正的用下就可以。

[wu00]

@JellyDong 从官方文档中自己提炼
框架设计准则 https://docs.microsoft.com/zh-cn/dotnet/standard/design-guidelines
通用设计原则 https://docs.microsoft.com/zh-cn/dotnet/architecture/modern-web-apps-azure/architectural-principles#single-responsibility
清理非托管资源 https://docs.microsoft.com/zh-cn/dotnet/standard/garbage-collection/unmanaged
异常实践 https://docs.microsoft.com/zh-cn/dotnet/standard/exceptions/best-practices-for-exceptions