对团队规范和技术的几点总结

优速盾-小U • 2024年10月6日 18:41 • 行业资讯 • 阅读 80

这两天团队要做项目总结，所以个人就浅薄的作了几点总结，当然，是从团队研发人员的角度去出发，因为团队的研发人员是基石，是铸造项目和产品的核心，产品的质量完全由研发人员来决定的，而市场唯一认可的是产品。

可维护，可插拔，可伸缩的代码是个人以及团队可持续良性发展的基石，一个不注重技术，不注重规范的团队终将被现实狠狠打脸。

避免破窗效应

不做破窗的第一人，在软件开发过程中，我们一定不要去做破窗的第一人，在西安项目中，由于团队开发人员迭代了几批，加上工期紧，所以代码可以说不是那么美观，导致这个问题的根本原因是从功能的初期就没有做好规约，团队成员没有按照那个规范去执行，后面随着代码的堆积，已经无法重构，代码极度耦合，后面的同学想去重构发现工作量很大，风险很大，想要去适配，发现效率又不高，最终，他也只能妥协，在盘根错节的代码中继续加判断，所以最后代码就变得像印度的电网。

如果团队成员都严格律己，加上相互提醒，监控，没有人去做破窗的第一人，那么我们的项目交付时间，项目维护成本等将会缩短很多。

规范权限管理

一个权限不规范的团队暴雷是早晚的事，即使不暴雷，那么途中一定会遇到大大小小的问题，权限包括服务器权限，数据库权限，各种文档权限和各种中间件的访问权限等等。应该根据开发人员的职责给他划分权限，而不是不管是谁，直接给你root上去，开发，测试，生产服务器随便等，数据库随便登，这样是不专业，也是风险很大的操作。

比如数据库，根据业务来，只给开发人员分配那几张表的增删改查等权限，而不要全部开发，这样就会避免很多误操作带来的损失，再比如各种种中间件的权限，如果管理不到位，那么会造成严重的损失，之前我们就因为nacos的管理不到位而导致配置文件被删除，导致服务全不可用，这些都是血泪的教训。

技术氛围

特别对于交付型项目来说，说工匠精神可能会比较扯，因为团队成员水平参差不齐，有热爱技术的，也有纯属为了生活的，当然，我们每个人都是为了生活，但是我觉得编码应该有思考，而并非堆上去，实现功能，换句话说，我更愿意说，“从繁琐的生活中刨解出一点理想主义”，写出美观，健壮的代码是一个过程，这个过程需要不断学习，不断总结，而一个人是需要成长的，而在团队中，我们就要注重技术氛围，多讨论，对成员的代码作点评，这样，不仅让代码整理比较健康，另一方面也培养了成员，对后续的开发打下基础，另外，一个团队的技术氛围会在很在程度上决定这个团队的稳定性。

上面就列举了几个部分来说，也是在团队中总结出来的，当然，还有很多影响团队的发展和项目的交付的因素，后续再进行一些总结，当然，因为我的经验不是很足，在团队里面只是一颗螺丝钉，但是我觉得无论是谁，在团队中都是十分重要的，都应该将自己的能力毫不保留的发挥出来。