我是如何写作一本软件+哲学式的书籍的（上）
近来，陆陆续续写了快十年的书《完美软件开发：方法与逻辑》终于上市了，这书非常另类，更像是软件+哲学的作品，很可能卖不好，也很多人不喜欢，但一路写来实在是比较坎坷，因此把大致的过程写下来，供想写书的各位参考。另一个自己很想说下的话题是，每个程序员都应该给自己写本书，虽然不太赚钱，下一篇写这个。
非要给IT书分个类的话，我感觉可以分两大类：一类是解决具体问题的书，比如：《C#高级编程》，《Hadoop实战》等等。一类则是修炼内功的书籍，比如：《人月神话》，《程序员修炼之道》，等等。当然也有一些融合的比较好的，比如《代码大全》。自从从事软件开发之后一直想写一本后一类的书，主要原因是自己除了软件之外也比较喜欢哲学，总感觉把哲学的思维用到软件上后，看到了一些别人没有看到过的东西，写出来没准可以超越《人月神话》。这想法不能说错，但其实是个坑，真用心去做的话，很容易就很多年过去了，还看不到什么成绩。现在想想，做这种判断和选择纯粹性格使然，有人喜欢创业，有人喜欢开源，我则喜欢思考一些本质的问题，03年的这篇文章可以算是个旁证《编程本质论》 。 那时候还没有博客，只有文档中心，当时大家讨论的很凶，可惜转成博客后，各种讨论都不见了。
什么事情，如果心里有执念，就会放不下，之后就会转化成一种动力，推着你走。思考也是，就因为持续思考，老感觉自己看到了些特别的东西，因此也就一直断断续续的写点东西。但写这类修炼内功的书，其实很累人，尤其是年纪小，视野不够开阔，实践不够多的时候。写点东西出来，过个一阵，自己看都会感觉惨不忍睹。但不管怎么样，这也是一种目标，虽然不是很清晰，只有模糊的一种感觉。真要想写书的话这点很关键，执念的程度直接影响书写不写的出来，写书不像成为比尔盖茨，需要很多其他东西，最最主要的是能坚持，这个上不给力，特别容易想放弃，因为写书既不酷，也不好玩，还很花时间。
就这样抱着“写本阐述软件本质问题的书”的想法就开始动笔了。这其中有三个比较大的坎。第一个是书的涵盖范围。
大约10年前OO还没有像现在这样有一种烂大街的感觉，所以最开始的切入点是OO，想写成一种关于设计的书。
直接起因是虽然OO大家都说很好，但违背我个人的直观感觉，读OO的程序明显比读非OO的程序费劲。对程序员而言在传统的结构化方法里，主要关注调用，作用域等几个基本概念就可以了，而OO程序里你要关注继承、多态、包含、聚合等等。直观上这等于好处没看到，但先支出了一笔----虽然都说上了规模，其好处自显，但自己没看到终究是不信的。
如果从对立统一的角度看，一物有其优势的地方就必然有其劣势的地方，当它跨越某种边界之后，这种劣势就会表现的明显。这就和说真理再向前一小步就是谬误的道理一样，但关键是边界，你要能说清那里是OO的能力边界，那里是结构化方法的边界。回头想想，这点对写书很关键：在逻辑和事实面前可以承认自己错了，否则的话要相信自己，不管多牛的人，多牛的组织也不能让他强奸个人的意志。
读了很多书，看了很多程序，最终写了篇文章来专门阐述这个问题，后来还以《闲侃分析设计》的名字发在《程序员》杂志上了。我们先不说具体内容，还是说写作过程。
但写了半天发现，从写书的角度看，单只这一个切入点也就只能是一段素材，篇幅远不足够支撑一本书。这时候我才认识到写书要做详细一点的规划，而不是只有热情，但从结果来看，最终结果与最初规划偏差实在是大。
第一版规划的时候，是想专注于设计，以抽象及抽象所需要的基本原则为提纲，打通各种设计方法，比如：结构化分析设计，面向对象分析设计，设计模式，框架设计，契约式编程等等。书名都想好了，那时准备叫《编程基础》。
可写写，又发现有问题了。
一个是在定位上有点好高骛远了，要想把设计挖的这么深，太花时间；一个是发现有点违背初衷。我想写的是一本关于软件的书，而软件里不只包含设计。软件的本质特征也作用于管理、流程这样的领域，最终各种因素汇合才有软件产品。
而要想把管理、流程、估算、开发模型、需求开发、开发与设计这么广的话题串起来又简直不像人干的事情。这时候的关键选择是只写设计，还是涵盖管理、流程这些领域。
琢磨了好一阵，由于比较年轻，还是想整个大的题目，要既有广度也有深度。说是好高骛远也好，不知天高地厚也好，反正自我感觉良好，就是这么选了。这是写这本书的第一个坎，跨这个坎的时候扔了很多写好的篇章的。现在想想，写书的经验可以描述成：你可以好高骛远，但得咬牙坚持，坚持了也能写出来。（待续）
--------------------------------------------------------------
理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。
