最近在研究程序运行方式的技术细节，看了一个让程序以daemon方式运行的函数，内部调用了fork、open、dup2等函数，约有20行代码，看完csdn一篇博客后发现，其实这个deamon实现并不严谨，而且可以直接调用unistd.h头文件中的daemon函数，于是忍不住感慨，勤奋的程序员会重复造轮子啊。
开发的时候还是得有"懒人思维"，尽量避免重复造轮子，优先考虑使用系统调用、各种公共库函数、第三方工具。人的精力是有限的，节约下来的时间和精力可以花在其他地方，比如为公司干更多的活。《计算广告》作者刘鹏(北冥乘海生)的一句话说的特别对，想要提高自己的薪资待遇，就要努力提升自己的价值，以便公司能剥夺更多的剩余价值。想想是不是这个理？
本周轮到我值班排查客户投诉，在分析问题过程中，忽然意识到80%的问题都是广告无展现，而排查问题的步骤几乎是固定的:先看广告投放单元是否有效，再在调试系统尝试召回广告，然后从大量输出中找到对排查问题有价值的信息，分析广告没有展现的原因，最后写邮件回复。
产品经理问我，能否提供一个更好用的问题排查系统呢？作为本份的开发人员，自然不敢接这样的活儿，我委婉拒绝后，自己也开始思考，如何避免大量重复枯燥的体力劳动，提高问题排查效率？
重新设计一个调试系统吗？除了实现功能外，还得考虑高可靠、高可用，想想都觉得工作量太大，况且最近本来就加班，何必要跟自己身体过不去呢。有没有偷懒一点的代替方案呢？忽然想到只要把广告gateway模块的代码简单修改，就能变成一个简易调试系统，而且gateway基于openresty实现高并发，因此只需要专注lua语言的业务代码开发就可以了。
动手尝试了一下，只改了十几行代码，就实现了根据广告投放单元来过滤特定的广告，结果真是令人兴奋。接下来只需要提取对排查问题有用的字段，并自动输出问题分析结论(以便粘贴到邮件中)，就能提高问题排查效率了！
生活在开源时代是幸福的，优秀的开源软件极大简化了构建大型系统的工作，诸如rpc框架、微服务框架、消息队列、日志模块、高效的编译工具等，开发人员大可不必再模仿造轮子，而是可以做"懒人"，集中精力在丰富和完善产品功能上，同时也有精力去研究某项感兴趣的技术，做一个能提供更多剩余价值的员工。
底层技术永远有用，但是产品需求变化太快，导致对开发效率要求很高，逼得我们去学习和使用更快、更好、更强大的高级开发语言和技术工具。摩尔定律揭示了硬件的提升规律，而软件方面的开发语言、技术工具的发展规律也一直存在，只是不像硬件那样淘汰的惨烈和彻底而已。
愿天底下程序员加班都不是因为排查问题和重复造轮子，而是在完善产品和提高技术。
金句分享
面试造核弹，工作拧螺丝。
——出自网络流行语。
解读：网友对大公司面试考察很全面深入，但是工作分工很细的一种调侃。
