从開始工作到如今已经一年了，通过一年的工作总结了一点东西，跟大家分享下。我所在的团队大家都没有什么经验，所以边写项目边总结，加上请教公司其他的团队。如今一起开发也越来越顺手了。这些观点可能非常稚嫩，希望经验丰富的大神们多多批评指正。
1：写每个项目时都新建一个文件夹，如今感觉貌似用IntelliJ IDEA加上maven建立和管理项目比較方便，但用eclipse查看api比較方便。
2：合作开发时。及时提交和更新代码，由于过一段时间后，遇到问题不方便找到最新代码（每一个人存的版本号可能不同）；
3：编码之前具体设计文档要尽量完好，包括数据库、功能（功能要十分具体）；
4：開始编码之前一定要明白任务。把每一个功能点分配到个人。明白任务的优点是每一个人都知道自己应该做什么，不至于由于谁多做谁少做而产生不好的影响。再一个。一起讨论时会气氛分比較好。假设有必要的话能够做一个《问题功能统计》。把全部的功能和问题列出来，每天完毕什么都标记出来（谁完毕的。日期），一周做一次总结，把每一个人完毕的任务编译一起；
5：開始编码要先从总体角度设计项目架构，感到自己的不足，如今正在看《Head First设计模式(中文版)》；
6：能写凝视的尽量写凝视，这个真的非常重要，只是当时敲代码的时候是真不愿意写%5D9pgf.gif)
；
；7：刚接触一个新的技术时。不能急着去写项目，要先对技术做一个大概的了解，然后down下api文档和样例（先学查文档和知道它能做什么），一个新的技术不是那么好学的（不论什么技术都不是那么easy掌握的），所以多思考、多请教别人（不能全指望别人的帮助。最好让他教你怎么使用文档和相关的调试与IDE工具）。假设有项目在身的话，肯定会经过一段很痛苦的阶段。当遇到一个很让你恼火的错误时。实在解决不了。就留到明天，很有可能这样一个错误，当你解决时会对你学习这门技术有很大的帮助；
8：对做过的东西及时总结。包含技术和团队合作的经验。我打算以后每周尽量写一篇技术总结的文章(这个很重要)。
9：我很希望团队完毕一个很好的项目，所以刚開始时很着急的让大家接受我的观点和编码方式。结果事与愿违，虽然你写的好。别人也不见的会接受，经理跟我说我的态度有问题，应该以商议的态度让别人接受你的建议。不能太急。而且别人的想法并非没有可取之处，应该静下心来。大家讨论一下，相互补充。