[读书笔记]《软件工艺》

该书相关信息:《软件工艺》,Pete McBreen(著),熊节(译),人邮出版,2004年

软件工程的关键问题就在于:“它使我们忘记了是人开发软件”。

 

确定过程,验证过程。

 

所有的软件需求都来自于人,需求的获取无法自动完成,开发者必须和用户沟通才能了解用户的真正需求。

 

彼此学习是软件开发中非常重要的一个部分。

 

而对于如今的很多项目来说设计和实现都已经不再是难题,最主要的困难是在需求分析阶段和需求分析与软件设计之间的交流上。

 

同一件任务被切分而成的小步骤越多,人与人之间传递信息所耗费的时间总量就越多。

 

在项目之间存在的诧异性要比相似性重要的多。

 

如何提前交付,只需更早开始。

 

尽管编程环境已经演变为利于小型团队的形式,但软件管理方法并没有作出相应的改变。

 

软件开发是一个社会性的学习过程。

 

软件开发是一种全新的东西,它融合了艺术,科学和工程三者,最终目的是要为用户提供实用的系统。

 

在需求说明和设计说明之间存在一条巨大的鸿沟,当我们忘记这一点时我们就可能低估软件开发的困难程度,到目前为止还没有任何工具能帮我们跨越需求和设计之间的鸿沟。

 

拥有知识和拥有利用这些知识开发软件的技巧和实践能力是两码事。

 

计算机辅助软件工程(CASE)。

 

技艺是靠实践来巩固的,一旦停止实践,技艺就会生疏。

 

编程是一门手艺。

 

软件工匠的声望也要建立在他们过去成功交付的应用程序和系统之上,建立在他们让用户满意的程度之上。

 

仅仅证明了他学会了如何通过这门考试。

 

同行的认可和推荐是获得更好软件办法。

 

相关的每个人都会努力的提高自己的能力和信誉,力争成为更好的开发者。

 

从业执照无法有效的提供软件质量和可靠性方面的保障。

 

因为软件太庞大太复杂,任何人都不肯能保证其中没有任何错误,在软件领域中由一名可靠的工程师来保证整个工程的正确性的做法是不可行的。

 

颁发从业执照的做法的关键在于他假设通过检查可以提高产品的质量。

 

好莱坞模式。

 

导演和制片人只跟他们了解的人合作,他们可能和这些人有私交,也可能通过声望而了解这些人。

 

他们就会请他们信任的人来推荐。

 

通过向开源系统和应用程序作出贡献,许多软件开发者建立了自己的赫赫声明。

 

如果你能针对10%的用户,并努力使他们获得120%的满意,那么你会获得更大的成功。

 

与少数几个用户建立紧密的工作联系,为他们创建最好的软件应用,让他们获得最大限度的满足,然后这个软件才可以被大批量生产并推向广阔的市场。

 

作品上的签名是连接用户和开发者之间的纽带,它使用户能够看到是谁创造了这个软件,知道如何联系这个作者。

 

工匠应当对作品负责。

 

开发者是凭声望赢得尊敬的,而这种声望一方面来自于他们交付了牢固实用的软件,另一方面也是因为他们积极的帮助用户解决所以出现的问题。

 

测试无法证明错误不存在。

 

软件工匠应该修正所有已知的错误,然后才能交付软件。

 

程序里有九十九个错,改正一个错,现在程序里有一百个错。

 

用户感兴趣的不是便宜的软件,而是能用,能提升自身价值的软件。

 

软件工匠应该花一些时间来考察他们的客户。

 

而成功项目的关键就是让好的开发团队和好的客户一起工作。

 

软件工艺的世界里,开发者为人所知的不是学历,会籍或者认证证书,而是他们曾经做过的工作,只有这些才能真正构成开发者能力的证明。

 

伴随着被认定是某个软件的作者的权利而来的,是需要以私人身份对此软件负责。

 

由优秀开发者组成的小型团队能够开发出优秀的软件。

 

