Java课程设计（基于JavaMail的C/S模式邮件客户端）总结

一直以来自己的文笔都很cheap，技术也很菜，所以注册CSDN半年多了，我从未在博客上发表过任何文章。上周刚刚结束了为期一个多月的Java课程设计。仔细想想，我觉得有必要好好总结一下了。况且，我总不能让自己的文笔一直cheap下去，技术一直菜下去吧？（至少要没那么cheap，没那么菜）

既然是课程设计，当然会有leader和teamate，我只是负责整个project的mail机能。下面是我对这次课程设计的一些总结和感悟，纯属个人看法，难免存在一些个人偏见。

项目开发前期的系统设计与分析至关重要。我想，这一点是我们小组这次课程设计最大的一个不足之处吧。由于整个project的规模和复杂性都不小，所以模块划分、接口定义、数据分析和进度安排等显得更为关键。而这些都应该在项目开发前期作好充分准备的。我们小组最终没能把所有模块整合在一起，一个很大的因素就在于接口定义没设计好。而项目主干部分也因为时间进度没把握好，直到作业交付时也没能够如期完成。不过，这些都与我们自身缺乏项目经验有关。在此，引用我们SE老师的一句话，“软件工程本身是一个实践性很强的学科。”

团队交流需要贯穿整个项目开发过程。在我们的project中，包括技术组和非技术组（暂且这么叫吧）。技术组即编码的4人里面，2人负责架构与核心模块，另外2人负责各自的功能模块。一个多月开发下来，编码的这三parts之间基本上零交流，至少我个人负责的这一part与小组是彻底分离出来的，技术上没有任何讨论和交流。这样的后果就是，当你查API未果，google、百度未解，论坛提问没人理时，你会多恨自己没能力“自力更生”，也切身体会到什么叫“孤独无助”。此外，这也是导致项目最终无法整合（或难以整合）的原因之一。设想一下，如果在开发过程中，leader与队员之间、队员与队员之间能够保持密切联系和交流，项目的每一part都会尽可能地向项目整体设计靠拢，因为在直接或间接的提醒下，coder在开发时才不会完全地抛开系统的整体性而“一意孤行”。

时刻保持对模块架构设计的清晰把握，防止对逐渐增长的代码量失控。所谓的失控，是指所编写的代码失去易分析性、灵活性、可复用性、可维护性等优秀代码质量的性质。关于mail机能，最基本的功能莫过于邮件的收发。相应地，重点和难点就在于消息封装和邮件解析，最后再设计一系列UI与用户进行交互。设计思路就是这样简单明了。但是，随着类的增加，构造器和方法参数的设计就变得尤为重要，类与类之间的关系就变得越来越复杂。整个邮件程序写了大概20几个类，2500行左右代码，到最后一段时间编码时感觉就像是在做“面向过程”的开发，那个“object-oriented”的概念估计战斗力不足，只能先撤离了。因此，就算不考虑一些客观原因，设计出来的邮件收发系统的效用性也很低。不过幸好只是课程设计，重要的是学习过程。

对于初学者来说，不应该过分依赖IDE或自动化工具。为了方便叙述，这里就只围绕其中一方面来说——很多人都知道，netbeans的可视化编程是相对于eclipse的一大亮点。使用netbeans编写界面程序时，开发者可以像在图纸上绘图一样直接设计控件，而系统会自动生成相应的代码。貌似这让不少对界面设计与实现抓狂的童鞋进行开发时变得游刃有余。但是，在方便、快捷、高效的背后，却是一个最佳学习和实践良机的错失。上学期刚学了Java，这里的“学”是指课程教学，而实际上是自学（因为基本没听过课）。像GUI这些基础知识，我是通过开发一个含字处理功能的程序时边学边用的，而这次课程设计又加深了GUI方面知识的掌握。不可否认，IDE和自动化工具大大降低了软件企业的开发成本，也在一定程度上提高了项目系统的性能。而对于初学者，我觉得有必要尽可能地去了解每一个细节的实现，因为只有这样，才能更好地适应各种开发平台，并通过较好地把握细节来设计整体。何况，作为coder，首先需要作为创造者“造纸”，仅仅作为使用者“绘图”的，应该是painter。

虽然到作业交付时整个project还不尽人意，但我觉得我们小组是“形散而神不散”，直到最后时刻都没有放弃。感谢我们的leader和每一位teammate，在此共勉。