工作近5周，共完成了2个项目（第二个项目已经基本完成测试，准备收尾中）。第一个项目，是用爬虫抓取数据，然后做好 API 供用户使用。第二个项目，是扫描僵尸用户，发邮件唤醒，如未唤醒则关停僵尸用户的进程。
做这两个项目的过程中各有各的体会。
首先，是关于解决问题的方式。做第一个项目时，刚刚进入公司，很难适应工程师文化，加上和同事不熟悉，脸皮薄，不愿意问问题，甚至没有仔细确认需求和工程方式就动手开搞，最终耽误了不少时间。在工程上，沟通极为重要，工程师不是低着头闭门造车的，恰恰相反，工程师们是用集体合作的方式共同搭建一个或繁或简的系统，最终完成个体无法完成的大规模工程。这应该是工程师们在一起工作的最重要意义之一吧。
工程被分割成一张张工单，并不意味着其整体被切割成无关联的个体。在完成工作的时候需要尽可能多的理解工程的有机性。例如我将爬下来的时间序列存入数据库时，每条数据的时间都被我存成了str，于是在后期制作 API 的时候就遇到了一些问题，最后需要通过将其转成datetime来解决。类似的问题说明我在完成某件工作时，并不知道这件工作在工程中的位置与意义，这就需要多问和多做了，在对整体熟悉了以后，自然会逐渐清晰。
其次，是关于单元测试的重要性。其实『单元测试』这四个字，有弱化其意义的副作用。我在做第二个项目的时候，由于内部处理数据的逻辑比较复杂，导致大大小小的 Bug 一大堆，每次提交都认为自己已经做得差不多了，但还是在 code review 时被打脸，来来回回提交了若干次，花费大量时间，甚至同事成了我的人肉 Debug 处理器。最后同事说，你还是写一些测试用例吧，覆盖的情况越多越好。
果然，写了一百多行的测试用例后，将单元测试完成，自然发现了一些之前很难发现的 Bug，无论对我还是其他工程师来说，都节省了大量调试改错的时间，多灾多难的第二个任务也随之迎刃而解。经此一役，我对单元测试的意义恍然大悟，其实单元测试并不仅仅是『测试』这么简单。在『测试』的背后，其实是将代码化整为零、各个击破的写作过程，因此单元测试的写作时间，应当与程序本体同步，也即『写一个函数，就写一个测试』，二者几乎是同步完成的。这样看上去花了很多时间在设计测试用例上，其实是规范了自己的思路和代码，同时大大提高了后期的可维护性。
在明白了第二点（也就是单元测试的真正意义后），觉得自己仿佛突破了一个模糊边界——一个软件工程师和业余代码爱好者的界限。虽然现在代码依然很烂，但是本着对代码负责的态度和对自己职业的尊重，我会把以后写下来的所有代码都同步加上单元测试，配得上一个专业人士应有的严谨。
以上就是我在完成了两个项目后的些微体会。工程师的快乐，是由一个个微小的痛苦组成的。此生竟有幸成为工程师，真是一件幸福的事情。