真正的问题是我们为技术性并不太强的劳动付出了太高的报酬。

 

增量式开发,渐进式发布。

 

鼓励软件的最终使用者与软件的开发者交流,这样工作能够进展的更快。

 

希望客户已经完成了该作的检查工作。

 

自动化测试,自动化单元测试,功能测试和验收测试提到了新的高度。

 

高质量的,坚固的应用程序比丰富的特性或固定的交付日期更有价值。

 

在软件工艺中,只有当没有任何已知缺陷存在时,产品才能发布。

 

维护者是一个荣耀的身份。

 

我们有常年使用精致工艺品的传统,而软件工艺正是这种传统的回归。

 

确保你理解了真正的问题,尽全力寻找简单的解决方案,首先在小范围内测试你的解决方案。

 

一个人是否能成为大师级的工匠,决定的因素就是,他是否能够坚持实践自己的技艺,而不随波逐流。

 

掌握技艺的过程需要相当长的时间,因为开发者必须学会评价自己的决策在整个软件生命周期中造成的影响。

 

没有任何一项认证或考试能够证明你掌握了软件开发的技艺。

 

会编程并不等于会开发软件。

 

编写代码是软件开发中最容易的部分。

 

没有反馈的实践只会强化错误。

 

软件开发的一个关键问题就是:如果没有对背景知识的深刻理解,就不可能找出解决问题的真正方法。

 

软件工程的目标是大型系统项目。

 

软件工艺,系统工程,软件工程。

 

唯一正确的软件开发方法就是由过程和文档驱动的软件工程方法。

 

知识被尽可能的包含在机器之中,人只是接受一定的培训来操作机器,这条思路的终极形式就是生产线。

 

软件开发还是一项智力活动。

 

首要的问题是使用而不是复用。

 

如何与用户协作,交流,创建一个良好的设计,并使其不断演进发展,这才是软件工业中真正的难题。

 

软件是针对现行硬件的局限来编写的。

 

在它出错之前一直将其视为正确的。

 

软件开发必须以这种粗粒度的方式进行。

 

软件工程解决这个问题的方法不是在开发者之间进行交叉培信,让他们了解全局,而是不断强调文档的神话。

 

软件开发中最重要的问题是构思和设计。

 

比起技术方面的知识,融入团队的能力要重要的多。

 

我们应该能够在一开始就捕捉到所有的需求,然后在进行设计,然后编码,然后测试。

 

有了富有表现力的高级语言,再加上良好的编码习惯,优秀的开发者可以始终在头脑中保持对应用程序的整体把握。

 

在项目进行中更换硬件或者编程语言将冒很大的风险,并付出高昂的代价。

 

变化的不可避免性则是另一条相关的经验。

 

需求总是极不稳定。

 

工艺学强调个人。

 

工艺学项目会把新东西放在项目早期来开发,从而使不确定性得以提早显现。

 

在小型团队中,你必须先了解团队中成员,然后才能进行估算。

 

他曾经多次按时交付坚固,高质量的应用程序,不值得仅仅为了获得一个项目而削减估算值,并最终损害自己的声望。

 

经验——项目成功的指示灯。

 

工艺学注重个体。

 

由于使私人性质的推荐,他们实际上把自己的声望也押在了推荐人的身上,相信后者能够成功的交付这个项目。

 

不同规模的项目需要不同的过程。

 

挑选开发团队中其余的人是工匠的责任。

 

一个真正优秀的开发者比五个平庸的开发者更有价值。

 

给高产的开发者额外的奖励。

 

软件开发是否能够成功,对问题领域的理解与对技术的理解同样重要。

 

健康的团队总是更加高效。

 

任何一种技术,只要你的团队不熟悉它,它就是极端技术。

 

但也带来了非常高的技术性失败的风险。

 

创业者开发了优秀的软件,带领企业起步腾飞,然后就走上了管理岗位,再雇一批菜鸟来糟蹋自己的软件。

 

