... | ... | @@ -19,7 +19,7 @@ |
|
|
为了应对这些变化,我觉得开发团队方面,我觉得一定要集中优势力量,采取小步快跑的策略。主要是以下方面:
|
|
|
1. 开发人员集中起来,所有人理解所有要做的业务,然后共同来完成设计和编码。
|
|
|
1. 做新功能,在现有系统的基础上。
|
|
|
1. 在做新功能的时候,不断优化原有的设计,比如把一些数据库表从主库中剥离。
|
|
|
1. 在做新功能的时候,不断优化原有的设计,比如把一些数据库表从主库中剥离,逐步优化技术栈等。
|
|
|
1. 充分利用事件(mq)进行解耦。把服务间的耦合度降低。
|
|
|
1. 逐渐把核心系统与辅助系统融合起来(不是变成一个大单体服务),比如实现统一登录、增加门户等,避免碎片化。
|
|
|
1. 逐渐把核心系统拆分出更多的外围服务,形成有机的服务体系。减少核心系统的复杂性,提高扩展性。
|
... | ... | @@ -52,6 +52,17 @@ |
|
|
# 团队建设
|
|
|
|
|
|
## 现状
|
|
|
目前开发团队人员很少,而且比较分散。不同的系统由不同的人员开发和维护,没有人能了解所有系统。使用的技术栈也各有不同。人员分散在各地,开发任务分配也不均衡,造成关键人员特别繁忙。
|
|
|
|
|
|
## 分析
|
|
|
多地开发人员不能经常见面,而且工作也都是分开的,然后开发人员之间也不进行技术方面的交流,所以形成了天然的鸿沟。
|
|
|
|
|
|
## 思路
|
|
|
1. 固定的时间进行技术交流,让开发人员能够进行交流,使每个人能比较容易理解别人的代码和想法。
|
|
|
1. 打破项目的界限,所有开发人员对所有服务都可以进行开发,而不是只有某个人才能开发或者维护某个服务。
|
|
|
1. gitlab开启同行评审,使代码在团队中有一个相对一直的看法。提高代码规范程度。
|
|
|
1. 招聘相关的人员,补齐团队的短板,努力提高工作效率。
|
|
|
|
|
|
# 总结
|
|
|
我觉得现阶段我们有很多想干的事情,但是却干不了,主要是因为团队不完善,人员少,任务多,但是如果解决了目前的问题,还会遇到更多的问题,所以需要按照上面的思路,做好各方面的准备,才能更好的完成以后的工作。
|
|
|
|