我做了很久的项目，发现实验室的人总喜欢在讨论的时候说：只要确定了该做哪些事情，有了提纲之后，就容易了，剩下的事情就是挪代码，无非是搬砖 嘛……
很多场合，我无权拍板去否定他们的决策。但我觉得搬砖并不容易。
首先，能不能保证读懂以前的代码？如果以前的代码或者是从外面拿来的开源代码有副作用甚至说是错误的，能保证在移植之前搞清楚吗？很多同学在编译移 植后的代码的时候，看着编译器的一行行输出几百个warning，却没有输出一个error的时候，往往会很高兴地说“瞧，移过来了！搞定了！”，以至于 这几百个warning一般没有人去仔细看到底是怎么回事。事实上，使代码编译通过大概最多只在移植过程中占了一半都不到的工作量，能不能真正work， 这才是真正头疼的问题，因为代码在老平台下是work的，因此就算查也不容易查出来。
其次，以前的代码在以前的环境中，现在的代码在现在的环境中，移植过来可不可能有问题？例如在windows下和在linux下，api完全是不一 样的，没准还找不到可以替代的api，怎么可能就简单搬砖呢？在这一点上，很多领导也做得不好，领导在一知半解的情况下，然后就说“肯定会有可以替代的函 数吧”、或者说“去网上查一查嘛”。有时候可能是一个很难解决的问题，在制定计划的时候，很可能被当做是一个“肯定能在网上搜到解决方案，因此半天就能搞 定”的问题。
最后，不要小看界面这个东西，学问大了。很多眼高手低的人总觉得界面简单，做界面最没技术含量。事实恰好不是这样，做核心和做界面的难度相当，甚至 可能更难。要把界面移植健壮，需要对底层的机制有非常扎实的了解才可以。而现在大部分人对所谓的消息路由、hook、以及mfc对api的封装机制根本一 无所知，就简单地认为“从网上当一段自绘控件或者是自定义工具条的代码就能拿来用了”，这是很危险的。事实上，他们做起来就会发现，网上根本就找不到能完 全满足他们需求的界面控件，于是只能下一个相似的，然后再“改吧改吧”，结果“改吧改吧”的时候，发现根本看不懂这些代码是怎么回事！于是本来计划做一两 个小时就能搞定的事情，足足做了一个礼拜，最后才发现自己还是不得不转过去学习底层核心的知识才能彻底解决问题。
因此，这就是我们实验室很多任务无法按期完成的原因。以上原因，归结为一个字就是：浮。
http://hi.baidu.com/taotaoya/blog/item/f161f33ed8032bf1828b139f.html