程序员需要知道的97件事

架构师需要知道的97件事(参看InfoQ此前的报道)之后,该系列来到了本期:程序员需要知道的97件事。这些内容都是通过wiki搜集的,我们欢迎大家群策群力,请说出你的想法。

在本文撰写之际,该wiki上已经有88个条目了,现摘取一些条目列举如下:

InfoQ有幸采访到了程序员需要知道的97件事的编辑Kevlin Henney以深入了解该项目。

97件事系列始于软件架构师需要知道的97件事,然后就是项目经理需要知道的97件事,现在轮到了程序员需要知道的97件事。每一主题都是由众人群策群力并发布到wiki上,大家可以对其进行编辑,然后从中选取97个条目形成最后的图书。

这些参与的人们通过声明、邀请、推荐以及口述的方式献计献策。软件架构师与程序员项目(Software Architect and Programmer projects)走的更远,这样只要你有足够的兴趣和动力就可以参与进来。内容则来自于博客、争论以及Programmer和Twitter( @97TEPSK)。

通过为所有的贡献应用Creative Commons协议再加上开放性使得整个项目达到了开源项目的品质。即便是在图书出版后,项目wiki仍然接受大家的建议,目的就是搜集更多的信息。

在架构师需要知道的97件事完成之后,为何又开始了程序员相关的话题?

为什么不从反方向来看呢?毕竟在软件开发领域中,程序员是比软件架构师更庞大的群体。

架构师需要知道的97件事是这个系列的第一本,也是我们的第一次尝试。在考虑按系列出书之前,我们把它当作是一本独立的书籍。Richard Monson-Haefel曾希望将自己正在做的“架构师需要知道的10件事”加到Bruce Eckel所维护的列表中,我们从中获得了灵感,之后整个系列就蓬勃发展起来了。

有一次我在检查代码中的疏漏,发现自己不知不觉地在嘀咕“Dammit,这是每个程序员都需要知道的事情!”(当然了,我一开始的感觉是非常强烈的),这就是这本面向程序员的图书的灵感来源。“每个程序员都需要知道”触动了我的思绪。我曾经写过各种值得推荐的做法和值得考虑的问题,但却将其放到了软件架构师这本书当中了,同时发现集体的智慧是无穷的。

该项目面向哪类程序员呢?

这本书面向所有程序员。它并非是一本教你如何做的书,也不是一个介绍性指南抑或是程序员需要知道事情的权威列表,而是来自于各种视角和经验的对程序员有价值的知识片段。有些程序员可能会发现这本书对他们应该知道的知识进行了补充和增强。另一些程序员会感到这本书填充了其知识和经验上的沟壑而无论他们的经验水平到底处在哪个层次上。还有些程序员会发现这本书在某些地方与自己的经验产生了矛盾,这种方式更能激发大家的讨论,非常棒。

大家既能随需阅读这本书,也能深入进去;既能用于群体学习,也能自己细细品味;同时它也是一本很棒的床头书(很多面向程序员的图书都不具备这个特质),当然了,大家还可以在等飞机、地铁或是公交车的时候用这本书消磨时间,只要天气允许就行。

这个系列还会有第四本书么?

97件事系列还在继续,我们当然希望还会涌现出更多的书。虽然不少项目已经被提出,甚至已经试验性地开始了,但现在我觉得这些项目还没有达到能够出书的程度。

没什么具体的模式——软件架构师、项目经理、程序员、DBA、业务分析师、UI设计者等等——因此该系列并不会按照这种方式来组织。没有什么东西会限制这些书籍与软件开发的的具体关系。每个项目都是单独提出并由一个编辑来管理,因此选择的决定权在于编辑,同时他也是项目的驱动者。

现在每个读者都一定想知道为何条目的数量正好是97呢?

这些都是精华所在:-)

这么说没错,但这个理由实在没什么说服力,其实也不是真正的原因。之所以97是因为这个数字很接近100却又不是100,然而太接近也不怎么好(比如99或是101)。大约是100,因为我们考虑到了很多短条目,每个条目占两页,正好符合纸质图书的页数标准。具体的数字97是由Richard Monson-Haefel决定的,他是架构师需要知道的97件事的编辑,这也是该系列的第一本——毫无疑问,97件事系列的其他图书在某种程度上也要遵循这个模式!

如果条目太少,那么每个条目就会变得很长,多样性也会降低,变得更像是普通的文章,这会降低参与者的积极性,最后的图书可能就变成一个小册子了。如果条目太多,那么每个条目就会变短,看起来就像是摘要一样,最后的图书也会变得太长了。

请访问程序员需要知道的97件事的wiki以了解更多信息,同时别忘了看看条目列表

查看英文原文:97 Things Every Programmer Should Know

你可能感兴趣的:(设计模式,项目管理,软件测试,twitter,出版)