没看过什么书，没什么工作经验，浅谈。 我想团队协作的基本原则是沟通顺利和互不影响各方的工作，如此一来就会面对工作同步或者滞后的问题。
刚刚开始没有经验的团队，一般流程是出设计稿、编码、测试，甚至是出设计稿、编码、出设计稿、改码、出设计稿……，永远不知道什么时候是测试时间，有一天老板心血来潮要体验产品，结果一堆bug，产品实现人员被骂得狗血淋头。 好像一开始就扯远了文不对题了,好，开始数点。 1.前后端如何配合 前后端的配合主要是数据获取和操作的问题。一般的做法的是各方自己写自己的，前端需求有了问题或者API调用不对头，后端改一下。很明显，这样并不好，会导致沟通成本增加（不要太简单的理解沟通成本）。 既然这样有问题，你可能会问那前后端在工作开始就确定API的调用接口不就好了？这样其实是没有什么用的，因为你还没有进行编码工作，你对这个产品并不了解或者细节了解的不深，双方的沟通是没有深度和不清晰的，即使一开始沟通了，后来还是再次沟通。
前端其实一开始不需要数据，可以自己模拟一些数据来实现界面设计的实现，这个时候后端编码人员也在同步进行API设计。
界面快要完成了，前端和后端编码人员进行API的核对和商讨，这个时候，编码人员对整体的架构都有清晰的认识，沟通就比较高效。
工作上也谁都不耽搁。 我这么说不是否定沟通，而是如何进行高效沟通。
2.面向对象编程如何设计你的类 在数据驱动的产品中，用户的所有的操作都是操作他的数据，一个类的设计也应该围绕数据操作来进行，如果有一个user表，那你的代码肯定也有一个user模型，围绕增删改查来组织你的代码，无论你的c层的逻辑如何，m层的代码实现也不会受影响。 这样的好处是m层和c层的代码耦合度很低，以后改起来很方便。以前写代码没有经验，写了很多难维护的代码，也不优雅。 3.作为一个编码人员的基本素养是什么 在目前，我只能简单的理解为你要对你的代码负责，负责包括写好注释，测试代码的功能和使用流程。
当然，我也问过很多人这个问题，他们都说不知道，这个问题了太难了。反过来想，有答案不见得是好事，追求答案的状态才是重要的。
一个编码人员在不同阶段对素养的理解和追求应该也是变化的。
只能说，我要做一个有职业素养的人。 4.2015的总结 上了半年班，可能是人生最后的寒暑假没有了，我心里很不情愿，我还没有做好心理准备，lol还没有上大师，心有不甘。
但是我是适应能力很强的人，所以没有上的大师以后再上。 说到最后都是感谢。如果有两个关键字的话，我想一个是‘拒绝’一个是‘迎合’，无论我得到的是‘拒绝’还是‘迎合’，我都学到很多东西，特别是那些我去实现和追求某些东西能开导我的道理，感谢你们。
