《采购系统》项目总结

前言

这次项目是腾飞学长交给张凯杰学长负责的一个小型商业项目，我在本次项目中是作为一个后端负责人的角色。

开发人员5人，开发周期为2星期，虽然我们提前完成了任务，但是在第一次交付后的新增需求变更中，我们又花了将近1个星期多的时间。中间后端全部回家，导致第一次交付延期（我猜极大可能是这个原因，所以内心也比较愧疚），这一段时间中项目进行了断层，等后端人员回来后，需要思路重新回到这个项目中。不过最后还是顺利完成交付，后续可能还是需要维护的。

经验总结

以下都是我在这次项目中出现的问题和一些感悟，做项目中可以参考一下。

1. 没有接触框架，就去做项目，但是项目中就是要用这个框架怎么办？

   • 这时候就需要自己去快速上手这个框架了，一开始可能会蒙，但是不要怕，没见过猪跑，咱还没吃过猪肉吗，框架原生的代码咋写，咱先模仿着来写，虽然不知道啥意思，但是模仿着模仿着就会了，代码层面可以相似，但是思想很难同步，一千个人有一千个哈姆雷特，框架的搭建，使用以及架构思想很重要，这时候需要自己对着官方文档，快速过一遍，感悟这个框架的意义和框架是如何实现的。这样才能快速上手，一般就花一天时间就可以去上手了，这时候是一个不断模仿的过程的，循序渐进就可以把握这个框架了。

2. 第一次作为后端负责人，应该要做些什么？

   • 首先是自己要有信心能够带领后端团队顺利完成排期任务，然后是要指导和帮助后端团队解决问题，这一块的确很锻炼人，技术沟通和思路很重要。要有规划能力，对于工作的计划规划，是不是胸有成竹，进行风险规划。最后就是解决一些难以理解的bug时候需要不断记录。

3. 我们对不同项目大小的态度应该是什么样的？

   • 不管拿到什么级别大小的项目，都要去认真对待，从中吸取经验，不断成长，注重成长和过程。

4. 前期后端压力比较大，前端等着后端的接口，如何有条理的去解决？

   • 首先是要后端需要根据需求去设计数据库，因为数据库中的字段很多是需要返回给前端的，如果数据库没提前设计好，会影响后面的前后端接口约定，当然了，后端是主要设计数据库的，但是在时间比较紧张的情况下，前端也可以参与，或者拉大佬帮忙一起设计。当数据库设计完成并且表都建好了后，这时候后端再去定API接口，但是再时间比较紧张的情况下，前后端都参与比较好，这时候定的接口前后端都可以知道是什么样子的，也就不需要再去review了，但是但是还是要建议有接口文档，可以留作备份参考。如果项目组成员中有人不了解框架，需要让他先快速上手一下框架，给他一点时间去熟悉，这段时间不急着去安排后端任务，先让前端去写页面即可。后端负责人需要把握前端页面开发情况，合理安排后端任务开启。当一切变得有条理的时候，那么你就可以去把握事件的走向，压力自然就不会那么大。

5. 开发中一天提一次代码有必要吗？会不会太影响开发效率？

   • 我觉得非常有必要，一天一次我甚至觉得少了，因为及时合并代码能够保证服务器上运行的是最新的代码，接口可以及时反馈给前端，同时出现的问题也可以很快浮现，这样就减少大联调中产生的bug。另一方面开发人员间的代码会是最新的，减少了代码产生冲突机率。如果你觉得影响了自己的开发效率，需要从自身找原因，为什么会觉得影响了，对吧？

6. 开发过程中遇到了很棘手的问题怎么办？自己已经将近一个小时没解决，任务即将超时怎么办？

   • 首先向项目负责人说明情况，申请协作和该任务时限重定。然后梳理问题，讲清楚问题在哪，自己做过哪些尝试的解决方案，节省协作人员问题感知时间。如果这个问题仍然没有解决思路，寻找替代方案，暂时放弃该问题，记录该问题，确保此问题不影响整个项目的开发和交付。

7. 项目中遇到的技术难点有哪些?

   • 框架的灵活使用，很多时候，我们是需要自己去完成某项功能的实现，但是有时候在框架中其实是有已经写好的实现了这个功能，这个时候我们就可以不用重复造轮子了。
   • 新技术学习成本高，有的功能需要新的技术去实现，但是这个技术又比较难，开发时间不够自己去学习掌握，那这时候还是建议“对着葫芦画瓢”，只要咱们画的瓢它能跑起来，咱就先不管了，等时间够的时候回过头来再去思考我这样画的他咋能跑起来的，也就是再去深入学习。
   • 框架出现的bug，使用框架过程中发现框架本身就带bug，而且这个bug还影响到最后功能的使用，这时候还必须要debug挖框架底层代码逻辑，从中去改了。
   • 前后端无法重现的bug，从头开始梳理逻辑，最让人头大的。

