文章目录
产品需求讨论阶段
产品经理确定产品需求，弄好产品原型，然后团队成员拿到产品原型，这个时候，UI，前端，后端，测试都会了解产品需求，这个时候难免会出现产品理解不一致的情况，特别对于后端研发而言，产品逻辑一定要贴合产品经理提出的需求，如果有理解不一致的情况，很容易导致后期返工的情况，所以作为Java开发岗，在拿到产品原型之后，可以拉着产品经理和前端，测试进行一次需求反讲，这个对于团队成员理解产品需求，并且理解一致会有很大帮助。另外在进行需求返讲之前，需要确定产品经理追求的是细致的还是大致的，因为每个产品经理他对需求考虑肯定有遗漏的部分，这个时候，需要了解他希望后端研发是帮他想到没考虑到的，还是简单理解他提出来的需求，一句话就是，需求讲细了会导致会议时间很长，有些产品经理会很烦，他心理会骂娘，心想我就想这个简单的东西，你给老子扯这么多干啥。需要讲粗了会导致很多细节没注意到，实际开发的时候会有很多细节逻辑没确定，有些产品经理会嫌弃你，这人是个菜鸟吧，之前开会的时候不说，开发了就不停的问着问那，会不会影响进度。这是一个很扯皮的过程，所以在开会之前，一定需要确定产品经理要的是啥，这可以根据自己做的项目先大致做个判断，比如你研发的项目是对用户而已的，那么在研发之前，肯定是越细越好。比如你研发的项目是公司内部的项目，或者不是针对大众用户的项目，过需求对细节方面要求也没有那么严格。但是这些只能作为你自己的初步判断，实际还是需要跟产品经理确定好，避免后期扯皮扯不过对方。
测试用例
产品需求过完之后，测试会拉着前后端和产品经理过一遍测试用例，主要是列举需要测试的细节部分，这也是后端补全自己对需求理解的一次机会。
工作任务评估排期
对于某些企业，对于工作任务排期一般都会压比较大的工作量给员工，这种和国外的项目形成鲜明对比，对于研发过程中出现的各种意料之外的事情，比如服务器被黑，服务器文件被删除，服务器资源不够，代码丢失，团队成员隔离无法办公，自动化部署流程中断无法发版，之前发版出现的bug未排期需要立马处理，领导突然开会占用研发时间等等情况，没有合理的安排，一旦定好时间，必须按时完成，否则会影响个人绩效，所以在工作任务排期，研发人员评估时间不能压的太紧了，也不能太宽松了，否则会被认为工作能力不行或者工作态度不行。最好能给出理由，为什么这项工作任务需要这么长时间，给出可以用来作为“证据”的理由，这么做，有二个好处，第一个方便后期在和公司有劳动纠纷的时候，作为呈堂证供，提交给仲裁委的证据，第二个可以说服领导和团队成员，体现出实际的工作量。
数据库表结构设计
在理解产品需求，并且和产品经理，前端，测试理解一致的情况下，才进行表结构设计。设计表结构尽量考虑后期扩展问题，尽可能的遵循表结构设计三大原则，除此之外，对于每张表的公共字段需要统一，比如是否逻辑删除，创建时间，更新时间，创建人，排序号等等。在设计表的时候，尽量减少单行数据的大小，字段的宽度设得尽可能小，尽可能不用text、Blob、Clob等类型，它会增加存储空间的占用，读取速度较慢。能用数字型字段就不要设计为字符型，因为字符型锁占的存储空间更大，比如，性别这个字段不用男女进行存储，改为0/1的方式，这样不仅可以控制数据量的大小，增加了同一高度下的B+树容纳的数据量，还能提高检索速度。尽量使用varchar/nvarchar代替char/nchar，因为变长字段空间小，可以节省存储空间。不在数据库中存储图片、文件等大数据，可以通过第三方云存储，存放图片或者文件地址。金额用decimal，注意长度和精度。如果存储的数据范围超过decimal的范围，建议将数据拆成整数和小树分开存储。尽可能不要给数据库留null值，尤其是时间、整数等类型，可以在建表的时候就给非空设置。对于某些未来可能会成为大数据量的表，要提前考虑到分库分表的情况，又或者未来可能使用其他数据库的情况，主键尽量不要使用mysql的自增长id。不同数据库语法和实现不同，数据库迁移的时候、多数据库版本支持的时候、或分表分库的时候需要处理，会比较麻烦。当DB异常时整个系统不可用，属于致命问题。建议使用雪花算法生成主键id。
接口文档讨论落实
当设计好数据库表结构之后，这个时候一般UI设计稿也出来了，这个时候就需要对UI了，因为有些时候，产品原型和UI有一定的出入，如果后端以产品原型去设计接口文档，而前端以UI图去实现，会导致后期需要修改接口文档，出现返工的情况。和前端确定好交互逻辑，以ui图作为参考，确定好接口文档后期尽量就不要改动了，否则会有大量的返工，影响效率。另一方面，页面的交互逻辑也需要通过UI图和前端进行一次返讲，尽可能保证从用户角度出发，页面的交互逻辑是通畅的。和前端的理解也能保存一致，页面没有出现漏接口的情况。对于请求方式，比如GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源；这个尽量统一起来。另外需要考虑后期接口参数是否会新增，如果后期参数不确定，尽量使用POST，方便后期扩展参数。对于返回响应的实体类，后端响应统一起来，不能每个后端都用自己的响应实体类，这样前端会炸的。另外对于后端抛出来的错也需要拦截封装，给到前端一个友好的响应，而不是直接抛出去，这样前端那边的感知不友好。可以通过swagger在线文档快速编写接口文档。
研发阶段需要自测
对于一个新功能，一开始会有大量的接口，这个时候尽量先一次性编码完成之后，再去自测。这么做的好处是方便后期接口调整和修改，不需要反复自测。自测阶段不要单独只测试单一接口完成就不管了，整体流程需要以接口的形式跑一遍，尽可能考虑多种情况的发生，提高接口的质量，减少后期的bug。研发阶段就需要考虑后期接口的并发和数据量，时间充足尽量进行压测，这也是避免后期bug的情况。代码规范遵循阿里巴巴开发手册即可，对于字典类型的，后端尽量统一，到底是用枚举类还是存数据库里。
联调提测冒烟改bug上线
接口开发完成之后，和前端会有一段时间的联调时间，联调时间大部分取决于接口的质量，以及前后端字段是否需要调整，还有前端的效率。联调完成之后，需要发一版到测试环境，自己先冒烟跑一遍，保证主流程没什么大问题，阻塞性的问题没有了之后，发提测邮件给项目经理，产品经理，测试，前端，讲需要测试的功能点列举出来。在提测之后，时刻关注自己的bug列表，及时修复当前版本的bug，改好之后快速发版，测试通过之后，在上线时间进行发版，发到演示环境或者生产环境。
每日的工作完成情况和工作计划
一般公司都会开早会或者晚会，讲一下今天的工作计划和工作完成的情况，或者有没有什么问题等，这个时候尽量提前写好工作计划和工作完成情况，发邮件给领导，即便没有要求尽量也写。这么做的好处是方便后期和公司有劳动纠纷，可以作为证据，除此之外，提前写好工作计划，让自己心里有个数，开会的时候可以很多的讲清楚自己的工作情况，另外如果后面有周总结或者月总结，年总结之类的，只需要把之前写过的邮件翻出来就可以清楚的自己过去自己的工作情况，不会因为忘记导致没东西可写，不会让自己的绩效表现的太差。对于节假日加班或者工作日加班，一定要留底，有证据，有些公司不会因为你加班给加班费，说给的调休，后期也不一定能全部给齐，所以这个留底之后，后面有劳动纠纷的时候劳动仲裁会有利，劳动仲裁不是很麻烦，手续费只要10元，提交身份证，劳动合同，员工证，加班证据（代码提交记录，聊天记录一切可以证明你加班的都行），合理的维护自己的合法权益很有必要。对于非工作能力和工作态度导致的试用期没过，加班费不肯给的情况，在公司结清所有工资之后，可以进行劳动仲裁，劳动仲裁时间是你离职后的一年时间都有效。
对于试用期转正
一般公司会要求试用期薪资打八折，这种情况在入职之前需要衡量一下，考量一下公司靠不靠谱，同等机会是不是可以优先考虑试用期给全薪的公司。入职后，如果完成了一个大功能，可以申请一下试用期转正的事情，毕竟试用期员工和转正员工福利待遇还是不一样的，特别是在裁人这块，很多时候，你能不能转正就看你领导一句话的事情，所以尽量争取吧，即便不给通过也不影响什么。大部分公司试用期都是三个月，这三个月一定不要放轻松，尽量早点转正，不管你觉得多有把握，终究还是没有转正，还是有很多意外情况可能会导致你无法转正，比例疫情，公司资金链断了等等。
对于公司选择
个人建议，在选择公司的时候，尽量不要去通宵加班的公司，选择有双休的公司，加班多的公司大多工作安排不到位，进去以后会占用你的个人时间，长时间的加班会让你的眼睛容易得干眼症，对腰也不好。不太建议年轻人把太多的时间放到工作上面，同样的时间，用来提升自己的专业能力会好很多，专业是你未来可以提薪的基础。另一个需要考虑年终奖，因为年终奖是你一年当中存钱的一个机会，它也是影响你一年可以存下多少钱的一个因素吧。然后就是风评，主要看领导的风评，团队的氛围，一个好的工作氛围，可以让你工作很轻松，心情愉悦。
