推荐搞IT的你读读《软件随想录》
Posted dotNET跨平台
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了推荐搞IT的你读读《软件随想录》相关的知识,希望对你有一定的参考价值。
《软件随想录(Joel on Software)》,这是我多年前看的一本书,也是对我影响很大大的一本书。这不是一本讲软件技术的书,但跟技术强相关,推荐给朋友们读一下。
这本书严格来讲,不是作者专门写的书,是对作者 45 篇博客随笔的合集——记录了 2000-2004 年间的工作所感所悟。虽然不是按照时间顺序来的,但整篇文集整体上散而不乱,而且获得了第 15 届 JOLT 大奖,被读者誉为堪比《人月神话》的经典软件项目管理文集。
关于编程本身
软件和互联网行业本质上都是属于服务业:通过服务客户、满足客户需求来赚取利润,简而言之,卖的是服务,是客户体验,谁给客户的体验好,谁就能赚到钱。
所以,为了甲方提供更好的服务,作为提供服务的乙方就得不断地折腾自己,不断的折腾自己,在一定意义上就意味着晚交付,但晚交付对甲方来说就是不好的服务体验。这就是一个悖论。
所以从这点上来讲,Joel on software 就是教我们在整个开发过程中怎么样才能少折腾自己。
在本书中提到了著名的乔尔测试。是乔尔在 22 年前提的,现在已经成为开发团队的标准配置。
你们用源代码管理系统吗?
你们能一键编译吗?
你们做每日编译吗?
你们有 bug 数据库吗?
你们在写新代码前修改以前的代码吗?
你们的进度表是最新的吗?
你们有软件规格书吗?
程序员的工作环境安静吗?
你们使用了能买到的最好的工具吗?
你们有测试人员吗?
你们面试时会要求应聘人员写代码吗?
你们做过走廊可用性测试吗?
乔尔应该特别重视功能规格书,用了整4篇的篇幅来讲功能规格书:
为什么要写
什么是规格书
怎么写
以及写作技巧
归结起来就是:一是:为了减少日后与甲方的扯皮(节省沟通时间);二是:为了自己能顺利实现 feature,防止推倒重来,所以写规格书最根本的是让甲乙双方都看得懂。
乔尔在规格书中必写的内容:
免责声明
作者
使用场景
非目标
概述
细节
待解决的问题
多角度的注解
规格书要与时俱进
其中我觉得 「非目标」 比较有意思。
每个开发者都会认为自己的功能是好的,要非实现不可,但软件开发毕竟付出的是脑力和时间,从效费比上来论,就要去伪存真,把能不实现的就不要去触碰,以减少在非必要功能上铺张浪费,所以在规格书中就明确什么不能碰,真是个非常聪明的点子。
当然,规格书不可能是一成不变的,尤其是在中国这个社会,变与不变都是甲方爸爸一句话的事,乔尔也提到了,产品代码开发完成之时,才是规格书定稿之日。
乔尔在书中提到了五个世界,就是软件开发的五个基本方向:
盒装软件(2C的软件)
内部软件(2B的软件)
嵌入式软件
游戏
用过即抛的代码
每个方向注重的问题不一样,产生问题的解决方法也不一样,如果混淆的处理方法,那就是不断地折腾自己。对于新入行的开发人员来讲,要弄懂你们公司涉及的领域,以及理解老板为什么要这么做,理解了,就会减少很多负面的情绪。
比如乔尔讲「2C」和「2B」的区别:
❝内部软件和盒装软件的一个关键差异就是,在达到某个临界点之后,再投入更多资金去提升内部软件的稳定性和易用性,其边际效果会有明显降低,而对于盒装软件,不断追求软件的稳定性和易用性,永远符合经济定律,都是对公司核心竞争力的提升。所以令人叹息的是,很多内部软件虽然能完美地实现既定的功能,但是质量却非常差。年轻、有热情的开发者经常会被泼冷水,劝他们不要再完善某个软件了,因为已经足够好了,这通常会让他们十分沮丧。
❞
对于游戏和嵌入式软件来讲,乔尔提到只能有一个版本.而一个版本,对质量就有很高的要求,同时面临的经济压力也要求软件尽可能一次到位。—— 这个前提是单机游戏,这可能是因为在 2000 年左右,受带宽的限制,大型网络游戏还没出现,你看现在的网络游戏都是先推出再说,部分有 bug 可定时或随时迭代更新。
关于管理开发者
不得不承认,管理程序开发者团队与其他团队是有差别的。
比如“奖励有害论”:乔尔认为绩效评估会给员工带来巨大的压力
❝评价对于士气的影响是一边倒的:负面评价严重影响士气,而正面评价对于士气或生产效率没有影响
❞
事实上,只要涉及脑力劳动者的,都脱离不了“文无第一、武无第二”的魔咒。文案、设计等工作者,都会对自己的作品感觉良好,奖励是给小部分的人,那么大部分得不到奖赏的人心情难免会沮丧,丧失士气。而且乔尔在评估机能失调这一章节,对这一现象再次进行了强调:
❝每一次试图对脑力工作成果进行定量评估,似乎都会以失败而告终,并且对团队造成巨大破坏
❞
对原有代码推翻重来并不是好办法,曾经的网景公司,被乔尔反复引用. 最主要的一次就是网景公司的战略性错误,网景浏览器发布到6.0beta版,5.0版没有出现,是从4.0直接蹦过来的,6.0往后他们不再做代码优化,而是丢弃以前全部代码,从头开始写一个已经发行过的程序代码,当几年后最终改名为 Mozilla
的浏览器重新上市时,已经没了他们的立足之地。—— 估计现在年轻人都不知道网景浏览器曾经存在过。
普通的团队,我们更期望于一个人能同时开展多个项目,而根据乔尔的经验:
❝如果把一项任务指派给一个人,这个人能很好的完成任务;而当你把两项任务同时指派给某个人的时候,通常的结果是两件事都做不好。这个人要么做好其中一项任务,而完全不做另一项,要么会用比蜗牛还慢的速度同时做两项任务。这是因为在编程任务之间进行切换的时间太长了。
❞
作为管理者要明白: 「程序员是单核单进程的CPU,工作要顺序来」
关于企业发展
乔尔在 2000 年创立了 Fog Creek Software,这本博客合集当然也记录了他的创业所感. 所以,对于从事软件、互联网创业的人来讲,这也是一本启蒙书。
乔尔讲,如果你想在软件行业取得成功,必须有一支完全理解并热爱编程的管理团队,但他们还必须理解并热爱商业运作。
所以关于企业发展,作者用自己在微软和朱诺的工作时的切身经历来阐明管理水平对商业的影响。
乔尔用了 5 个章节专门讲企业发展战略,他提出创业的两种模式:
一种类似本杰瑞的慢慢的、自然的发展;
一种是类似亚马逊这种靠大量资金的投入迅速做大
并指出最不可取的模式,就是在两种模式之间摇摆不定。同时,他也给出了警告,这个行业不能形成标准化的规则:
❝虽然能让任何人都产出可怜但勉强过得去的业绩水平,但同样对真正有才华的人它是一种沉重的负担,限制了他们的发展
❞
总结
书中乔尔在这三个方面的态度:
在编程上,追求效益的同时要少折腾自己;
在管理上,要想尽一切办法促进开发人员的积极性,不做打击士气和积极性的事;
在创业上,一定要考虑商业运作,因为软件行业的本质还是要赚钱的。
《软件随想录(卷一)》45章节的内容远不止讲了这么多。从初入行编程语言选择、开发工具的优劣到软件行业创业,都能在其中找到答案。
可以这样说,只要是从事的软件行业的或者想了解软件行业的人,读了它之后都会对这个行业有一种豁然开朗的感觉,别忘了这是一本快 20 年的书了。本书翻译的有好有坏,翻译比较好的,杨帆译本、阮一峰译本都还可以,当然,英文好的建议直接看英文原版。
关于作者
「乔尔·斯波尔斯基」 :
1991 年,毕业于耶鲁大学,并曾在 Microsoft 的 Excel 团队工作,担任项目经理,负责在 Excel 5.0 中推出 VBA。
2000 年,创立了Fog Creek Software并推出了Joel on Software博客
2008 年,他与 Jeff Atwood 合作推出了Stack Overflow 程序员问答网站。使用为 Stack Overflow 提供支持的 Stack Exchange 软件产品,Stack Exchange 网络现在托管了 170 多个问答网站。
目前,担任Stack Overflow、Glitch和HASH的董事会主席。
以上是关于推荐搞IT的你读读《软件随想录》的主要内容,如果未能解决你的问题,请参考以下文章