https://mp.weixin.qq.com/s/LytUQfeEKf-YdqennDyZ1Q
文 | Highway
腾讯互动娱乐 后台开发
笔者目前的团队研发力量有3名客户端开发以及两名后台开发，再加一名外包的管理端开发同学。目前客户端仅需要支持安卓版本。大概一个月一个版本的研发节奏。其中，2个星期的研发时间 + 1个星期的bug 修复+ 1个星期的需求优化等。
技术选型：
小团队的本身力量小，要懂得利用社区或者公司的力量，因此在技术选型上应该向生态更好，维护力量更强，社区发展更蓬勃的语言和技术上靠齐。
这样，在出现问题的时候，就不会花费大量时间在各种网站上寻找解决方案，甚至需要自己研究源代码，修改源代码的情况。
以笔者的项目而言，继承于合并前的两大部门的历史产物，包含mcp,lua,php,swoole,go等语言，而在部门产生变动之后，小团队已经无法维护这么多技术栈，因此对不需要变动的服务维持，对需要长期迭代的服务则用go语言进行重构，对服务也用go语言进行编写。
他山之石，可以攻玉。小团队更应该将更多的力量聚焦在业务的实际开发，而不是在框架上，工具上重复造轮子。
大系统小做，小系统大做
在小团队里，很容易有惯性思维，以自己小或者时机不成熟为由，将业务冗杂在一起。他们以为有时间可以以后慢慢拆分，但是往往就是最后想拆的时候，发现已经无法进行拆分。
服务拆分，应该是服务设计的时候就必须做的事情。它要求开发者高瞻远瞩，暂时的维护工作量，带来的是将来无穷的方便和可复用性和可拓展性。
现在慢一些，是为了以后跑的更快一些。
另外系统拆分，对于系统的稳健性大有好处，不会遇到牵一发动全身的灾难。
完善的devops流程
得益于蓝盾的发展，开发/编译/部署 一站式流水线成为了可能。这将大大减轻开发人员在环境部署上花费的时间，自动化将开发代码运行在测试环境。
同时蓝盾上集成的代码扫描功能，结合质量红线，可以帮助开发者评估代码质量，形成统一风格的代码和优秀的编码习惯，使得代码的可读性和可维护性大大加强。
完善的mock机制
由于客户端和后台往往是并行开发，非并行开发容易导致多余的沟通和联调成本。
因此，在需求确认之后，就开启技术设计沟通会，会议会拆解协议，同时约束好名词约束，定好协议规范。
后台利用yapi 制作mock server，将所有约定的接口进行mock。
在并行开发期间，后台按照约束的数据实现，客户端按照mock server 定的协议开发。后台开发完成之后，检查协议返回数据一致即可完美匹配。
优秀的rpc通信机制
既然服务已经拆分为小服务，那么服务之间的通信就是通过rpc来进行，利用grpc等通信机制，可以通过约束协议，自动生成客户端代码，方便调用者调用，减少沟通联调成本。服务之间调用变成开箱即用的行为，而grpc等还有http2等优化行为，提高了调用效率。
良好的代码管理习惯
一般可以按照主分支，dev分支，每个开发人员一个开发分支的开发行为进行管理。也可以按照MR的方式进行管理。在笔者的项目里，采用了MR的方式，主要是工蜂将MR和CR进行了整合。方便互相进行代码检查。
坚持做系统设计文档
不能因为人少就摒弃了软件工程的重要环节。系统设计文档不仅是认识系统的说明书，也是系统迭代的重要指导书。
坚持写系统设计文档，也是为了晋级答辩准备材料，系统设计文档将系统里可能遇到的问题，瓶颈，分析论证，可以很方便的抽象系统。为以后做类似的系统提供思路。
系统的容量和数据量的分析，也是系统扩容的重要依据。
以上总结的几点思路是本人在带领和参与小团队研发过程的一点思考，大部分都属于公共知识，践行这些原则会浪费一些时间，但确实是一件投资未来的事情。
坚持做效率敏捷的优化，可以保持小步快跑，个人的工作效率和自我提升的时间也会越来越多。
对于自己和团队这都是双赢的事情。
