看到里面说道Linus以重用 Minix(一个用于 P C 机的迷你型 U N I X 类操作系统)的代码和理念作为开始,引领几千名散布在全球各地的开发者们,利用业余时间,仅仅是通过 I nternet 这种脆弱的合作,就鬼斧神工般地造就了一个世界级的操作系统。
这突然让我想到小米在出手机前的MIUI,就适配市面上一些主流的机型,每周发布(Linux当时也是每周发布),让很多用户刷机来用,及时发现和提出问题,并且提出一些有价值的建议。记得当时买了一部摩托的Defy,刷了MIUI之后觉得系统好用了很多,基本的拨号、短信、通讯录都好用很多,虽然问题也不少,但这种参与互动的感觉以及本身有很多两点的功能就吸引用户投入,自愿当小白鼠,自愿奉上自己的建议。 当然这个和Linux的开源合作不一样,但总有些共通处。
书中提到作者在遍寻一个好用的邮件客户端未果,着手写一个时(准确说的是在现有的好的开源代码上完善一个),总结了几点:
- 好的软件作品,往往源自于开发者的个人需要。但太多的软件开发人员并不需要也不热爱他们正在开发的软件,他们把编程当差事,为的只是拿薪酬。Linux世界里可不是这样——也许这可以解释为什么 Linux社区里原创软件的平均质量是如此之高。
- 优秀的程序员知道写什么,卓越的程序员知道改写(和重用)什么。
- “计划好扔掉一个吧,迟早你会这么做的。”(Fred Brooks,《人月神话》第11章)或者可以这么说:在你第一次把问题解决的时候,你往往并不了解这个问题,第二次你才可能知道怎么把事情做好。所以,如果你想做对事情,至少要再做一次。
- 如果你有正确的态度,有趣的事情自然会找到你。
- 当你对一个程序不再感兴趣时,你最后的责任就是把它交给一个可以胜任的接棒者。
其中,对第2、3点有点感触。
对于第2点,Mike Gancarz在《Linux/Unix设计思想》中曾经提到过软件开发人员看完别人的解决方案时经常觉得自己也可以做得更好,于是花费大量的时间去重新造轮子,事实上不一定超越现有的,何况也耽误了他们做其他的事情。我想,除非仅仅是为了练手,不然,在正当途径下不要为了证明自己很牛就从零开始去做,大可借用现有的源码来改造提升(除非现有成果真的是烂的一塌糊涂),甚至买一些合算的商用组件集成到项目中也可以。例如,我们在做一个项目时,因为客户需要做很多的统计汇总的报表,但这个不是我们的长项,也不适合花太多人力和时间成本。以前的做法是让一些本身就不很懂业务的项目经理带着初级的开发人员做出来一个配置超级麻烦、功能简陋的模块。后来的人要去看懂维护这段代码很痛苦,何况功能本身就远远不够用。后来的项目渐渐采用市面上比较成熟的报表软件,集成到我们系统中,而且花在软件上钱不比我们自己去开发维护来得多。
对于第3点,我记得项目中“会议系统”这部分的代码相当乱,就像你不想走进一个多次未冲的厕所一样。这是以前请的一个外派开发人员写的, 本身就是赶工出来的东西,未经仔细考虑,而且也没重构。但是很多人看到这部分代码还是忍着臭味继续用,本来就不是很多的代码,其实如果好好重构甚至重写一下,后期这一块的维护和修改演进工作会顺利省事很多。大家往往就看到当前为了修改一小个点,如果去重构整个代码,感到很不划算,懒得去动