一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第12天，点击查看活动详情。
在新公司工作半年多了，很多事情开始变得熟悉（ji xie）起来，我也从一开始的小白，慢慢成长（xun hua）为一个经验丰富的工程师。
梳理一下在互联网公司做一名开发工程师的一些日常。
需求评审
这一个环节是产品提出他们种种天马行空的设想，把产品形态描述地天花乱坠。而一旁的研发们则心里暗暗嘀咕，这需求又得让老子加班了，可恶。
一次好的需求评审，最好能让研发和测试，明白需要交付出什么样的产品，即可落地性强。如果产品的设想一直飘在空中，不切实际，则会让开发变得非常艰难，无论是出技术方案，还是给排期，都会大费周章。
所以，我的建议是，产品和研发应更紧密一点，好让产品知道我们研发能做什么，不能做什么，能获得哪些支持，还缺哪些方面的支持，这样才能把产品的想法更加切合实际，提出更契合当前研发团队情况的产品方案。
技术评审
需求评审完后，就开始技术评审，这个环节需要研发出技术方案。
技术方案需越详尽越好，越深入到细节，就越能发现开发过程中的潜在风险点，并更好地帮助确定排期。
做技术方案，我觉得最难的还是团队间协作，尤其是多个团队合作的项目，如何正确合理的分工，就显得尤为重要。
我理想中的合作状态，是所有人都往一个方向使劲，如果有团队总抱着多一事不如少一事的心态，我会感到特别心累。
做技术方案时，也不能闭门造车，多看看当前部门有哪些技术积累，有没有可以复用的，哪些思路是值得借鉴的，帮助自己能快速完成技术方案。要知道，来公司干活，不是考试，而是如何高效协作团队，一起把事情落地。
对于技术评审的具体内容，根据项目不同内容就会不同，但大体可归纳为以下几点：数据库设计，数据流设计，模块设计，接口设计，可靠性设计等等。以后会写文章另外介绍。
技术评审完成后，大致知道工作量，可以定下排期，这是产品也很关注的东西。
测试评审
除了研发测的评审，测试团队也要出一些测试case。这样的好处是，一是从测试角度对产品功能做评估，看下研发有没有漏东西，二是也是可以提前预知一些潜在风险点，三是测试用例也可以作为研发自测的一个工具。
如果团队有一个厉害的测试，会很省心，因为研发有时候也不能对系统有足够的了解，反倒是测试能深入了解各个细节，提出合理的方案。
上篇的内容介绍到这里，在下篇，将会分享开发，提测，上线，复盘等心得总结，敬请期待。
