作者：henrystark henrystark@126.com
Blog: http://henrystark.blog.chinaunix.net/
日期：20141109
本文遵循CC协议：署名-非商业性使用-禁止演绎 2.5（https://creativecommons.org/licenses/by-nc-nd/2.5/cn/）。可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接。如有错讹，烦请指出。
这篇blog是为了鞭策自己而写。要讲的理念是我认同，而尚未完全做到的。
很多人学CS大概是处于无奈，被调剂到这个学科的。他们也以此为借口不去好好学习，或者觉得CS学起来太难。开玩笑，以为土木工程和工业设计学起来就简单了吗？不论哪个专业，想要学得好都要付出一些努力，乃至拼天赋。学CS，只要你智商没问题，肯付出时间，一定学得好。可惜，大多数人浪费时间来刷weibo。
做课程设计的时候，求捷径，想抄别人的，能完成任务就好。做项目时，遇到问题，就找人问这个该怎么解决啊。或者靠蛮力乱搞一通，重启、换系统，搞七搞八，最后侥幸弄好，自己还没搞清楚原因。我想说的是：这世上没有捷径可走，你看起来像捷径的，肯定是走起来最远的路。当然，写blog不是灌鸡汤。所以我们来分析下现象、原因，然后以我自己为例来剖析事实。
为什么会有走捷径的想法？
1、没能力，是平时没有花时间积淀，没有练习，等到真正用的时候傻眼了，没办法，只有抄别人的。2、不重视，课程设计、毕业设计、项目什么的，能应付过关就好，“哥在乎的又不是这个”。3、没时间，有别的事情要忙，有些高手同时在搞ACM、搞其他更有价值的事情。4、就是懒，有些人很怕拿不到好的成绩，却总是不愿意自己做，不相信自己的能力，到头来只能靠别人拯救自己，也可以归类为依赖心理。
以上这几点原因，只有第三点情有可原，其余几点大致可以视为“对CS没兴趣，不想做，就是混学分的”。有多少人是这种想法呢？很多，多到惊人。我也抄过作业，但是，我会弄懂每一个地方。既然学了CS，就要对得起自己付出的时间，尽量把他学好。
那遇到问题怎么办呢？找捷径就是他们唯一的解决之道。问别人，到bbs上发帖子，期待有高手能说出原因。不可否认，发帖子有一定的作用，可能给出一个大方向。但是，但是，长此以往，自己除了“经验”，什么都没积淀。而这些经验，只是靠记住的，下一次就不一定有用了，对自己的知识体系、职业发展毫无益处。真正有用的方法是：看书、看文档、看手册，遇到现象就推测原因，逐个排查验证，总能定位问题的。可笑的是，某些做科研的，还在说网上提供的资料不够全，写个程序很费力气，我只能说，没写好程序的能力，就不要科研了，没用的，搞出来的东西也是瞎搞。经过了这么多年的教育，不能依靠强力的逻辑框架来学习、来分析问题，实在是一种悲哀。我们学习的单一变量法难道没用吗？你遇到实验室电脑不能上网是怎么排查的？其它问题呢？能不能用科学实验方法来定位？
中国学生不喜欢CS是有背景的：从小只知道埋头做题，动手能力不强，对着冷冰冰的屏幕，丝毫找不到兴趣点。另外还有奇葩的一点是：接触计算机的时间太晚，以至于认为自己没信心排错，看着屏幕上输出报错，一下子慌了手脚，认为自己弄错了什么，期待重启一次程序，伟大的电脑就能恢复正常。简而言之，没有逻辑性。计算机输出每一条错误，都是有原因的，不神奇，排查起来虽然麻烦，但总能追本溯源找到。
近期遇到的问题有：1.网络多流并发吞吐率不行 2.多进程并发测试TCP结果不对 3.VM编译内核，重启遇到错误“wait for network configure...”
那么，遇到这些问题的人是怎么解决的呢？靠蛮力，举例来说，一次测试不行，搞第二次测试，一直找到自己满意的结果。或者切换环境，软件或者OS什么的全都换一遍。我们来按正确的逻辑分析一下：
第一个问题，网络多流并发测试吞吐率不行。那吞吐率由什么决定呢？数据量和时间。数据量可以分解为：客户端发出的请求、服务端回应的数据。时间可以分解为：处理请求的时间、网络传送时间，即RTT。于是我们得到thru = perresponse * n / (dealtime + RTT)。其中，perresponse是服务端每个回应数据的大小，n是在dealtime+RTT这段时间内，服务器实际回应的response数目。于是，限制条件很快理清了，有这么几个原因：服务端处理时间过长、处理请求数目较少或者RTT增加。接下来逐步测试，分析数据就可以了。
第二个问题，多条流TCP并发测试结果很怪，各条流直接胡乱抢占。那很好找原因，先换个并发测试工具看看，如果还是这样，说明TCP实现有问题，可能是系统问题或者算法问题。是系统问题的话，如果部署很快，直接用别的机子再测试，如果部署代价太大，直接捕包看网络流量变化，推测算法实现出了什么问题。
第三个问题，比较麻烦，耗了我很多时间定位问题。编译了一个内核，启动时发现没有eth0，于是从interface-config、启动脚本、驱动模块等角度查找原因，最后定位到是make menuconfig时某个模块支持没有编译进去。于是重新编译解决。这个问题给我的启发是，一定要弄懂脚本做什么。其实本来没必要编译新内核的，只是因为没注意到脚本多写了一个参数，导致协议出错。
根据逻辑驱动的方法，可能做起来很慢，但是总能找到原因，而且为下次定位错误提供了经验。蛮力、乱撞、靠死记、参考别人的方法，总有一天会陷入死胡同。
本文随性而写，本来技术博客不该写这些主观性很强的东西，但是看到tombkeeper关于【如何让黑哥将多年的功力传授于我？】，就把深藏已久的想法说出来。这只是个人观点，不喜勿喷。
原文：http://blog.chinaunix.net/uid-28387257-id-4608873.html