之前从来没有想过，有一天我也要开始写与生活无关的博客了，以前写的东西都是无病呻吟，年轻的时候确实是，年少不识愁滋味，为赋新词强说愁，现在终于在入职以后的第四个月，经历了一场惨绝人寰的灾难，让我终于开始要正视职场，正视自己的工作。之前的态度完全没有达到工作的标准吧，可能也是太嫩了，不知道水深浅，这次我想借遇到的很大的工作失误来开启自己的博客之路，主要为了纠正自己的编程习惯和学习习惯，也是记录一下自己的收获和思考，希望也能给初入职场的各位码农小伙伴有一些警醒。
故事端倪
刚来公司不久，就被安排了独立做一个实时流的项目，基本的操作就是读kafka的消息，然后对数据进行某些格式的清洗，比如清洗html标签，去图片二维码等。最后输出到mysql数据库，其实也没有多复杂，但是由于流程不规范，加上我的编程能力很差，导致线上出了一堆问题。
事后反思
毕竟第一次上线项目，而且特别怕自己编码能力弱的事实被领导看穿，所以每次出bug都后背发凉，甚至全身都僵直，个中滋味不必细说，就说下现在的一些体会和经验吧。
1. 开始编程之前要先设计好结构。
首先要明确的是最后要做成一个什么样的东西，要使用到哪些工具，比如mysql、kafka、redis等等，他们之间的连接会不会有问题，哪个具有什么特点，适合用来干什么，程序大大框架是什么，分几个模块，这些都是要一开始就想清楚的，不能说已经写了一部分了，才发现没有合适的输出数据的地方，或者说模块之间还有关联，调试起来会互相影响，这些都会给自己埋下很大的坑。
2. 测试要使用和线上代码完全一致的，包括输入和输出。
要想快速定位线上问题，最好的方法就是保持跟线上一样的代码，所以在写代码的同时就要考虑到测试的问题，怎么才能最快地在线上代码和测试代码之间完成切换，因为线上代码的很多环境和配置都是只能在线上用的，所以要准备好一套测试的代码，保证所有的环节都跟线上一致才可以。
3. 定需求的同时应该搞清楚怎么验证。
很多需求写出来，自己简单测试一下是肯定没问题的，感觉一切都正常，可是这个任务里到底有哪些异常情况，出现异常应该怎么发现呢，这里很重要的一环就是测试，在测试的环节里，必须搞清楚你是要测试什么，是格式的问题还是数量的问题，应该从需求分析里发现测试的细节，这样才能保证线上不出问题。如果你每次上线前测试都没问题，但是又总出问题，那你就要考虑重新选择测试策略了。
4. 加报警，加日志。
其实有些问题自己在写的时候也会有考虑到，但是总是侥幸心理，啊这个嘛，不会发生的，其实bug从来不会因为你躲开它就不来找你，所以在写的时候自己就要考虑到会不会有异常情况，如果出现问题，我用什么样的日志才能最准确的定位到问题，这里不光可以捕获代码异常，还要记录出错的数据，到查日志的时候立马就可以针对性地分析case。当然报警也很重要，对于要上线运行的东西，我们必须防患于未然，对于不紧急的问题可以加日志，每天收集进行处理，对于紧急的一定要加报警，出了问题第一时间解决，线上无小事，出了问题谁也负不起这个责任。
5.遇到问题先跟领导交流，不要直接去对接合作方。
这个就是人际上的学问了，之前我不懂，每次对方一发现问题我立马就去回应，说是自己的问题，其实这是很忌讳的，如果你直接回复说犯了一个很低级的错误导致的故障，那你的领导是很没有面子的，而且对方也不会再信任你们团队。最好的办法应该是先跟领导讨论方案，然后再由你的上级去跟对方对接，承担该承担的责任，但是不要乱说话，这是在跟其他部门或者公司合作的基本要求。
这是一些简单的反思吧，当然我非常感谢我的同事们在我困难的时候会主动的帮我，安慰我，还有提点我，大家都是为了混口饭，没人理应帮你，所以这次真的让我清醒地看到，你不能主动地变强，就是在拖所有人的后腿，希望自己能坚持下来，多多学习，多多进步。
网友评论