项目总结

      项目做到现在已经有不少收获了，也遇到了不少问题，现在将项目中我觉得需要特别注意的地方列出来，这其中不包括技术问题，写的这段时间我也发现了在项目中技术并非是最麻烦的的事情。
      项目开始时，因为阶段还么走完因此许多东西并不懂，也不知到如何开始，是技术问题，也是快速上手一个陌生项目的问题，在项目需求没出来前，问了做过项目的人，有了一个可以作为下手的方向，虽然方向有一些偏离，但是也在学着东西了，对项目中可能要用到的东西有了一些基础了解，在面对未知的东西时还是学习过的人更有经验，向他们询问确实能来了解些东西。
      之后开始了解项目的大概需求阶段，也就是明白了自己要做一个什么东西，虽然没有明确需求，但是知道项目是正式开始了。在这之后过了段时间就开始有前台的需求了。
      在了解需求阶段的时候整个项目的框架是已经搭建好的，觉得哪些能了解框架并搭建适合自己项目的人很厉害，同时也觉得自己落后太多了，我也想自己了解框架，但能力不够，所以项目结束后我要再把框架研究一边，不为技术为了自己能够学习如何去快速了解一个新的框架，也为了弥补自己在项目结构上的缺陷，虽然工作之后不太可能使用这个框架了，但框架之间说不定有什么相通的东西我能学习到。
前台确定需求之后是后台需求的确定，需要注意的是雪球不明确一定要即使提出来，即使是很小的一个疑问也不应该自己下决定，一旦开始作业，这些疑问都可能成为隐藏的大问题。
      再之后是数据库表的建立，这项工作交给了带领我做项目的人去做，也是我第一次接触实际数据库是如何建立的，也是第一次见到这么多库表，到现在为止，关于如何构建数据库自己心里有了一些总结了，建库无外乎两种表，实体表，关系表，这是关系型数据库建库的特点，适当的时候还可以建立一些类似于缓存一样的表，用于频繁操作一些数据时简化sql语句。
      数据库建立后开始分配任务，因为确实没什么项目经验，所以那时我觉得分配什么任务都行，即使有的任务确实感觉到了可能有什么技术是从未接触过的，但困难即是机会，我是这么想的，现在也是这么做的，在项目中我学到的是机会很少但只要能抓住一定会有进步，我不怕困难，不过有时确实会犹豫，我会尽力完成自己的任务，但也怕因为自己的学习拖累整个团队，能够面对困难，但又怕给其他人带来麻烦。
      开始真正写代码之前，以为询问过负责人很多问题，所以入手并不是很困难，即使磕磕绊绊但也知道从哪开始做了，毕竟整个项目框架已经搭建好了，我需要的只是去遵守一些项目规范，然后按照自己以前学的知识按部就班的来，开发期间遇到了很多问题，但也都解决了。
      接口明确
      接口是沟通前后端的重要途径，现在我们是通过rap2进行接口同步的，刚开始用的时候知道接口很重要，但也确实没做好接口的同步，因为自己还是像以前一样按照自己的想法来，并没有团队开发的意识，导致在之后的接口对接上出现了问题，前后端出现矛盾，不过也是这个问题让我学到了如何去和其他人沟通能快速解决问题而不是花时间在寻找问题是谁的问题上，一味的针锋相对不但不能解决问题还可能加大解决问题的难度，认清自己的问题，承认自己的问题，不追究对方的问题，退让一步，对方反而会很好的去听取自己的意见，甚至也退让一步，总之学到了不少。
      接口文档维护
      还是接口问题，无论解决接口问题效率怎么高，说到底都是出问题了，那么想避免这样的情况再发生就要做到接口文档的维护，无论是多么小的改变，是你知我知的事，接口文档上的一个接口名字，一个接口变量名字，一个变量类型都要做到及时更新，接口文档并非只是给开发人员看的，它的存在还是一种凭证，事情会忘记，但记录下的事情就不会丢失，虽然我现在对文档的维护也不是特别好，但只要是我会再涉及到的接口，需要用到接口文档，所看到的错误我都改正了。
      排期
      这个也是十分重要的，项目开发周期是要可控的，排期是开发人员对自己开发时间的估计，在自己预期的问题解决时间上适当放宽时间用于解决突发情况，但最好不要延期，延期往往会拖慢整个项目的周期，以为刚开始参与实际开发，事实上我的排期也确实出现了问题，未能考虑到实际业务逻辑的复杂，导致有三天的时间不在我的预期内，那段时间的压力确实很大，因超出预期确实是我没预料的，那也是我正视排期这件事的时候，幸好的是结果并不坏，仍未超出预期。我现在会去考虑自己所承担任务中复杂业务可能的开发时间，然后延长些，不过脸皮厚了些，延长了两天，被驳回了，但也在预期内因此这次的排期比上次好多了。不过也出现了意外，接口本定于五天内写完，但工期提前了，要求两天内写完，幸好新需求通知到后做了不少准备工作，还是在预期内完成了，当然急赶的结果是埋下了不少bug... 这件事告诉我，预期再完美突发情况还是会有的，因此当自己有时间做些什么事情的时候一定不要浪费。
      进度把控
      和排期类似，是对自己的开发进度有个明确的了解，知道自己做到哪了，还差多少，当出现进度延缓，无法在预期内完成时，至少在预期的前两天告知其他成员，减少任务，或者协助开发，总之不要让自己陷于其他人想帮帮不上忙的境地。
      需求沟通
      我们虽然在项目最开始就进行了项目需求沟通，但到实际开发中这些需求会进行细化，细化到每段代码的实现逻辑，需求是生产的依据，当自己不明确需求时一定不要自己下主意，或许会给其他人添些麻烦，但作为开发中的一员，需求不明确造就的产品就大概率不正确，那就不是麻烦了，是灾难，无论是对要修改代码的人来说，还是对团队来说。
      代码同步
      代码同步是为了能有一个当前完整的代码库，现在使用的是gitlab进行代码同步，在测试时这些代码可以被部署在测试服务器上进行测试，同步度越高，bug就越少，测试越稳定，而且做到实时同步很难，自己的本地的代码往往是最新的，尽量保持同步后，当其他开发人员直接连接后端某个开发人员电脑测试时也能测其他人得代码，代码同步如同接口同一样，是很重要的事情。
      统一测试
      这个是当前所有开发人员最新代码的测试，虽然能够直接连接后端开发人员电脑测试，但那也只是应急或者节省一些时间的缓冲策略，要测试还是要在实际的生产环境中测试比较好，有些问题可能会因为环境的不同而表现不同，因此，测试时最好能做到统一测试，而 不是各自测试自己的。
      以上是目前我在项目中看到的一些问题和自己存在的一些问题，现在我项目的开发经验还是不多，有些想法还是不成熟的，但我会在之后的学习中逐渐改变的。