Software Craftsmanship

Software Craftsmanship pdf epub mobi txt 电子书 下载 2026

出版者:Addison-Wesley Professional
作者:Pete McBreen
出品人:
页数:208
译者:
出版时间:2001-08-23
价格:USD 29.99
装帧:Paperback
isbn号码:9780201733860
丛书系列:
图书标签:
  • 软件开发
  • 计算机
  • 工艺
  • 项目管理
  • 软件工艺
  • 计算
  • 英文版
  • 编程
  • 软件工艺
  • 软件开发
  • 编程实践
  • 代码质量
  • 软件设计
  • 专业性
  • 可维护性
  • 测试驱动开发
  • 重构
  • 领域驱动设计
想要找书就要到 图书目录大全
立刻按 ctrl+D收藏本页
你会得到大惊喜!!

具体描述

Craftsmanship is a return to the roots of software development: Good software developers have always understood that programming is a craft skill. Regardless of the amount of arcane and detailed technical knowledge that a person has, in the end, application development comes down to feel and experience. Someone can know all of the esoteric technical details of the Java programming language, but that person will never be able to master application development unless he or she develops a feel for the aesthetics of software. Conversely, once a person gets the feel for software development, the specific technical details become almost irrelevant. Great developers are always picking up and using new technology and techniques; learning a new technology is just a normal part of the life of a software developer. The term software engineering was coined in 1967 by a NATO study group that recommended a conference to discuss the problems of software. The report from this 1968 conference, which was sponsored by the NATO Science Committee and took place in Garmish, Germany, was titled Software Engineering .1 In the report, Peter Naur and Brian Randell stated, The phrase 'software engineering' was deliberately chosen to be provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering. In the same spirit, it is the intention of this book to be deliberately provocative in implying the need for practitioners to start paying attention to the craft of software development. Software craftsmanship is important because it takes us away from the manufacturing metaphor that software engineering invokes and makes us pay attention to the people who do software development. Craftsmanship brings with it the metaphor of skilled practitioners intent on mastering their craft, of pride in and responsibility for, the fruits of their labor. Software craftsmanship is not the opposite of software engineering or computer science. Rather, craftsmanship is a different tradition that happily coexists with and benefits from science and engineering. Just as the modern blacksmith benefits from better tools, materials, and understanding, so software craftsmanship benefits from better computers, reusable components, and programming languages. Just as blacksmiths transcend science and engineering with their skill and artistry, software craftsmanship can transcend computer science and software engineering to produce great programs, applications, and systems. UNIX and the modern-day GNU Linux are probably the best-known examples of this-;systems that are thriving due to the craft, skill, and dedication of their creators. Software craftsmanship is a response to the problems of trying to force-fit software engineering into commercial application development. Software engineering was developed to meet the needs of NATO in developing very large defense systems. Commercial application development differs from the development of defense and government systems in that applications are a whole lot smaller and normally have to be up and running in less than 18 months. It is rare for a commercial application to be developed by a team of more than 20 people, and most application developers work in teams with fewer than 10 members. Software engineering is good at handling the problems of really large teams of 200 or more people, but it has little to say about how the individuals in a team should practice their craft. Software engineering encourages the human wave 2 approach to software development. Rather than solving the problem of how to develop highly skilled developers, software engineering attempts to deskill software development by suggesting that every problem can be solved by throwing more people at it. Although this approach sometimes succeeds, the resulting software is junk. Slow and bloated, it just never feels right. Users are dazzled by the graphics and animation but never really manage to come to grips with the software. They are thwarted by their inability to learn the software and use only a small fraction of the available features. Software does not have to be like that. All too often I see application development teams shipping valuable applications that provide real, measurable business benefit, but apologizing for not following software engineering best practices. For me, the real test of a team is whether it manages to ship and then enhance and extend the application for years afterward. Timely shipping of the first release is important, but it is more important that subsequent releases occur in a timely fashion and that each new release improves the application. Whenever I'm asked about hiring developers, I tell people to look for developers who have shipped a few applications successfully and then stuck around long enough to handle the next enhancement or maintenance release. Shipping proves that the developer can make something work; staying around for the next release allows the developer to experience the effects of the way that he or she built the application in the first place. If a developer has done this three times, my guess is that he or she is skilled and experienced enough in the craft of software development to be successful again. Software craftsmanship is the new imperative because many members of the software development community are starting to chase technology for its own sake, forgetting what is important. The purpose of software development is to create high-quality, robust software applications that deliver value to their users. What matters is growing a new generation of developers who can do that. Software craftsmanship stands for putting the joy and excitement back into creating applications for our users. 1 Naur, Peter, and Brian Randell, (eds.), Software Engineering: A Report on a Conference Spnsored by the NATO Science Committee, NATO, 1969. 2 Levy, Steven, Hackers, Penguin Books, 1994, p. 88. 0201733862P08202001

