一次合作的思考

来源网络
  • 关于小组分工:

如何协调各成员间的分工,如何高效而准确地推进项目完成,是一件困难的事情,在一开始做的时候,我们在 一次性将个人的分工分好方面犹豫了好久,最后发现我们对于所做的事情,并没有足够的全局统筹观点,换言之,我们难以将项目分工分的完善,于是最后我们转向了就眼前一步步面临的问题,一步步共同推进,期间常出现分工不明确,导致两组人在干同一样事情,给后边的整合带来了极大的麻烦。

在小组合作中, 每个人对于“将要实现的功能”理解有偏差,落在软件编程中,则是出现代码逻辑不同,代码变量命名不同,导致阅读中出现极大的困难。

同时,在合作中,因分工不细致和个人因素导致小组成员常常力图以自己的方式优化,实现某项功能,但这样实际的结果往往是同其他人不合拍,或者将团队合作演变成了几位关键人物的独自编程,一个人的力量终究有限,在本次实习中,时间和前期准备是不允许我们这样以个人的方式独立编程的,而在更进一步的社会高效团队合作中,更是不可取的,故如何让每一位团队成员记住“自身”团队一份子的身份,在团队合作中是重要的。

此外,由于团队合作中,面临项目带来的压力,每个人接受其他团队成员的失误,或者因不理解其他团队成员的想法而觉得他人做的不对等等埋怨的情绪往往在团队之中发酵,造成团队合作中的不愉快,这于项目而言,是不利的;同样,于个人而言,也是不利的。如何接受,理解团队中的其他成员,每位团队成员都需要认真思考,但注意,对于这种问题,我们也不能单纯从自身找原因,同时我们要去发现团队中的缺陷,人及环境的思考并举。

  • 关于程序调试 Debug

理想的程序(项目)测试是什么呢?那肯定是项目按照我们的设想,每次的测试都正确地验证了我们当前的想法,从而使得项目可以朝着下一步前进,但这种直线型的,有因必果的理想情形,在现实这种不能考虑到全部因素的情况下,是很难发生的,程序的调试,往往是走在一条bug满路的荆棘丛中。在这时,如何去调试程序,如何设计测试方法,就变得尤为重要, 程序的debug,如同医生手中的听诊器,电子工程师手中的频谱分析仪,当debug落入一行行,这种程序中最微小的执行单元时,一个个单元的执行,我们便可以很容易地发现错误。在本次实习中,在课程中,关于测试的教程并没有涉及,这方面的知识个人认为不可或缺的一部分,这对于高级的编程人员是重要的,这更对新手人员是重要的。但如果将 测试debug拉入教程,同样存在着问题,随着现代电子信息技术快速进步, 代码测试 与实际功能的效果差距越来越大,我们可以想见,在早期编程时,测试就是编程,编程就是在测试,而现在的编程则是在若干测试的正确结果上,进一步地推演,当编程出错,其犯错的原因便要从其若干 默认正确的测试结果基础中抽丝剥茧。 我们现在看到了编程实现的功能很强大,我们萌发了学习这种知识的兴趣,而要让我们从测试学起,而与实际的效果差之深远,这无疑会影响到学习的积极性,反之,解决问题的兴趣,或许可以促使我们主动思考如何测试程序,由此看,测试这块不教也是有一定的道理的。举个例子,两位骑士站在草地上,一个抬头看见了城堡顶端的公主在向他挥手,一个低头看见了通往城堡道路上的险象丛生,一个前进了,一个放弃了,想来就是这个道理。

  • 关于知识检索及解决问题

本次项目中,我遇到了许多的问题,大多经由百度,查阅网上资料得解,但对于当时的问题及具体的解决方案,缺乏很好的记录及总结,导致的结果是什么呢?想来在下一次遇到同样的问题时,会出现没有思路,或者有思路,却是需要循着旧路,再次查找。

有人说,这是你当时不认真考虑,解决了问题而没有停一停想一想导致的,我看不尽然,当下大数据时代,问题解答层出不穷,一个人所能记下的内容岂能是几本书呢?我们应掌握是一种快速而方便的记忆方法,没有文字时,是用绳子打结;有了文字,是书籍;现在有了bit,GB,那当然是利用电子化存储,我们应将我们的所学所知,快速记录在内存中,以便于下一次重复问题出现,快速调用即可,这无疑是解决问题的高效途径,这样,有人又会说,这样不就像是一个机器人?做着抄写的工具人,不经过脑子,没什么用。我看不是这样,人的思考应该更高一级别,快速的数据,更多的知识,将更进一步提高人的认识,而人是有惰性的,往往希望以已有的知识,来解决所有的问题,所以想把东西记下来当自己的一法行万事的法宝。但在当下的时代,不断更新更重要的知识,是令人费事的,却才是最重要的。Emmm,好像扯远了,总之啊,对于接连面对的问题,欲有收获,我们应抽出一些额外的时间,将之压缩整理,存储它们到一个地方,更新我们的思路索引,时刻为将来做准备,这要克服惰性。

回归到本项目,则是应对遇到的问题予以记录整理,我在实习中仅仅是存储了其链接在云空间中,而这次的总结才是最重要的。