加入新公司后前面一段时间还算正常工作，虽然有时候也有点忙，但也还算能够正常下班，按时完成手上的工作。随着另外一个系统的两个人离职，接手这个系统，一下子就忙了起来，时间节点就在那里，不得不加班搞定，现在差不多快结束了，总结一下遇到的问题。

开发规范

这段时间开发的东西都是按照一套新的开发规范来做的，这套规范是一家著名公司的规范，但是这个规范可能在别人公司有非常好的实践，但在我们这里需要快速完成一次迭代，并且没有踩过里面的坑这种情况来说，并不是一个很好的选择，在开发的过程中会经常遇到一种情况大家都不知道按什么标准好，不同的人按照不同的方式去做了，更糟糕的是并不能很好的理解别人规范的一些意思，只是看了一些很表面的东西。整个不长的开发阶段中就经历过几次大改一些规范上的东西，非常耗时。觉得在使用这种东西时最好能够小范围试用，或者有这方面的专家，不然会浪费掉非常多的时间。

项目难度

接手另外一个系统时实际上是不太愿意的，这是目前这些系统里业务最复杂的，而且自己对这块的业务并不是太了解，而且这个系统被做了一部分，还需要去了解之前人写的东西，再加上之前人的所做所行，觉得这个系统难度非常大。
在这两个礼拜做下来，其实感觉业务理清楚了，东西也就那样，并没有很难，也得益于把原来的项目直接扔掉，重新做了一套，省去了去看前人写下的代码与处理里面的bug(bug很多)。所以其实业务上的项目大多数来源于对业务的了解，只要很清楚的了解了业务，程序上就手到擒来了。

产品

这届的产品是我见过文档能力最差的，好几个人的团队，文档写的这是一踏糊涂。业务描述不清楚，这一点在评审需求时遇到非常大的阻碍，发现很多地方写的是这样但实际上后面还有很多东西，在开发时还会遇到这种问题，有时候真的想就按照文档文档写的做算了，管他对不对；文档与ui图工具用的太差了，话说没描述清除就算了，到时后问问你，但你好歹也把文档与ui整理清楚，有时没文档看看ui就明白什么意思，但用的那个工具完全不知道文档与ui怎么对应起来，这里说的就是石墨和蓝湖这两个工具，石墨卡的不行，蓝湖把图一股脑扔在里面，根本找不到想要的。好在几个产品都很配合，这把增加的了解业务时间稍微减少了一些。产品要把文档写好啊！

接口文档

项目里开始用swagger做自动文档生成，但这个东西用下来不是怎么好用，会侵入代码里面，然后同一个path不同param这种接口他只认为是一个，还有其他一些问题导致我非常讨厌这个东西。后面就自己用markdown手写api文档，其实也不会耗费多少时间，或许有其他更好的方式吧。这次开发中有一个很不好的地方是没给前端和app端很好的接口文档，其实应该最开始就给出来。