作为一个程序员，你有下面这些的经历中的一个或者多个吗？
1.好不容易周末和妹子出去溜达一圈，走到某个地方，山美水美人也美，幸福生活才刚刚开始，噩梦来了！一个电话或者QQ消息来了：你开发的这个地方出问题了，赶快去看看，现场急着呢（各种催啊，受不了了）。TMD，整个人瞬间感觉心痛欲绝。
2.今天发版本，下班后自己走了，回家后，一切正常，正当打算睡觉时，加班测试的同事来电话了。兄弟，你这个地方我要怎么测试？逻辑和设计有偏差吧，解释解释……额，是有点偏差，我远程修改，你稍等啊。
3.公司某个同事离职了，结果他写的代码由你来接管，你也称职啊，这天天气晴朗，心情特好，准备好好看看他写的代码，为以后修改什么的做准备。于是打开IDE，开始工作，可一看到他写的代码，差点没把自己气死！代码乱七八糟（估计这兄弟连format都没用），要注释没注释，要文档没文档。我就问你：这还怎么维护？
以上只是程序员日常苦逼经历中典型的3个，我们的苦逼经历犹如B-U-G那么多（数不清！）。
难以对付的bug
这天，现场同事发来一个错误日志，敏捷主管群里@我处理下。错误日志关键部分如图1所示。
根据日志，我的第一反应是写代码的兄弟没有及时关闭I/O资源（文件或者Socket连接），于是根据出错的类名定位到所在模块，再定位到所在方法，结果发现这代码和前面说的场景3一模一样，写的人离职了，没注释没文档，格式混乱，代码量至少以万为单位，我这天彻底没胃口了！没办法，自己一行一行地读出错模块代码，读到最后发现I/O是及时关闭的。
徒劳一番后，没找到错误根源，我只能另辟蹊径。于是建议现场跟踪一下这个进程打开的文件到底有多少。这个在Linux服务器下是很容易实现的，说下操作步骤吧，希望对你有用。
#查看JVM进程ID
$ jps
说明：如果不是Java应用，请使用系统自带的ps命令查看。
#查看指定进程打开的文件
$ lsof -p <pid>
说明：
1.Socket连接也是文件，Linux中，一切均文件，你懂的！
2.有些Linux发现版可能没有lsof这个命令，请自己安装，比如这样安装。
$ yum install lsof
这样一操作下来，现场同事发现这个进程正常的时候，同时打开了3923个文件（有点恐怖）。之后了解一下业务场景，发现根本不需要同时打开这么多文件，业务并发量非常小。在Linux中，单个进程可以同时打开的文件数限制是可配置的，通过这个命令可以查看这个限制。
$ ulimit -n
现场查了一下，服务器中的这个配置是10240，Linux默认的是1024，显然这个值已经被修改过了。这意味着，刚刚报错的那个进程打开了10240个文件后，还要继续打开，所以超过系统限制了，这太恐怖了！
至此，一个大黑锅扔给了我，如果再看到当初写代码的那个兄弟，我太想请他“吃顿饭”了！
程序员，如何愉快地生活
程序员，要想不让你的接班人背后骂你，要想有段完整的和妹子约会的愉快时光，要想凌晨睡得好，要想……只有把自己的代码写好了！可这又谈何容易，这件事情怎么可量化，可操作呢？
写代码的三个梯度
写代码是有梯度的，我自己总结为3个梯度，通过这3个梯度的成长，可以让自己的代码赏心悦目，自然支配自己的愉快时光就容易多了。
这三个梯度是：
1.实现功能
2.优雅地实现
3.赏心悦目
第一梯度：实现功能。这是最低的一个梯度，只要实现设计要求的功能即可，没其他额外的要求。设计要你实现在控制台打印个“Hello,world”，你老老实实地打印就好了。不过，这个梯度仍然有需要注意的地方，最重要的一点就是切勿拿到任务就开始啪啪写代码，这样你就等着一大堆麻烦来敲门吧！拿到任务后，首先要做的不是写代码，而是仔细研读设计文档，不清楚的、有歧义的地方一定要和设计沟通清楚，有些时候，你会发现设计的没那么牛逼，写的文档让人看了云里雾里，设计也有不合理的地方，辛亏你发现了。没把这个问题埋个五百年再暴露出来！看明白设计文档后，自己再构思一下功能的代码设计，在纸上涂鸦式的画画，之后就可以放手干了，这样，第一梯度给自己埋下的祸根会少很多很多，上游的一些锅也被你砸了，不需要人来背了。
第二梯度：优雅地实现。这是在第一梯度的基础上开展工作。实现了基本功能以后，我们该思考如何优雅地实现，这包括以下这些方面：代码中有完整、详尽的注释吗？再过半年，自己回头看自己的代码，还能够快速明白实现机制吗？是不是该详细写一下开发报告，而不是应付式地随便写写然后扔给测试？代码运行后有完整的日志信息，出问题后可以快速定位吗？代码有清晰的格式规范还是密密麻麻的（Eclipse中Format可以简单调节一下格式）？在实现该功能时使用的语言特性是不是最优雅的一种使用方法？代码可以怎样写得简洁、清爽一点？有哪些地方可以使用缓存，不需要疯狂地去I/O？以上是思考如何优雅地实现时众多问题中最值得思考的几个，通过思考这些问题，再及时对自己的代码进行重构，自己在愉快休息时突然被拽回去看代码的几率将大大减少，以后跳槽后被自己接班人挖祖坟的几率也如此。
第三梯度：赏心悦目。这是最高的要求，不光光涉及写代码了，而是一个系统工程。需要达到的目标是：让开发同事看自己的代码时赏心悦目而不是胃口大减；让用户使用自己的代码时赏心悦目而不是骂你弱智或者感觉自己弱智；让测试同事测试自己的代码时赏心悦目而不是各种懵逼，来回找你麻烦；让部署人员轻易部署，没有繁琐的操作步骤；让接班人接手自己的代码后迅速明白自己想干什么以及怎么干的。上升到这个层面，我们做的是和艺术家一样的工作，都力求打造艺术品。
总结
本文结合自己实践中遇到的一些问题，思考总结了程序员如何避免被各种诡异的问题打乱自己日常生活的编码技巧，毫不隐瞒，我也还是个编码菜鸟，希望与诸君共勉，发现好技巧及时分享。
