第二十章 第一次团队合作与猪队友（2 / 5）

已经沉了下来，他有些不耐烦地用马克笔敲了敲白板：“我们现在是在做一个简易的、原型的核心模块，不是要开一个商用的、承受百万级并的系统！

你说的那些东西，复杂度远项目要求，两周根本实现不了！”

“但这是正确的方向！”

陈飞坚持道，“我们不能为了赶进度而牺牲代码的质量和系统的健壮性！”

眼看讨论要陷入僵局，林小圈只好站出来打圆场：“好了好了，这样吧，架构大体按周博瀚的思路来，陈飞你重点关注判题逻辑和沙盒安全性的设计，我们先实现基础功能，如果时间允许，再考虑优化安全部分，怎么样？”

最终，在一种略显压抑的气氛中，三人勉强达成了初步分工：周博瀚负责整体架构搭建和用户交互模块；林小圈负责判题逻辑的核心实现和数据库设计；陈飞负责研究安全的代码运行沙盒方案，并协助设计核心判题算法。

分歧，从这一刻就已经埋下。

项目在磕磕绊绊中推进。

他们使用了git进行版本控制，这本来是协作的利器，却成了矛盾的放大器。

周博瀚效率极高，很快搭好了基础框架，并实现了用户提交代码的接口。

他习惯小步快跑，频繁提交。

林小圈也稳步推进，开始编写判题逻辑，针对不同的编程语言设计测试用例。

而陈飞，则彻底沉浸在了他的“完美沙盒”

研究中。

他查阅了大量英文文献，尝试编译各种底层库，在本地虚拟机里反复测试。

几天过去了，他除了提交了几篇相关的论文链接到项目91iki外，代码库里的贡献几乎为零。

第一次冲突爆在项目开始后的第五天。

周博瀚在合并林小圈提交的判题逻辑时，现与他自己刚写的用户状态更新模块产生了冲突。

“林小圈，你修改judr类的接口为什么不事先说一声？”

周博瀚在小组的即时通讯群里质问，语气带着不满。

林小圈一愣，解释道：“我加了两个参数是为了传递更详细的编译错误信息，我觉得这样更合理，当时你在忙架构，我就直接改了。”

“但你没通知我！

我这边调用的接口全错了！”

周博瀚过来一个崩溃的表情。

“我提交的时候写了注释啊……”

“谁会每次都仔细看diff（代码差异）？这种公共接口变动，至少要在群里说一声吧？”

两人在群里争执了几句，气氛有些僵硬。

而陈飞，自始至终没有在群里说一句话，仿佛消失了一般。

林小圈心里有些委屈，也觉得周博瀚有些过于严苛，但他知道周博瀚说得有道理。

团队合作，沟通确实至关重要。

他主动道了歉，并约定以后涉及公共模块的修改，必须提前在群里报备。

然而，更大的麻烦来自陈飞。

距离项目截止只剩四天了，陈飞终于提交了他的第一份代码——一个极其复杂、依赖了大量外部库的沙盒实现雏形。

周博瀚和林小圈尝试集成，现光是环境配置就极其繁琐，而且与周博瀚搭建的现有架构格格不入，甚至因为引入的库版本冲突，导致整个项目都无法编译通过了。

周博瀚的怒火终于爆了。

他在活动室里，当着不少队员的面，直接对陈飞低吼道：“陈飞！

你搞出来的这是什么玩意儿？项目要求是简易核心模块！

你看看你引入了多少不必要的依赖？架构完全被你打乱了！

你这几天到底在干什么？”

陈飞的脸一下子涨红了，他梗着脖子，声音因为激动而有些颤：“我在实现一个安全的沙盒！

这是判题系统的基础！

你们那种简单的d0bsp;