xxxTMS项目总结
追梦1819(2017-7-26)
背景
今天是2019年5月13日，而这篇总结是去年7月26号写的。博主一直都有一个习惯，就是在一个项目完成时或者一个大的版本迭代后，都会对工作的方方面面进行一个总结。不过这篇总结比较特殊，公司领导要求我们写的，而博主的这篇总结，也被领导拿出来给其余同事当范例参考。当时开发的是公司的 xxxTMS 项目，项目开发不久，团队也是新组建的，大家处在一个探索期和磨合期。
可是再回头看是，这个团队以及当时领导的管理，是我见过的效率最高和管理最好的（此处的管理是指项目管理，不涉及公司层面的行政或者人事管理）。今天拿出这篇总结，目的是提醒自己不管什么时候，都不能忘记自己的初心，同时要对自己的工作的方方面面不断思考，而不只是做一个敲代码的机器。
前言
TMS本次迭代开发，我负责的模块主要有：到达确认、回单上传、回单确认、企业钱包等功能。在开发过程中，遇到了很多问题，以下是对所遇到问题的描述以及总结。
正文
一、问题描述
项目开发过程中，我将所遇到的问题分为两个部分，需求理解部分(1-6)和功能实现部分(7-9)。
1、需求文档不够详细。下面是所遇到的几个实例。
1) 回单录入列表，应该是“有回单”且“已到达”状态，但文档只有“仅显示待回单录入的运单”几个字；
2) 到达确认的逻辑，有到付金额显示到付金额，无到付金额显示尾款，两者都无不显示，这个逻辑在需求文档中都没有；
3) 钱包注册过程中，在使用体验上来说是应该有【上一步】按钮，但是需求文档没提到，后面使我们自己加入的；
4) 检索部，为提升用户的体验效果，有的字段可以作为检索条件，比如运单编号；
2、部分新的需求或者新的样式到开发后期产品部才确定下来，比如钱包相关的功能，这在一定程度上同样会影响开发进度；
3、需求的不断变更(难以避免)；
4、如果是调用上海那边的接口，很容易出问题，他们所给的api文档，可能不是最新的；
5、每个人只关注了自己的个人开发模块，对项目没有一个整体的认识，或者说与自己相关的模块都没有去了解；
6、业务理解得不够深刻，甚至把比较复杂的逻辑理解得很简单，导致开发后期手忙脚乱；
7、基本上都只是相似功能代码的复制粘贴和修改。这导致了很多问题：
1) 出现很多没用的垃圾代码；
2) 不理解所以然，会出现很多意想不到的bug；
3) 很多不规范的代码甚至错误的代码会不断“流传下去”，会进入一个恶性循环；
4) 看似相同的功能，但是实现方式不同的代码，并不能复用，更加不能简单的复制粘贴。例如系统中有很多的照片上传功能，但是实现时，有的接口是接受图片路径，有的接口直接接收图片；
8、框架不熟，如angular和bootstrap；
9、部分字段的校验被忽略。
二、总结
遇到问题，我们得总结出相应的方法去解决，避免下一次掉进同样的坑。
1、关于需求理解，我一直都认为是开发过程中的重中之重。只有正确的、深刻的理解好需求，才能更好更快的进行开发，以下是关于需求理解的一些感想：
1) 尽可能细化需求文档，更深入理解，不理解的、不够详细的或者我们想到而产品部没有提到的，尽早跟产品部沟通；
2) 复杂的逻辑，尽量能画出图表，有助于理解和修正；
3) 需求的不断变更，是在任何项目开发、产品开发的过程中无法避免的。但是希望产品部的设计人员能够以书面的方式通知需求变更，然后调整相应的开发时间和测试时间。而不是仅仅口头说变就变，这样可能影响开发进度；
4) 在深入了解自己开发模块的前提下，至少要理解跟自己相关的模块，比如数据的来源的对应模块，数据的输出对应模块等。拿运单管理模块来说，运单的状态变化要了然于胸；
5) 如果是调用别人的接口，一定要保证沟通的正确性(如字段名、字段类型)、及时性(必须是最新的接口)；
2、关于功能实现的总结
1) 在开发过程中，要善于总结，比如类似功能的代码，框架的基本使用，一些常用字段的校验等，形成自己的“代码库”，这样在后续的开发过程中会极大的提高效率；
2) 复制粘贴类似功能的代码，一定要多问几个为什么。尽量做到理解每一行代码的意义，不写无用无效的代码；
3) 所用到的框架(TMS系统主要用到了spring+hibernate（后端），bootstrap+angular（前端）)，应该主动、多花时间去熟悉去学习，尽量能够做到知其然知其所以然；
三、后续
1、开发过程中，我们不应是为了开发而开发。要多多站在用户的角度考虑(当然，这个如果跟需求文档设计的不一致，就要先跟产品部沟通)。比如上面说到的检索部加一些比较实用的检索条件、钱包开户加【上一步】按钮等；
2、项目所用到的技术，要去深究，不能一直只浮在表面，不然可能会产生许多不可意料的坑。
扫一扫
585
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