8. 项目开发过程中与人交流产生的问题如何解决？

   • 人际关系的处理对于我来说应该还是比较注重的点，我个人有过一两次团队开发项目的经历，都出现过大大小小的与人交流上面产生的问题，多数情况是我没有特别清晰的让别人懂我的意思，而让别人似懂非懂的去做了，结果到最后的他做的和我讲的差别很大，这就是我的问题了，首先不要上去就怼，还是需要心平气和的再给他讲一遍，直到他懂我说的意思后再去做这件事才会带来比较好的效果。
   • 另一个情况就是观点不一致产生矛盾。那么竞争、回避、包容、妥协和协作等情况是常见的解决方式，这时候寻找项目负责人进行协商处理，往往可以解决这个问题，与其两个人争得面红耳赤，不如将选择权交给项目负责人来把控。美国总统林肯曾经说过一句话：当我准备和一个人理论的时候，我会用1/3的时间思考我的立场以及我想说什么；另外2/3的时间我会思考对方的立场以及他想说什么。这无疑是一种从根本上解决问题的方法。

9. 对比之前的前端开发，后端开发有哪些需要注意的地方？

   • 前后端分离是一种架构模式，前端人员需要思考如何将后端的数据进行渲染上去，本次项目中前端表头与表列的动态变化是一个难点。而后端同样也许要做到excel文件和前端页面表格一致，这都是一样的道理，都需要考虑如何去做到数据变化表格动态变化。也就是说，后端的任务核心就是各项服务怎么实现和传给前端数据的格式是什么样的，数据库字段咋传给前端，各种复杂的sql语句如何编写了。日志也很重要，出现bug就可以根据日志去解决。熟悉各种配置文件和注解，便于开发。CRUD很常见，要精通。代码优化与注释是为了让人看的，便于维护，也需要注意。后端的缓存与前端的缓存的作用是不一样的，但都是可以帮助我们解决一定场景中出现的问题。

10. 本次开发的项目流程走的咋样？(每次做项目都需要关注的点)

1.需求人员向项目组提出需求，然后给项目组的所有人进行需求讲解，大家一起探讨需求中各项细节的可行性。（Done）

2.当开发人员和需求人员一起确定没有问题的时候，开发人员返讲一遍需求，当双方都没问题的时候需求才可以定下来。(Done)

3.需求确定以后，开发人员进行分工调整，然后订制开发设计概要和Api，后端Api中一般包括一些接口，需要的参数，需要和前端确定访问路径以及传递的参数和数据格式。（Done 80%，本次项目中部分接口是在开发的时候才发现少的，以后需要避免出现这种情况）

4.在设计api的过程中，需要前后端各自设计好后互相讲解，讲解中要达到相关重要点的意见一致。(Done)

5.需要有测试人员编写测试用例，验证是否可行。(Done 80%)

6.前后端开发人员自己需要有测试用例，在测试中不断修改和优化自己的代码使其代码更加简洁。(Done)

7.当双方都测试没问题后，进行联调，进一步确定功能没有问题。(Done)

8.打包部署到服务器，联调测试。（Done）

小结

• 在编写代码过程中我们也需要不断的总结，无论是需求的变更还是系统的搭建，我们都需要考虑哪一部分是变化的哪一部分是不变的，将不变的抽取出来，变化的封装起来。这样在以后无论是系统扩展还是需求变更中我们都能够以最小的代价来完成任务。
• 很开心项目能顺利交付，并且得到学长的肯定，虽然项目是个小项目，但是每个小项目都有自己的难度点，像文凯他们的那个项目，用到了人脸识别，图片压缩技术；而浩鹏他们的那个项目战线时间拉的长，并且后端人员又少，按浩鹏说的就是“又臭又长”，挺费心力的；回到我参与的这个项目，excel的多个单元格合并和动态表格的制作以及不同角色用户的权限设置等技术是这次项目的核心。也就是说，不管什么项目都有自己的核心要点，我们都从中收获了许多，我感觉在做项目经历的这些过程中成长是最快的。
• 最后，“当你越过了喜马拉雅山，你有拥有了越过喜马拉雅山的能力”，加油吧！