项目总结——项目方法

转载自：http://blog.csdn.net/u012333003/article/details/21317541

-----------------------------------------------------------------------------

一、背景

做了好几个项目了，但一直没静下心来总结自己，或是做项目的方法也好，或是做项目中碰到的问题也好，或是做项目中碰到的技术也好，我觉得都应该拿出来好好反思下。前阵子，看了下设计模式。以前不懂设计模式，但发现自己在项目中已经不知不觉用到了不少设计模式，可能有瑕疵，并不完善，但终究是解决了问题，如果我早知道这些概念和方法，那么在碰到问题时是不是更得心应手呢，好在开始总结经验，若是只为做项目而做项目，做完了不了了之，学完了也不了了之，那么永远难以得到提高。

-----------------------------------------------------------------------------

二、漫谈做事的方式

1.如何提高做事的效率

每天大早来到实验室，大晚回去，一闭眼一睡觉了事，要是不知道自己做过什么或者已经完成了什么，那是纯粹是熬掉时光，剩下残渣。对于一个项目来说也是如此，每往前跌代一步，大多应在计划之中，若是逃出意料之外亦有应对措施。

整个项目老板负责硬件，我负责软件，项目的主题是围绕改造材料学院一台高性能精密测量仪器，用于碳纤维性能测试，原设备据说很贵，即便是用老设备去换也还得花费六七万，而目前他们买的一台日产的辅助测量设备已经花费十来万，而测试结果并不理想。简单说来，我们就是要做这么个东西：把我们的硬件和软件做成一个系统，用于改造设备提高测试性能。具体细节不宜透露过多，你懂的，倒是我更愿意分享下目前我对做项目的方法和涉及的技术，因为这是完全自己的，即便他们付过钱，但还没为讨论这些方法和我对项目的认识付钱，不说完整的工程，分享代码片段总还是可以的吧。

关于如何提高做事效率，一个人的或许好办，个人能力突出，做事踏实专心便可，但对于一个团队完成任务，涉及任务分工和团队合作协调，可不像一个人在战斗那么简单。显然项目进度是并行执行的，但又去各自完成被分配的任务，而各任务之间又有千丝万缕的联系，比如说这里的软硬件协调，我们不能等软件出来了再去设计硬件，也不能把硬件先完成再是做软件，或许依次进行也是可以的，但我们要得是效率，整个任务应该并行完成，即当其中任何一个子部分完成时，另外一部分也应该差不多了。

老师最精明的部分是先构思，定好底层协议，通过协议把软硬件分开，如此我们便可以分头行事，但有一点，我们都遵守约定，一切按约定行事，完成后在指定地点汇合，若是各忙各的，则会各自失散。所以一开始通过指定可行的协议把大事情分成小事情这是最重要和关键的。

2.如何保证做事的有效性

通常我们拿到一个事就下手，类似于考试，至少我很久以前是这样子的，关于高考看到题目就动手，因为要抓紧时间。但做项目不是这样子的。如果你碰到问题就急于下手画电路编代码，那么你会陷入死循环，最终因内存耗尽而使得整个项目终止，这不是件很好完的事情，一浪费你的时间，二你会一无所获，客户不会给你工资还会受老板批评。最有效的方式是你先构思，比如软件部分，我应该先撰写详细地文档，客户提出的要求，我应该尽量用行业的语言描述清楚，然后我的伙伴们还要能够看得明白，其中不断地和客户进行沟通，以保证我们完全理解他们的需求，这个阶段即所谓的需求分析吧。对需求分析理解透彻后，然后才是干自己专业的事，小组成员进行讨论，提出合理的解决方法，比如软件上，我们用什么开发环境，语言上选择C++，C#，Java还是Python，我们最后选择了Python，一方面它开源无需支付任何费用，二方面它跨平台，三方面它有很多库，一个人足以在同样是时间内作出比如Java，C++等四五个人的小团队才能干得事，当然还有许多别的原因，以前我们常用C#，这次把它抛弃了。数据库我们选择了MySQL，抛弃了原来的ACCESS，也有好多原因，跨平台，开源，良好的性能，或者我想在项目中尝试下新的东西这或许都是原因。GUI选择了Qt框架等等，这一系列决择都应该是小组经过讨论的结果，当然我这次是个人，不涉及和成员讨论，也无需和老板商量，老板不会关注我用什么语言什么数据库，作为上级，他关注的是看到正确的结果。

把上面这些事弄好之后，要开始写技术文档，描述清楚整个工程如何搭建。就像建筑，我们知道用混凝土，钢筋去这块地建一个18层的大楼了，合同也写了，供需也有了，材料也有了，现在最重要的事是绘工程图纸，哪个地方怎么建，哪个地方要注意什么，地基挖多深，柱子架多高，电梯的设置，消防系统的安排等等都是要考虑的事。软件构建中的异常处理，数据处理，交互界面等都有类似，大楼希望看起来美观实用安全，软件也希望看起了友好不出Bug，如此可谓优秀。所以在文档上你应该尽量描绘出你的整个构思框架，把任务模块细化。这样在具体编码时你就得心应手，而不是不知道自己要干嘛，只是在代码里翻来覆去，问题总是得不到解决，辗转难眠。

总之在合适的时候做合适的事情，不能急性子，也不能慢拖拉。许多人喜欢编程，碰到问题就编，没编成功就改，改完了又测，或许最后成功，但最好的办法是先想好再下手，就像打靶一样，你先瞄准目标再开枪。当然前提是你的编程基本功扎实，否则即便瞄准对象了也打不中靶心。但如果你不瞄准靶心，即便你编程功夫再牛逼也是徒劳。