项目架构相关

   其实至于项目架构相关就是主要是编写文档啦。目前还在寻找比较标准的文档编写的规范和相关设计模式，学习后来总结下：

  终于又恢复正常的"写写"生活了，为什么这么说了。前段时间一直实习，在做项目组安排的任务，我当时的想法就是如果连简单的上层的东西都做不好，那么又怎么能够往底层走了。所以我努力的做到最好。因为自己的项目经验太少，编写别人使用的软件，同事查阅的代码的时候会让同事说自己，不能这样写，需要怎么样写。确实，自己考虑的太少，经验太少。需要历练才可以成长阿！先不说了，这些东西以后在LIFE中去说。

 在实习期间确实学到了很多东西，很感谢同事的帮助！后面项目验收的时候还接触了很多与文档编写相关的东西，确实给我提供了很多东西。其实在做项目的时候可以有两种方式去编写文档：1、时间紧迫，可以先开发，然后后补文档；
    2、先写文档，在开发；
 以上两种方式都可行，当然必须考虑客户的需求和体验，所以我们必须先出设计，然后与客户交流，确认后才开始进行功能的开发；
    这是我在开发BS和CS结构的功能模块的时候的做法，先出设计，然后在做功能。如果涉及到与业务相关的东西，那么我们就不能纯粹的做功能开发了，而是需要具体的与业务挂钩；
    这个说起来比较抽象，不过你做多了后，与客户交流多了之后，就明白了。比如一个xxxx系统的帮助文档，你把所有模块的帮助文档都做好了。那么此时你就需要考虑什么了？
  1、你的帮助功能是否进行分类了；
  2、当你在使用系统的某个功能的时候，当用户在按下F1帮助按钮的时候，你是否自动关联到该功能的文档，同时只是弹出该功能的帮助文档，以便达到目的化和简约化，这就是与业务挂钩了、当然这些诸多功能可能就需要存储数据了，那么一般都是利用数据库来做。如果一个系统与数据紧密相关的话，那么数据库这个"东西"必不可少。

 
 至于，我们所说的文档，比如需求分析，项目规划，设计文档，详细设计文档，升级文档，功能设计文档等等，那些每个公司都不一样，所以自己多看看别人的，然后整理出自己的一套思路，写出设计，然后完成设计，然后编写DEMO，然后代码编写，然后提交测试，最后发包，诸多流程以后会慢慢接触的。

 当然在windows下和在linux下截然不同，可能文档大体相同，但是说句实话windows下代码代码效率要少现不足，微软的整套项目管理的系统功能确实挺强，这点不过。linux下也是类似的，只要你用熟了，一样好用。这就各有千秋了，我们也不贬低谁。

  其他的东西我感觉就没必要说了，毕竟很多东西都是学了才是自己的，不然学习太多也没用。而且不能学习太多。所有阿，我应该开始侧重某方面去学习了，而且要学的很好，不然就大浪淘沙，把我给淘掉了，悲剧呀！我还是挺刻苦的呀........