MBlog项目经验总结(一)

跌跌撞撞的总算是把这个所谓的微博的服务器端给捣腾了起来，发现自己 堆起来的东西是如此的丑陋和脆弱，有必要总结一下。

 

一. 项目简介:建立一个CS结构的微博（手机端 PC端） 主要功能：以书会友 以友找书 以及跟之有关的各种小功能

二. 我的工作:服务器端的工作，其实也就是与客户端的交互，大白话就是客户端要什么我给什么,只不过是以XML的形式给出

三. 用（学）到的相关技术：TOMCAT连接池的配置,servlet,DOM4J (说出来真是汗颜，整天起早摸黑的工作就是学会了这点东西,真是人间悲剧)

四. 经验:

1. 不怕:再接实验室的项目的时候不用怕，硬着头皮上，问题总会解决的，刚开始的时候不也是什么都不知道，然后在刘老师和方师兄的帮助扶持和督促下，不也能出点什么东西了嘛

2. 不挑:对于自己现在来说，学什么都行，自己都会有收获。虽然J2EE方面的工作经常被实验室的师兄鄙视，但是要是想做的很专业，也是很难。最尴尬的事情是这样的东西依旧写的依旧很是丑陋。

五.教训：

     在做一个项目之前，一定要把你要做什么想清楚要做的是什么，和自己的组员商量这个东西，把这个东西想透，想清楚，自己做的东西的核心竞争力是什么，中心功能是什么，并且有一个中长期的规划。

     做服务器端，首先要与客户端商量好接口。接口定下来之后，跟客户端就可以分离工作了，但是也应该随时的与客户端的同志进行交互。因为底层的服务器端应该尽量的稳定，不应该三天两头的改变结构。

      然后定期对工程进行备份和文档编写工作，这个工作很重要。要把文档写清楚，实现的功能，欠缺的部分，做项目的时候就养成写文档（或者是注释 ）的习惯。我现在做到这个时候就觉得自己已经控制不住这些代码了，觉得很是混乱，虽然能做，但是以后维护的时候肯定会很困难。

     深刻体会到数据库的表结构对于服务器的工作的重要性，由于图书的三个表导致现在对图书的操作有很大的不便，最起码应该三个图书表的设计应该是同构的，不应该各自为战。这当然也不全是我的原因。

      写代码的时候一定要把自己代码的结构想清楚，尽量的使用代码重用，我这次写完之后就发现了大量的重复代码，相当的丑陋。MVC是一个很好的框架，结构清晰易用，企业级的开发一般都会采用这样的架构。但是需求一定走在前面，以最简单的方式实现全部功能，也是应该考虑的。应该读读项目管理方面的图书。以一个架构师的要求约束自己，这次readings大会战，不知道最终的结果是什么，不过无论结果如何，缺少一个优秀的软件架构师是导致readings如此丑陋的最大原因。

 

项目未完 同志还需努力~