初创型公司技术单系统的痛点和建议

很多初创型的公司，项目沉淀了1-2年，还是单系统架构(一个项目一个数据库一个缓存库)，3、5个人时是一个很正常的状态也不会有什么大的问题，业务迭代可以非常快速，但随着公司的发展业务迭代速度加快，技术团队的人数规模增加，代码库和数据库的内容越来越多，各种问题逐一暴露出来。

1. 每次的修改可能都伴随着各个功能块的回归测试，开发成本越来越大。
2. 代码的改动，没有覆盖到的面越来越多，导致上线后出问题的概率剧增。
3. 重复造轮子的情况越来越多，导致更改某个逻辑会连带修改N处地方，导致上面2个问题。
4. 某个业务写了一个慢查询，导致整个应用崩溃。
5. 谁又动了我的代码
6. 排查线上问题的成本越来越高
7. 代码库大小已经好几个G了
8. …

很多人会想到解决的方案就是服务的拆分才能根本性的解决上述痛点，这点我非常认同，但本文并不想扩展服务拆分这个话题，更多的是讨论如何在当下的团队结构中能尽量的避免这些问题，使公司还能持续不断的发展，为技术部未来的服务拆分做好准备。
另一个原因是服务拆分是需要一个过程的，并且很重要的一点是需要投入人力和金钱来做，并不是所有的公司都能鼓起勇气现在就干，可能这样的情况还是得持续很久。

建议

.保障开发人员的组织架构是属于技术部的
程序员的直属上级是业务部门的，那你就很难约束他

.分清楚每位开发人员的职责，模块罗列清晰，同步到每个人
相信这一点技术团队天然就具备，但也有灰色地带，你需要的是强调并同步到每一个人，特别对测试和产品人员来说，这就是了解并解决问题的指南。

.功能迭代开发时谁负责的模块谁来开发
模块划分清楚了，为的就是更好的管理代码，请严格按照谁的模块谁提供开发，举例来说，比如A程序员负责用户模块，现在要在用户基础信息里新增“订单花费总额”的信息，而订单模块是B程序员负责的，请找到B程序员让他提供类方法，而不是你直接在代码里调用订单信息得出结果。这里可能会碰到如果这个时候B程序员也在开发另一个功能模块没有时间的情况，你有两种选择：1.等待 2.让B程序员给出方案，A程序员来编写。

制定好团队的技术规范(代码、SQL语句)
每个人都有自己的代码风格，但很多规则还是需要遵守的，所有你必须出一份你审视过并大家认可的规范，并严格执行。其实每个团队都有技术规范，但很多都是摆设，过一段时间就不了了知，所以要有效的执行规范必须配合下面的codereview.

团队定期codereview
一定要做，他能提升你团队的整体能力，最关键的是保证代码规范有效推广的,尽量保证1-2周一次，每人轮流的形式，讲解你负责开发的代码和思路。

定义好项目内的层级目录结构
根据你当前的项目规划好你的代码应该放在那里，什么时候建立新的目录，是否需要再加一层结构，即使当前的结构并不合理但也请定义好这个标准。不要怕无法执行标准，你有codereview。

上线前必须审核新增的表结构变更
如果你的表结构还没管理起来，那就赶紧管理，当前你应该收紧sql权限，并和发布sql语句的工程师达成非常一致的要求标准。

慢查询需要长期和它斗争
1.记录慢sql，定期导出并优化，但你有可能忘记，最好做成每周自动化导出。
2.结合“审核表结构”的原则，尽量把索引建立在建表时，做好审核工作多问问为什么不建立或者建立索引
3.部分预计很难优化的很完美，如果你的主库压力大，可以考虑建个从库分担一些主库压力
4.避免连表查询，说来容易，但你不强调更无法控制
5.如果真的出现慢查询还是要有惩罚机制，如果一位程序员在你做了这么多管理动作还是重复犯，那我只能说他能力真的不行。

有目标的抽离你的基础代码，建立属于你团队的公共组建库
这一步是你对未来的计划，你需要从团队内找出这样的人来做这件事情，这是一个长期的工作，在技术团队发展的过程中一定会有属于你们自己的沉淀，也是未来你做服务拆解的前置工作之一。多想一想，列一列，一定能找出来。

根据实际业务考虑先把可独立的项目独立出你现有的库
这是要求你有意识的服务化思维，新的功能或者比较独立的模块是否可以独立出来，它的成本是否可以承受，可以先从非核心模块开始做，服务化最大的好处就是自治，在做的过程中你会面临很多的困难，你会遇到系统和系统之前各种异常问题，你的程序员们思维可能还停留在当下单系统的模式里，这些都需要去克服和提升。
（个人观点微服务才是技术架构的终局，你要往这个方向靠。当下可能确实离的很远，但方向对了，你终有一天到达。）

团队要有绩效考核
没有绩效考核你是很难推行这些制度和流程的，他是根，只有根扎实了，团队才能茁壮成长。关于绩效考核的规则，其实你不用太费脑力去自己制定一套，现在互联网公司的绩效考核这么多，你只要拿来用就可，绩效最大的难度还是在于执行两字。

坚持并持续的监督执行
任何事情都是需要持续不断的重复重复再重复才能形成好的习惯和意识，定制规则很容易，但是长久一贯的执行才是最关键的。

就写到这吧，在写每一项的时候思绪都会发散，有很多的东西想写进去，但又感觉没组织好，所以只能点到为止。每个技术团队在发展的过程中都会遇到这样那样的问题，你需要面对这些问题，并且要有方向，只要往好的方向走，大家是能感觉到的，始终记住一个原则，制定的这些条条框框最终是有利于大家的，这是最最重要的。