项目总结：开发过程中犯过的错误

其实很多错误都是老生常谈了，但是没想到自己在接手这个项目的时候仍然会在这里踩坑~当然也有可能是这个项目逻辑太过复杂、团队工作方式仍存在问题~希望自己在今后再处理复杂流程时，所有问题都能更好的规避~

即过不纠，下不为例

1.工欲善其事必先利其器

要想把分配的工作做好，作为一个研发人员，一定要熟悉自己项目的开发环境和项目中的技术框架。前段时间接了一个需求，我们的订单需要按层级进行展示，但是问题来了，在某系统的供应商页面查看订单数据时，始终无法找到对应的接口是哪个，别说接口了甚至连在哪个项目都不知道，而且没办法根据URL进行判断，中间有类似nginx的转发，单单根据URL根本确定不了接口请求的是哪个项目，哪个接口。后续没办法想采用debug日常的方法进行确定，如果进断点则证明进入了该方法，但是日常一般两台服务器，debug有时能进，有时候进不来，尤其多个项目互相调用时，debug一台机器完全是靠概率，刚开始不知道部署逻辑，所以一直以为项目有问题，晕头转向。所以在接触一个项目的时候，需要花时间去了解一下，自己的开发环境是什么样的，项目测试方式，运行方式，部署方式，以及自己的项目用了哪些框架

2.业务不熟悉导致举步维艰

这段工作期间接到一个全链路的需求，某种服务器在整个链路上有特定需求，当时处理了好久，还有很多流程没有处理到，直到上线前才发现，问题在于对项目不熟悉，甚至连测试都不知道该怎么测~上线的前一天和测试同学搞到了凌晨一点多~才把最后漏掉的流程补上~我觉得这里面有两个重要问题，首先项目太生了，测试都不知道该怎么测，其次整个链路不能很好的把握，导致部分流程遗漏，所以在开始做项目之前把业务梳理清楚~及其重要

3.需求澄清

还是上面服务器的需求，因为当时没有和PD直接对接，而是和其他同事沟通，其他同事说改这改那，我就改这改那，最后确实改完了，但是结果呢，和PD要求的并不一样，那问题来了，责任在谁呢？这种问题是完全可以避免的，如果提前与PD确认清楚，大家都会少很多麻烦~我觉得这里面有两个问题，需求澄清一定要与提需求的人直接对接；第二个问题是团队没办法给新人较好的支持，需求肯定是新人去做，但是作为团队是需要给到新人一定的支持和解疑答惑的~

4.项目设计环节

设计过程需要完备，也需要设计评审，这样可以提前处理掉开发中遇到的多数问题。比如服务器需求，如果存在较好的设计评审，那么重要环节缺失肯定是可以发现的~

5.代码是自己的作品，要精益求精，任何一个小的问题都不能被放过

在处理页面的访问权限时，通过其他域传过来的员工code进行判断，本来默认code会一直存在，但是在线上偏偏就出现了code不存在的情况，导致空指针。在自己的判断里，这种情况永远不会出现，但是事实是它就出现了，所以对代码一定要精益求精，任何但凡是有可能的问题，都不能放过，不然，这个有可能就会成为一个坑

6.开发心态

任何人写的代码或多或少都会有一定问题，我们接手过的任何需求或多或少也会存在一定问题，我们在开发时应尽可能的将逻辑梳理清楚，做到对自己的程序有信心；如果真的出现了问题，我们都应该勇于承担，不能逃避推脱问题，当问题来的时候，没关系，做之前好好做，做之后我们好好解决就是了，不管什么样的责任，天塌不下来的，用于承担！好好处理掉就是了！