分享 说说多人协作遇到的坑

hjf_coding · 2018年07月20日 · 最后由 coderliu 回复于 2018年08月09日 · 1848 次阅读

多人协作的坑(一)

一个项目要想如期高效的完成 往往离不开多个人的协作,一旦涉及到多人协作,因为个人编码风格、水平的不同就会留下一些坑,这种情况如果在培训、和实施到位的情况下是可以避免的。下面就说说在遇到的坑和我的一些愚见。

统一标准编码风格

客观上来说,每个人的编码风格都不相同,怎么才能保证在同一个项目上代码的风格、可读性和质量呢?可行的办法就是由公司牵头做一个公司标准,强制大家学习、和使用。一个大牛必然有其特殊的风格 但是他们的风格可以帮助他们编写高质量、可读性好的代码。我认为这是一个 IT 从业者应该学习的。

统一的标准、风格意味着你写的代码别人都知道这是按照上面方式进行编辑的,小到可以从这个变量的命名知道你这个变量是用来做什么的 生命周期大体在什么范围,大到知道这个你的代码功能模块是怎么划分的。这样就大大减少了交流、和维护成本。

在项目上,从原则上来说自己开发的模块总是由自己来进行维护的,但是当你有急事的时候,代码也需要紧急维护,那么遵循标准编写的代码至少能让你找到你一个能帮你处理问题的人 否者就只能自己来处理。还有一种情况是,当你和别人模块交互的时候 要编写接口,没有一个统一的格式 你会频繁的询问别人 这个是什么意思,这个怎么没有反应。如果是这样,那么恭喜你 你一天可能会有一半的时间在处理这些问题,那么真正能解决问题的时间有多少,解决完问题之后还剩多少学习时间。这样下去你会讨厌这份工作,认为待下去迟早要废掉,但是如果你不遵循大家的标准,那么你离废掉就不远了。

数据更新

针对实例数据,不要直接调用系统提供的方法,数据的更新一定要通过别人提供的方法进行更新!

针对实例数据,不要直接调用系统提供的方法,数据的更新一定要通过别人提供的方法进行更新!

针对实例数据,不要直接调用系统提供的方法,数据的更新一定要通过别人提供的方法进行更新!

举个例子 在 rails 框架中 采用 MongoDB 数据库

Mongoid 提供了很多的更细方法去更新数据库的数据

A 模型更新 B 模型的数据但是 由于 A、B 模型分属不同的模块,由不同的人进行管理,这时候 在对 A 模型数据进行更新的时候采用 Mongoid 提供的方法 update_attributes 更新 B 模型的数据,好了 现在已经出现设计上的 bug 了 B 模型不是你管的 你怎么知道在更新 B 模型数据的时候有没有去更新其他模块的数据 你不知道对吧。

为了解决这种因为要同步不同模块数据的问题 我们应该采用的是消息或者同步调用接口的方式去进行数据的更新。 至于是采用消息的方式还是 接口的方式由具体的业务决定。考虑长期情况下 如果只有一个模块需要同步更新 没有理由去创建消息进行更新,虽然消息是个好东西,但是多了一层消息调用 就意味着出错的可能性多了一些。毕竟我们往往觉得别人写的代码是垃圾 手动滑稽

代码风格统一 是不希望了 就是一些东西还是遵从一个标准好阅读一点 为什么我特别支持选用接口和消息的方式去更新呢 很大一部分取决于系统架构 采用微服务的架构 通过消息解耦模块 各个模块之间可以单独更新而不影响其他模块 但是实施起来要求技术成本有点高

update_attributes 不是消息?不是接口?

hooopo 回复

update_attributes 只算是实例方法 我觉得让别人来调用你的实例方法是不安全的 这个方法还可以写 并不是只读方法 只读方法 随便调无所谓 单一涉及到写操作 就会出现一些问题 两个系统之间 相互更新的用实例方法就不可控了

然后写着写着 自定义的更新方法 的逻辑就和一个 controller action 差不多了

需要 登录 后方可回复, 如果你还没有账号请 注册新账号