这个标题似乎让人很晕，我也在试图去修改它让它变得更清楚一些。大概已经两个年半过去了，我还是觉得这个想法是合理的。
所谓生活就是在你忙着制定其他计划的时候发生的事情。
复用的概念在软件开发领域已经倡导了很多年了，GoF 的设计模式也已经深入人心。他们提倡模式的复用，代码的复用，软件的复用。当然，这是三个不同的层次。所谓的模式的复用是让一个软件有可生长的空间，让它拥抱变化使你最初的代码不因为新的变化需要大量的重写。代码的复用是将通用功能的模块做成了所谓的类库，避免了程序员重复发明轮子的过程。这种思想也让这个世界涌现出了众多的伟大的类库和框架，它们精心的结构，巧妙的接口让人惊叹不已。真不敢想象没有这些伟大的类库这个世界将是一个什么样子。伟大的东西就像这个领域发展的必然趋势，没有 APACHE 的世界最终也要有一个可能不叫做 APACHE 的角色出现。至于所谓的软件复用就有点说不清楚了，我们很难想像你 windows 里面的某两个软件可以被用于做别的事情。不过根据我目前的知识水平，我多能想到的就是 UNIX 下的一系列软件。那些命令行下的，神奇的 shell 程序。管道把它们连接起来形成了一套可以随意组合的灵活工具。
不过，我没有想在真正的 reusable 上花太多的段落，我们回到第一段的引言。从小到大，我们给自己或有心或无心的定下了无数的计划。我们这里所说的计划是一个方向，是一个按部就班、坚持不懈的达到某个预期目标的过程。它似乎是一个整体，似乎是一连串的动作只是为了最终的那个结果。所谓的功亏一篑就是说你沿着这个道路一路向前却恰恰少了最后一根稻草，是的，少了最后这么一篑你就输了。
那么，真的如此么？真的要这样坚持么？无心插柳：Gmail 作者、FriendFeed 创始人 Paul Buchheit 谈人生偶然性则给我们阐述了生活的另一番场景：无心插柳柳成荫，机会就在我们周围，但被我们的习惯和信念断送。生活的乐趣就在于这丰富的偶然性之中。过分的心无旁骛很有可能断送了巨大的机遇。你真的确定自己的计划或者说是信念就是你达到目的的最好途径么。事实上，个人的信念或者计划总是源自于自己对外界世界信息的分析和理解。当你获取了一个所谓的计划之后就摒弃了最初计划的来源是很不明智的。你最初的计划很有可能是因为你获取了片面的信息而得出的结论，此后的一意孤行不一定能够得到你需要的结果，或者不能很快的得到你想要的结果。
那么，我们应该怎么做呢。我认为很好的把握计划的粒度才是关键。
计划是要执行的，不过绝不能一意孤行下去。这个所谓的计划很可能要根据你的心智的越发成熟而产生变化。我们要做的应该是在这个过程中把计划分解成一个个小的模块并认真的执行这些小模块，让每一段经历都"值得一提"。这和我们的软工原则是一致的：我们让每个模块有自己独立的功能，避免各个模块的过分依赖。当我们发现我们的需求发生了变化，那么原有的模块依然有用武之地。最怕的就是在经历计划的变革之后，我们发现自己原来的工作一无是处了。
下面，我们就要说一说上一段所提到的"值得一提"了。其实，原则就是让你以前的经历有价值，不能因为它是错误的计划的产物就变得一无是处。举个例子，一个人在一个自己不感兴趣的公司做过一份自己不喜欢的工作，没几年就离开了。那么，在这个公司的一段时间是应当有价值的。是的，它在一个完整的计划中是失败的，但是你在这个经历中应该有所收获，而且最好是“值得一提”的。值得一提这个词真的很功利，它就好像是在说如果你去一个新的公司去面试，当 HR 问你以前的工作时，你可以很自豪的说出自己的业绩，而不是无言以对。当然，“值得一提”应该是你真的有所收获并有所成绩的外在表露，而不是夸夸其谈。
所以，请珍惜生活的每一个阶段，不要找任何借口去荒废它。未来是那样的不可捉摸，你永远都不知道自己现在所做的一切对将来会有什么样的影响。请用心的去度过你生活的每一个部分。不论你的计划是什么，它并不重要，重要的是你经历的过程。希望你回首往事，发现自己的一段段经历都好像是给自己留下的无数可重用的优秀代码，自己随手捏来加以组合就可以构建一个伟大的系统。你生活的过程，其实在很大程度上并不是在“做软件”，而是在为了将来的“信手捏来”积累优秀的资源。
我自己在最近的一两年内接过一些外包项目或者和人做一些合伙项目。这些新项目有的已经在被人使用了一些时候了，这我当然很开心。有些项目在我接的时候就知道它注定会失败（真的哦）。但是我还是做了，一个是出于钱的考虑（对于一个穷学生来说，这再自然不过了）；另一方面则是觉得其实这些项目怎么来说都算是"真是的需求"。对的，比学校里的课程大作业强多了。我应该去捕捉这种机会去实际做一些东西。这其实对于很多人来事也算是难能可贵了。我除了关注项目的业务层级的发展之外还可以去关注它的技术方面的发展：这完全是另一个视角。这个项目不论成功与否，我通过实际项目去联系自己的技术的目的达到了。然后，通过踩过的这些坑，我可以在未来的项目中做的更快。
很多人不重视这些的，但实际上这些纷繁错杂的、在实际项目中才能历练出来的各种解决问题的能力以及遇到各种诡异问题的经验的积累还是非常重要的。因为事实上开发工作很多内容就是这些：救火。并且，我也在反复强调，这确实是在比较真实的项目中才能遇到的。比如，我们在平时做自己的项目的时候，我们很少接触百万级或者千万级的数据。而在给别人做项目的时候就会有这些问题。那么性能的问题，内存，带宽这些都会显现出来。我本身就很崇尚实用主义，在实际项目中去学习一些东西对我来说确实非常的适合。