作者简介

目录信息

读后感

评分

软件工艺是我比较钟爱的一本书,虽与传统的软件工程思路有出入,但里面有很多思想&思路可以借鉴。其实软件工艺和软件工程并不矛盾和敌对。项目的特点不同,周期不同,我们在做项目的时候确实应该采用不同的策略和方法论。其目的只有一个就是保证项目成功和按期的交付。 1...  

评分

花了俩个晚上一口气读完了《软件工艺》,应该是即《程序员修炼之道》后再让我喝彩的非技术类计算机书籍了,虽然看得是囫囵吞枣,却也酣畅淋漓,解决了我心中的疑惑。软件工程强调的是软件开发的过程,软件工艺则强调软件开发中工匠的重要性,换句话来说,软件工程强调的是管理...  

评分

软件工艺这个观点,我是很赞同的.事实上,我更倾向于把程序员作为一名工程师和艺术者的结合来看待,软件设计,既是一门技术,同时也是一门艺术,至少在现在来说.以后软件开发会如何发展,我们不敢妄下结论 用工匠来比喻软件工程师,用学徒式的教学来培养程序员,这点我想是针...  

评分

(应第二书店之邀而作) 我一直为吃不到口味一致的炸鸡翅而耿耿于怀。每当我面对一堆火候太过的鸡翅时,总是忍不住会想起软件工程——连号称生产过程最规范的连锁快餐店都无法避免品质偏差,我们怎么能对软件工程继续抱有幻想? 看来Pete McBreen也有同感。这位偏...  

评分

终于看完本书,前面提的问题发人深省,但后半部显得比较罗嗦,叙述不清晰。作者提出软件工程存在很多问题,我同意;但是推荐借鉴工匠的做法,对此我不敢苟同。 诚然,软件工程存在很多问题,但是它没有止步不前,随着时代的发展也在演变。例如当前流行的xp、敏捷等不都...

用户评价

评分

我对这本书的整体感受是,它像是一部慢炖的哲学著作,而不是快餐式的技术手册。它没有过多纠缠于语言的语法细节,你不会在这本书里找到关于Python装饰器或Java泛型使用的详细教程,这一点对于追求即时满足感的读者可能会造成最初的困惑。但请相信,一旦你沉浸进去,那种被引导着去思考“为什么我们要这么做”的体验是无与伦比的。作者似乎在不断地挑战我们对“完成工作”的定义。在他看来,交付一个能运行的功能只是完成了工作的一部分,真正的完成是交付一个易于未来理解、易于修改、并且能够持续适应变化的版本。书中对“设计原则”的阐述,如SOLID原则,不再是教科书上干巴巴的定义,而是被融入到一系列精心设计的场景中,让你亲身体会到违反这些原则会带来怎样的技术债务的雪崩效应。我花了很长时间才消化完关于领域驱动设计(DDD)与手艺精神结合的部分,它要求我们将业务语言准确无误地映射到代码结构中,这需要的不只是技术能力,更是一种对业务的深入理解和沟通的耐心。这本书迫使我走出单纯关注代码实现的舒适区,抬头看看宏大的系统架构和长期的维护成本。

评分

不得不说,阅读体验上,这本书的节奏感把握得非常巧妙。它没有采用那种高强度的叙事方式,而是通过一系列的实践、反思和历史回顾穿插进行。例如,它会花一些篇幅去回顾早期软件开发的失误和教训,这种历史的纵深感,让当前我们所处的困境显得不是孤立的,而是人类在处理复杂系统时不断重复的挑战。这种历史的铺垫,极大地增强了“手艺”这个概念的说服力——手艺的传承往往建立在对过往经验的深刻理解之上。在实践层面,作者对结对编程(Pair Programming)的推崇,让我对团队协作有了全新的认识。这不仅仅是两个人共用一台电脑,更是一种实时的知识共享和质量保障机制。我尝试在我的团队中引入一些书中提到的“代码清理”会议,效果立竿见影,团队的整体代码嗅探能力都在提升。这本书对“持续改进”的强调,也让我意识到,软件开发是一个永无止境的旅程,我们永远都在学习和打磨自己的工具箱。它传递的核心信息是:职业的成熟,在于你对自己产出质量的责任感,而不是老板的催促。

