缺乏从整体上把握一件事情的能力。 理想中的状态，是在写一个程序之前就想好它大概分为哪几个步骤，每一步的输入输出是什么，然后每一步中再细化的去分析，直到设计好一个整体的框架，然后再开始写代码。我尝试过先做整体的设计，但想着想着就考虑到细枝末节的事情上去了，最终页没有做出一个整体的规划。 于是，就出现了一些问题： 1. 思维混乱：实际的开发中，基本上是过程式的思维，按照事件的流程走一步算一步。写代码的时候也就经常会发现当前在写的一个X模块还依赖于另一个Y模块。于是又转而去写Y的代码，也许写着写着又发现Y还依赖于另一个Z模块，又跳过去写Z的代码。于是思维就在X，Y，Z之间跳来跳去，最终绕晕了，头脑一片混乱。有时做完一件事情，就忘了接下来要做什么，于是又不得不从头开始想我做到哪一步了，下一步该干嘛。 2. 总是抓不住重点，经常纠结在一些细节的问题上，然而这部分并不是整个问题的瓶颈，把精力放在这些次要问题上，就是浪费生命。有了整体的规划，我应该能自然的看清楚哪些地方重要，哪些不重要。
这三周来，上班和下班的时间是一样的，都是9点半，当然一个在上午，一个在晚上。 还好，我还有周末。 在周末，我才能静静的躺在床上想着，TMD这么忙到底是为什么。 work hard, play harder，那真的是只有牛人才做得到的事情。 也只有在周末，我才会注意到窗台上的瓦力，那个孤独的小机器人。
上周一，出了点小意外。删文件的时候本来要敲： rm data* 结果手一抖，敲成了： rm data * 然后，我上上周写的代码就全没了。。。还好在同事的帮助下，找回了所有的源代码，方法转帖如下，希望以后不会再有机会用上。 ================================== 在平时工作中一般会由于误操作而删除重要文件，其中最主要的是不适当的使用rm -rf命令。文件被删除之后不再显示文件名信息，只能从文件的大小和删除时间等上来判断是否为所需文件，一般需要查看文件内容才能确定，因此找一个文件可能需要恢复成千上万个文件之后才能完成。工作量非常大，最好能够用脚本来实现自动恢复。但是在debugfs的环境下一般脚本无法执行，下面提供几个组合命令及其使用示例，用户可以根据这些命令来编写脚本实现大量文件的恢复工作。当然最后文件的找回还是需要逐个去看才能确定。 1. 把所有删除文件的信息导入文件中 echo lsdel | debugfs -w /dev/sdb1 > dellist 这样所有删除文件的信息列表就被放入文件dellist中了，可以打开文件查看具体信息，也可以使用脚本过滤需要字段。 2. 批量恢复被删除文件 echo “dump /home/find/1.txt ” | debugfs -w /dev/sdb1 该命令可以把inode号为inode_num的被删除文件内容导入到/home/find/1.txt 文件中，也可以对多个文件进行操作，例如： echo -e “dump /root/find/2.txt \n dump /root/find/3.txt” | debugfs -w /dev/sdb1 同样我们可以用脚本来实现，例如： 文件aa中存放的是从dellist中得到的需要恢复的文件inode号列表，格式如下： [root@test02 ~]# more aa 29261925 29261924 29261923 29261922 [...]
在学习中没有问题，那说明你没有思考。一旦有了问题却不请教别人，靠自己能力去寻找答案会很浪费时间，而且可能找不到答案，甚至是找错了答案。 我进步最快的一段时间是高二下学期，那一段时间，很喜欢问问题，不管问题有多简单，只要是我不确定的，我就会去问。但自从上了大学之后，我就丧失了提问的能力。在一个到处都是牛人的环境里，我生怕自己提出来的问题太傻而被别人取笑，所以一直都只是在沉默中学习。如今的我依旧没有提问的习惯。 过于强烈的自尊心，阻碍了我的进步。
第一天，我在写对输入的数据进行排序的程序。数据会分成6块，我先对每个块排序，然后把6块合并起来。我就想用多路归并的方式一次把6个数据合并起来，要用一个堆来进行操作。整体的思路还比较明确，但是写代码的时候很慢。写了一下午也没写完，晚上吃饭的时候和同事提起这件事情，他就说，那你怎么不就先合在一起再排序呢？是啊，为什么呢，我何苦要钻这个牛角尖呢，很小的数据量，用最简单的实现就可以了，整个程序的瓶颈也不在排序上，何必要在排序的细节上如此的纠结？不得不说，在这件事情上也反映了我一直以来就存在的一个问题：不会抓主要矛盾。我总喜欢在细节上花很多心思，却忘了自己最重要的事情是什么。先让程序跑起来，再考虑优化！ 第二天，程序在更新数据库时会报错，而且只有在大的数据量时才会报错。我一度怀疑RRD的update函数是不是线程安全的。然后有同事提醒我，多线程的程序不容易调试，先从单线程开始试，确定单线程没有问题了，再看多线程。问题最终的原因不在程序而是输入有错误，但如果没有他的提示，我就很难定位到这个原因。 多线程程序没有带来性能的提升，我就开始用多进程的方式来更新数据库。更新一组数据时，多进程的程序可以有很好的效果，但是一旦把各组数据串起来运行，性能就突然下降了很多。我很困惑，甚至一度很沮丧。找人来帮我分析了程序的运行状况之后，找到了问题的所在，所有的进程都阻塞在一块硬盘的读操作上了。根据这个提示，我让每个进程负责写不同的硬盘，这样就可以保证不会出现所有进程阻塞的情况，性能也开始变得较为稳定。 不过此时又出现了另外一个问题，CPU的内核态进程占用率非常之高。这又是为什么？另外一个同事提示说，可能是在不断的打开和关闭文件。于是，我意识到了程序中的一个问题，我在更新一个RRD文件时，做了720次update操作，一定会触发720次的打开和关闭文件的操作，能让这些操作变少吗？我在查看update的API之后找到了答案：update方法是可以把所有要更新的内容用数组一次性传入的，那么更新一次RRD文件时我传入所有的数据，也就只需要一次打开和关闭的操作。按照这个思路修改程序之后，程序的性能得到了接近三倍的提升。 提出你的问题，别人也不一定能够给你答案，但至少在交流中能够给你新的思路。上面的事情，就是很好的印证，我总是很幸运的在交流中找到了解决问题的灵感。交流是如此重要的事情，可是现在的我，还是不怎么喜欢交流。