清晨，一缕阳光射入眼帘，张开眼，习惯性地环视四周，依然很熟悉，但是很陌生，这不是我的家，每周末该在的地方。

在韩国的时候并不怎么想家，因为知道再怎么想也不可能轻易地回来，然而如今家只在咫尺之边，仿佛就在自己的眼前，心中不免泛然，一种孤独，一种寂寞。

学校，绿柳成荫；

实验室，电线盘绕；

寝室，电脑为伴；

自习室，宁静独处；

闭目，尽皆虚幻；

睁眼，依然前行；

未来，雾里看花；

一切，没有终点。

昨天收到多智能车辆合流分流仿真平台的方案书，其中明确写着是“基于VB”，不免很是郁闷。

VB作为一门编程语言，因编写简单而受到青睐，但是对于这样的仿真平台，特别是考虑到如果最后要将几个人的工作整合，并非面向对象的VB显然不合适。小车的定义需要很多变量，还包括其他的车队、道路等等，难道全要用面向过程的语言零零散散地给出？那项目再复杂一些呢？又必须推倒重来，毫无可扩展性可言。我觉得对于这种问题，决不能以简单的因为VB简单而搪塞。这种“简单”的结果极有可能增加最终平台的复杂性，那么我们建立仿真平台就失去了其意义。毕竟平台的建立，就是为了为智能车多车协作的模拟提供方便。所以，工具的出现，简化了人们的工作、生活，但是这种“简化”，说的应该是工具与人的交互、它的实际运用效果，而不该理解为工具本身构成的简单化，事实上，如今日常应用频繁的电脑等工具，其本身的设计构造是极端复杂的。

另一个使用VB的理由则更滑稽，因为我们是团队协作，所以要照顾到团队其他成员，统一使用VB。且不说我们团队中4人中有两人会java，且另两人早已学过C，再学java根本不需多少时间（更何况我就不信我们中有谁不需要花时间再熟悉一下VB就能直接上手），就是学java需要一定时间，相对于项目来说，这些时间也是值得的。在这个项目中同样存在着木桶原理，如果我们不把这最短的一块板补上，那么这个桶永远盛不了更多的水。

所谓团队，应该是每一个人为此添砖加瓦的集体，每个人都是团队的主人，应该为此而不惜心力。而我们现在却只注重“集体”这个观念，一位地强求整个团队的“统一”，硬是迁就团队中个人的局限性，牺牲整个团队的效率，我认为是不可取的。一个人不会是万能的，不懂不会不要紧，但是心安理得地让团队迁就你，而不思进取，其本质就是团队责任心的缺失。