总结

参与了八个月左右的后端开发，心情也逐渐地从开始的兴奋慢慢地变成了现在的平淡。刚开始，艰难地看懂了很“复杂”的一些业务代码，然后通过一些细微的改动实现了一个需求或者修复了一个bug，并且上线，觉得很有成就感，很爽；再然后，自以为已经非常了解业务了，也觉得不能再忍受那些过于“复杂”无序的代码，便开始尝试去做重构，往往希望通过更大的改动来实现某个需求，同时将代码逻辑优化，这时候，觉得自己的工作很有意义；到现在，发现自己之前所谓的重构优化其实没什么必要，甚至引入了一些之前不存在的问题，也逐渐碰到一些奇奇怪怪的由于数据兼容、异步更新等各种原因所导致的bug，便真切地意识到自己其实很菜。

是我太菜么？是的。秋招前，突击大半年，转cs，然后入职，便开始成为view-control-v-control-c工程师。基础不好，把coding想得过于简单，考虑问题不够全面。所以还是要接受自己的菜鸟定位。思考了一段时间，接受了自己现在比较菜的事实，但是不愿意接受自己一直菜下去。于是思考：如何才能更快地进步？想了良久，觉得可能的答案是：多思考、多学习、多实践。

过去的这段时间，我应该只是一名刚刚合格的字段录入工程师，花费了大量的时间在理解字段录入逻辑，以及纠结于如何才能更好地接受前端POST的数据和提供前端GET的数据。这些工作抽象一点可以总结为是“维护数据流入的接口” or “维护整个数据系统的一部分数据生产逻辑”。我不再认为自己是一个后端开发工程师，而应该是一个数据系统开发维护工程师，当然，现在还有点不合格。

不同于web系统等描述，我觉得数据系统是一个更为抽象的一个概念，也更为准确的概念。参与整个系统开发和维护的所有RD都可以认为是在和数据打交道：录入数据、处理数据、展示数据，在复杂一些的系统中，比如引入微服务等概念后，应该又有很大比例的人员是在维护一套数据传输系统。整个系统的核心应该是存储，比如关系数据库、ES、hadoop等能够持久化数据的存储服务实例，关系型数据库由于在保证数据存储一致性方面的优势，因而也成为了整个数据系统中的存储核心，ES增强数据搜索功能，hadoop等通过离线数据提供分时、分天等不同维度的历史数据。围绕在数据存储外围的是各种后端服务，可以分为同步、异步两大类。更外层的则是数据展示，比如浏览器页面、手机app、以及一些api客户端。随着系统的规模和复杂度的提升，在保证数据处理的准确性、一致性、实效性等方面会面临诸多问题，而这些问题是需要每一个系统开发和维护的RD所要考虑的，这里就会涉及到各种实现or优化方案的设计和落地。这时候便能意识到，代码实现在整个开发过程中占用的比重其实是比较小的，最最重要的是方案设计，好的方案设计能够尽量让系统简化，减少复杂度，增强稳定性性，并且兼顾到未来一定阶段内的功能迭代。

努力成为一个具有设计思维和能力的数据开发工程师，当然是短期内。