关于阅读源代码的误区《代码阅读方法与实践》

昨天读到一本《代码阅读方法与实践  》(希腊) Diomidis Spinellis著，翻译的那个人奇烂，而这个著者也有些让我怀疑，看目录时有似曾相识的感觉，不知道似曾相识的那本书是不是他写的（<pragmatic C programming>??）……

就其中两个亮点说：

既然优秀的文学离不开阅读优秀的文学作品的，优秀的pilot也是从观摩老机长的操作开始，为什么一直以来，老板只知道要求程序员“今天完成**任务”？程序员不需要阅读来学习提高吗？长期以来，封闭的商业软件运行模式确实给我们带来这么一种错觉：程序员之间不需要相互学习，因为他们之间根本就没有可供讨论的蓝本！！从一开始，软件就是个人行为，individual behavior，无数程序员心目中的hacker诞生其中，并前赴后继的继续着他们崇拜之路。而这，正也是软件老板所欢迎的，并一直用所谓的伴随加班的高薪和无形的宣传 、社会氛围欺骗着代码民工 coder labor。

软件必须工业化，这是趋势。但不同于物质的、流水线工业的是，作为一项团体的、脑力的活动，更应当遵循关于脑力的科学，交流的科学。

回到代码阅读这一点来说，如作者所说，它对软件工业的发展的重要性，如同文学作品对与文学艺术的地位。stalling 开创的open source GNU项目不仅是一个人兴趣的延伸，一个OS的设计，而是被剥削压迫的程序员对理想中的自由发展的软件文化的初步探索。除了代码，程序员真的什么都没有—— 有谁能证明他曾经为某个被重用无数次，造福无数程序员的程序写过代码？？后人只能看到软件光盘的包装纸上印着microsoft Corp.

程序员的自由来自程序员素质的发展，就必须有大量优秀的代码可供阅读，进一步的，程序员之间，不论肤色，不论种族，不论信仰，可以真诚的交换代码，交换意见。—— 当软件已经成为一种工业，还有什么可以保留的呢？团队合作才最有利的竞争法宝。

可是，以上仅仅是理想而已。

一个是承认封闭的软件工业模式不合理，二是重视阅读代码在现阶段的作用。

我想，程序毕竟不于文学作品，它的创造性不同于文学的创造性，也不同于工业技术的创造性，它的创造性既在人的头脑中，又不在人的头脑中。在头脑中的那部分归个人所有，又很难归团队所有；不在头脑中的那部分归公司所有，跟个人所有的往往有很大区别。文学作品的读者可以见仁见智，但作品只有一个，因为作者只有一个；一个团队的人对软件见仁见智，造出的东西就会很糟糕，因为软件产品也只有一个，而作者有多个。另一方面，与传统工业流水式生产不同的，个人的创造性劳动是以某种神秘的方式融入到整合团队创造中去的，没有套路，因为软件本身包含的人的智能和对世界的重构这两方面的密码，至今尚未被人类破解（这么看来，生物工程似乎在当前更有希望些……）

事实上，正如作者所及，软件工程有一套既不同于individual programming  也不同于traditional industrial production的科学，（想料作者也知道software crisis,however,）软件还有一个重要的组成部分——文档document。过去，程序员确实除了code 以外，一无所有，单现在不同。代码阅读的难度和交流的难度并不全是程序员的错，现行的programming language 本身尚未能发现一种能够恰当反映程序员意图的方式，换句话说，程序员的创造性是被code扭曲的，用扭曲交流扭曲，只能是更扭曲。但文档不同，它的出现，本身就是为弥补代码在设计上跟程序员分歧，可是，software=program,program=code 的观念似乎根深蒂固了……，尤其是在programmer中间也是大量如此的时候就造成了眼下的悲剧……

也该说些鼓气的话了。代码，乃至软件工程的复杂性已经是无庸置疑了，在没有适当的from concept to code的机制时，我们似乎应当把更多的注意力放在concept上，而不是急于code,这样似乎就是自己打自己嘴巴了……再工程实践上，在当前， open source 项目是最佳的选择，积极参与其中，必会获益匪浅。对于一个老生常谈的问题：代码风格code style，应当在大体遵循gnu风格的前提下（毕竟代码是要给社团里的人看的嘛） ，一律以个人的设计意图为出发点——一味的遵循某些迁就编译器啊，分析工具什么的，着实每这个必要。