买了不少书,也看了不少书,买书读书过程中,好事、郁闷的事也遇得多。

着重谈谈本版书,听说好的本版作者难找,寥寥无几,我买了不少本版书,发现确实如此,好的本版书确实少。

本版书市场突出现象:

  1. 把作者捧起来;

  2. 动不动就吹捧第一、首创......;

  3. 封面夸张的醒目宣传关键字;

  4. 找托在书评里灌,打压其它同类书;

但,实际情况是:

  1. 作者虚名头很响亮;

  2. 东拼西凑,华而不实;

  3. 内容脉络编排不恰当;主题扣得不好,该讲透的没讲到,不该讲太多的却啰啰嗦嗦;徒有虚名;

  4. 可恨的托,还能说啥呢?

我眼里的好书:

一. 作者可以有两个出发点,我觉得都是可以的:

1.1 积累了经验,自己想提炼出来形成总结 - 我想,很多人有这个冲动吧?包括我自己......,但千万不能以赚钱为主要目的,抱着这种心态,才能心境平和、脚踏实地写书,不会受“快餐文化”影响;

1.2 想提升自己的名气,当然啦,这是很正常的人的需求嘛,没什么不可以的;但是,靠浮躁心态想瞒天过海、靠网摘东拼西凑完成作品,只能换来坏名声。总之,要把写书当成自己孩子一般仔细对待呵护,才能出彩。

二. 作者要从读者的角度考虑问题,懂得换位思考:

一个好的作者,自己对技术的理解是很重要的一方面,但是,我认为,懂得理解读者要什么、怎么要,则显得更重要!基于这点,一本好书的前期内容脉络框架的梳 理,显得尤为重要,你的每一章关注点是什么?章节与章节之间的衔接如何处理?先后顺序怎样安排?等等等等,不是小事情!别急着写,先梳理,每一章节处,也 先构思下。把自己当成读者,想想应该怎么读这本书会比较自然和平滑?

三. 书的内容,出发点要紧扣主题:

问问自己,写这本书,书的内容定位哪些受众者?本书的覆盖范围和层次是什么?

比 如:写的是初级书籍,就尽量设置平缓的行进路线,并以初级内容为基准,更高级的内容,可以引入门,再深入的内容,不应该多讲,但可以授以学习方法,指引初 学者怎么更进一步。再比如,高级技术方面的书籍,你就该多讲点相关知识点,这时候,方法很重要,应该知识点和方法并重,高级的技术,不讲方法,称不上高 级,高级的内容,更要注重“授人以鱼,不如授人以渔”。

四. 具体内容组织方面:

不要总想着在一本书里,把所有知识点都覆盖到,你全部覆盖到了,书的特点、亮点也就没了,你还可以写第二部、第三部嘛。

看 过很多的书,厚厚一部,里面为了把知识点讲透,把有关API方法一下子罗列了3、5页,列了个表,几十、上百个方法或属性,统统解释一遍过去,试问有几个 读者能够仔仔细细完完全全看完并理解的?还不如用到哪些讲哪些,重要的方法加以提炼辅以实例,其余的指明参考出处即可。

代码:避免代码一扔就是几页,有的还没注释,让人怀疑是否抄袭或没责任心。如果按逻辑分段,并分段讲解,会让人容易接受得多......

对于书的厚度,我个人感觉控制在400页上下,是最合适的,再多,可以考虑多册。

每个章节开头有本章讲解提纲,结尾有小结,特别是开头的提纲,我个人比较看重,从中可以帮助你把握你接下来所看内容的关注点。

索引,不管你喜欢不喜欢,反正我喜欢了。

内容,我更喜欢图表结合文字、代码的方式,可能是平时工作中PPT用得多、看得多的缘故吧,图表,更容易帮助你理解内容,直观且形象。

五. 排版及设计:

这是相当重要的一环,封面设计、版式及大小设计、字体设计,乃至纸张选材,就是门面,见面都三分亲了,第一印象很重要,出版社应该注重这一环。

我想要着重说的是代码排版,很多书的代码,用的也是宋体,而非编程专用的等宽字体,写程序写惯了的读者,看起来试想有多么难受啊;另外,有些代码,格式混乱,缩进不齐,或者一行过长直接就折到下一行的顶格,如果再遇到前面说到的连续几页的长代码,天哪......

错别字尽可能少,特别是代码,更应该没有排版错误,没有错别字。

总之,用心写书,用心出书,上面讲到的内容,自然就可以做得更完美。