这种策略的终极目标是要创建这样一个系统:它具有足够的可配置性,绝大多数变化能够再不断修改代码的前提下得到满足。

 

第二中策略是创建一个简单的系统。

 

尽量推迟为应用程序加入灵活性的时间。

 

需要封装基础设施的3个部分,用户界面,数据库,以及操作系统。

 

他们它们必须适用多种用户界面。

 

软件工匠有责任确保应用程序中没有“错误”的按钮——不管用户如何操作,都不应该成为错误。

 

“为测试和维护设计”需要及其渊博的软件开发知识,只有在多年的实践和学习中才能达到这样的水平。

 

开发者最重要的技能之一就是忘记细枝末节的东西,记住最根本的信息。

 

计算机硬件的速度在不断提升,价格在不断下降,很多以前的经验已经不再适用。

 

软件工程针对的是大规模的,工作量超过100人年的项目,而绝大多数应用程序开发项目与之相比可算是微不足道。

 

用学徒的方式来培养优秀的软件开发者。

 

软件工艺的分权模式是对软件工程的集权模式的挑战。

 

软件开发是一门手艺,它将艺术,科学和工程学巧妙的融为一体。

 

软件开发理应有乐趣,否则,开发过程就是错的。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
This book asks some tough questions. Is software engineering appropriate for projects of less than 100 developer-years? Is the specialization inherent in software engineering a good idea? Can software development even be expressed in engineering terms? It also asks some sensitive ones: Are less experienced developers paid too much, and should senior developers be paid more than almost anyone else in their organization? Should tools that are less than ten years old be used on long-term projects? And at its heart, this book asks the big question: How can we reorganize the process of building software so that it works? The book has some controversial answers: It suggests that we've lost sight of a simple truth—large methodologies and formal structures don't write software; people do. To fix a growing crisis in software development, we need to start by producing better developers. To do that, Pete looks back to a system that has worked well for hundreds of years—craftsmanship. Craftsmanship is far more than a tag for high-quality work. In the full meaning of the word, craftsmanship is a self-sustaining system in which masters arrange for the training of their replacements and where status is based purely on the work you've done. Apprentices, journeymen, and craftsman all work together as a team, learning from each other. Customers select these teams based on the team's reputation, and teams accept only work that they feel will enhance their reputation. Can this full system of craftsmanship work in our industry? Frankly, I don't know. Many entrenched interests will certainly oppose the idea. But I do know that being apprenticed to masters works. It worked for me. I was lucky enough to attend a great university, where I learned much theory (there was less theory back then). What really made the experience shine, however, was an apprenticeship that I served. One of the graduate students took me under his wing. He didn't explicitly teach me, but he showed me by example how a great programmer thinks. Working next to him month after month, I absorbed more practical knowledge about design, coding, and debugging than any course could impart. Later, I joined a start-up in London where I served a different sort of apprenticeship. My new boss showed me that software development was as about people as it was about technology. He helped me understand the business side of the equation and taught me how great development builds personal relationships from a base of technical strength. I “graduated” from these two very different apprenticeships a far, far better developer than I started out. Based on my personal experience, I'm a believer. Working with masters is the best way to learn a craft. This book offers more than ideas about training the next generation of developers. It is also about a philosophy. Craftsmanship stands for taking personal responsibility: for your work, for your personal development, and for your profession. It doesn't matter how you develop software. You could be working 9-to-5 in a CMM level 5 shop, or you could be pulling 100-hour, caffeine-drenched weeks developing the next cool first-person shooter. You could use RUP, XP, or SCRUM—or no process at all. Whatever the structure of your work, the real value in software development is added when skilled developers write high-quality, appropriate code, delivering what the customer needs. Methodologies don't produce these skilled developers. Honoring and practicing craftsmanship, along with the other ideas in this book, just might. You'll do yourself and your career a favor if you spend some time with Pete McBreen's tough questions. David Thomas The Pragmatic Programmers
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值