评分

这本名为《软件手艺》的书,坦白说,带给我的冲击远超我的预期。我本以为这会是一本偏向于技术栈或最新框架的指南,毕竟“软件”这个词常常与快速迭代的技术挂钩。然而,我发现作者将重点放在了更深层次的东西上——那就是对代码质量的敬畏之心,以及将编程视为一种需要终身磨练的技艺而非单纯的工程任务的态度。书中对TDD(测试驱动开发)的阐述,并非仅仅停留在教你如何写出一个通过测试的单元测试,而是深入探讨了测试如何成为设计过程的驱动力,如何迫使你写出更清晰、更模块化、更易于维护的代码结构。这种思维上的转变,对于那些长期在“赶工期”压力下妥协于“能跑就行”的开发者来说,无疑是一记警钟。我尤其欣赏其中关于“代码整洁之道”的论述,它不是空泛的口号,而是通过具体的、几乎是手术刀般精确的例子,展示了如何重构那些看似无法触碰的“遗留系统”,让它们重获新生。读完前几章,我立刻开始反思自己过去代码审查时常犯的错误,那种对结构美感的忽视,简直令人汗颜。这本书更像是师傅对徒弟的耳提面命,语重心长,却又直指核心,它关乎职业的尊严。

评分

这本书的语言风格极其克制而精准,几乎没有冗余的词藻,每一句话都像是在精心雕琢的结构中找到了最合适的位置。它没有使用那种煽动性的语言来鼓吹某个时髦的方法论,而是用一种近乎科学观察者的态度,描述了哪些实践能够带来长期的、可持续的软件健康。我特别留意了关于“元认知能力”在编程中的作用的探讨。作者认为,优秀的手艺人必须能够清晰地认知自己此刻的思考过程、代码的局限性以及团队协作中的盲点。这种对自我反思的重视,是我在其他强调工具和技术的书籍中很少见到的。它让我们从“工具使用者”的角色,提升到了“工具设计者和维护者”的高度。读罢全书,我感觉自己看待过去的项目时,仿佛戴上了一副新的眼镜,过去那些模糊不清的性能瓶颈和难以定位的Bug,现在都能追溯到更早期的设计决策上的细微偏差。这本书不是让你学会一门新技术,而是让你学会一种新的、更负责任的、更有尊严的编程方式。它确实配得上“手艺”这个沉甸甸的词汇。

评分

如果让我评价这本书对现代开发流程的冲击力,我认为它是颠覆性的,但却是以一种极其温和的方式实现的。它不鼓吹激进的变革,反而倡导的是一种内化的、循序渐进的文化转变。让我印象深刻的是关于“绅士风度”在代码中的体现。这听起来有些虚无缥缈,但作者通过描述如何写出清晰的错误信息、如何保证代码的自解释性、以及如何对待前任开发者的代码——即使那个“前任”就是几小时前的自己——成功地将道德和职业素养植入了技术实践中。这已经超越了传统的技术书籍范畴,更像是一本关于如何成为一个受人尊敬的专业人士的指南。书中关于重构的章节,非常细致地划分了不同类型的重构,从微小的变量重命名到复杂的类层次结构调整,每一步的动机和潜在风险都分析得淋漓尽致。我发现,很多我过去因为害怕破坏系统而不敢触碰的“坏味道”代码,在遵循了书中的谨慎步骤后,变得可以管理和优化。这种赋予读者的信心,是任何标准技术指南都无法比拟的。

评分

当年路过某书摊看见就买了=.= 看来没买错⋯⋯

评分

刚开始读觉得很喜欢很赞同,经过最近的学术reflection发觉书中意见有所“偏激”和绝对。但是也可以看一下,对冲击传统的software engineering概念有帮助。

评分

当年路过某书摊看见就买了=.= 看来没买错⋯⋯

评分

刚开始读觉得很喜欢很赞同,经过最近的学术reflection发觉书中意见有所“偏激”和绝对。但是也可以看一下,对冲击传统的software engineering概念有帮助。

评分

当年路过某书摊看见就买了=.= 看来没买错⋯⋯

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2026 book.wenda123.org All Rights Reserved. 图书目录大全 版权所有