程序员修炼之道（影印版）
出版社:中国电力出版社
出版日期:2003-8-1
ISBN:9787508307985
作者:Andrew Hunt,David Thomas
页数:352页
内容概要
Andy Hunt是一个热心的木工和音乐家，但他似乎作为顾问时更受欢迎。他工作过的行业有电信、银行、金融服务和公用事业，还有一些外来领域，如医学成像、图形艺术Internet服务。Andy擅长于将实践已验证的技术和前沿技术相结合，创造新奇而实用的方法。Andy在北卡罗莱纳的Raleigh拥有自己的顾问业务。
书籍目录
1,Apragmaticphilosophy
2,Apragmaticapproach
3,Thebasictools
4,Pragmaticparanoia
5,Bend,orbreak
6,Whileyouarecoding
7
作者简介
本书直击编程陈地，穿过了软件开发中日益增长的规范和技术藩篱，对核心过程进行了审视——即根据需求，创建用户乐于接受的、可工作和易维护的代码。本书包含的内容从个人责任到职业发展，直至保持代码灵活和易于改编重用的架构技术。从本书中将学到防止软件变质、消除复制知识的陷阱、编写灵活、动态和易适应的代码、避免出现相同的设计、用契约、断言和异常对代码进行防护等内容。
图书封面
发布书评
精彩书评 (总计6条)
-
Pragmatism in ProgrammingPragmatism is the philosophy where practical consequences and real effects are vital components of meaning and truth. ----WikipediaThe Pragmatic Programmer: From Journeyman to Master is a book where pragmatism is applied to software development and enlightens readers immediately. Like the authors said, what distinguishes pragmatic programmers is “an attitude, a style, a philosophy of approaching problems and their solutions”. When we accomplish that, we became skillful craftsman in programming.I am also fond of the authors’ description of programming: programmers work small miracles everyday. Instead of oil or blank paper for painters, or musical notations for composers, codes or modules are utilized by programmers to construct invisible mansions. So, programming is as abstract as painting or composing, converting our thoughts to codes to solve problems, and further, to make our products elegant and flexible enough to satisfy the customers’ elusive requirements. Good codes are simple, well-organized and beauty-revealed. Bad codes are difficult, cumbersome and higgledy-piggledy. No programmers are born with the gift to write elegant codes. There are ways to follow to be a pragmatic programmer. Those were the experiences which were come up with by our masters through careful everyday thinking and lots of tests and failures. Standing on their shoulders, we grow faster. This book provides those shoulders.Below are the rules I learn:Rule 1: Take your responsibility.This is the most impressive rule I have learned. It informs me how important to stay honest and direct to our mistakes or errors. Don’t fantasize that you have written a perfect program which will work like a charm everywhere. Problems are unforeseen. It’s a matter of when, not whether, error will be generated. When things go wrong, you have to be brave enough to admit our ignorance or neglect. Blaming others are often lame excuses, useless to produce a better consequence. Pragmatism here tells us to think in the large context, then to provide our options.Rule 2: Be a catalyst.The authors begin this chapter by telling the stone soup story—no villager is willing to serve the hungry soldiers a meal because food was short after years of war. But the soldiers succeeded in producing a large pot of steaming soup by boiling a stone soup and asking once a time for one kind of ingredient from the villagers. The story tells us that, people find it easier to join an ongoing success. If you provide a way that they participate by contributing a little resource, just like the soldiers in Stone Soup story, they are mostly willing to catch and follow. A catalyst works in software development just like that, he come up with a good idea and works it out, then shows it to the colleagues and attracts them to automatically participate!That’s the wisdom from everyday life. People are finally the objects we are dealing with, no matter how complex system we are working on. To satisfy people’s needs is the software’s purpose. Sometimes how wise we are while developing software depends on how well we know about people.But that doesn’t mean we have to be a psychologist. Some of their conclusions will do us a lot of good where possible. In the Stone Soup story, for example, a special trick--- boiling the soup and attracting the villagers’ attention and asking a small favor once at a time---is played to go against the “start-up fatigue” and achieve what we want. Rule 3: Never live with broken windows.Software development is easily affected by people’s psychology. Many chapters have this idea popped up into my mind. So does this one.The authors show us how a clean and inhabited building was influenced by a small broken window: A broken window in inner cities will cause a sense of abandonment. As people leave it unrepaired and any substantial length of time goes by, another gets broken and people start littering. Gradually, it becomes real abandonment.Similar thing could happen in software development. When a small flaw of the current system is discovered, and developers leave it unhandled, a broken-window mechanism is triggered. “Software rot” is not far away. The more pragmatic way is handle the flaws (wrong designs or architecture) immediately it is discovered. At least board it up when time is limited, and remember to fix it later.As a project leader, we have to consider similar kind of impact on the team’s psychology when making a decision. Otherwise even the best develop team might experience a ruin and decay during the development.Rule 4: Learn. Learn. Learn.The programmer’s most valuable asset is their knowledge and experience. But new techniques, languages or environments come up quickly and the market always changes at an amazing speed. Along with this process, our old assets go outdated fast.Therefore, the ability to be a quick-learner and to adjust to the change is critical for a pragmatic programmer.The authors encourage their readers to learn different knowledge. “The more different things you know, the more valuable you are.” They claim.But this book is a little misleading here. If you stop right here, throw away the book, can’t wait jumping into the magazines or technical books, you will probable end up tiresome, with your brain occupied by pieces of unorganized details.Think critically!Reading simply for killing time is useless. Only by careful examination of what you hear or read can you learn the wisdom, and apply what you learn to your development approach. Besides, instead of memorizing every dogma you read in a book, asking WHY and HOW anywhere you get confused, and finding answers to your questions, it raises your interest and colorizes your learning process.Also, choosing what to learn is like selecting which stock to buy. The authors use the word “knowledge portfolio” to imply that investment skills are needed when refreshing our brain.One guideline I remember clearly is that: Don’t put all your technical eggs in one basket. The authors inform us that, there exists a technology spectrum of risk, from risky, potentially high-reward to low-risk, low-reward standards. Span yourself in that spectrum.Those are the rules I’ve learned. And I am sure there is still a lot that I can talk about. I realize that pragmatism sounds reasonable and is an attitude that deserves trying in software development.I myself tend to like pragmatism, because I have believed for many years that action speaks louder than words. Only the practical consequences can prove whether our thoughts are right or not. It is useless to be a giant in thought but a midget in practice. -
我看的是英文版。作者的文笔没得讲，简洁有力。印象最深刻的是里面一句话：“Think about your craft.”翻译过来大致是，思考你手头上的工作。为什么？我的体会是，人是懒散的动物，一旦习惯了某种模式，他/她就会顺着这个模式不经思考地做下去。这样的结果是，人的状态就保持在这种状态下，不会进步也不会退后。要突破这种状态，就应该时时思考，思考怎样把工作做得更好。用脑袋的状态，是最好的状态。 -
如题，中文版和影印版我都有，后来中文版送人了，实在翻译的太烂了。建议过了cet-4的程序员都看影印版
精彩短评 (总计12条)
-
程序员的床头读物。 -
温故而知新 -
软件开发人员必读 -
无必要翻译 -
不知道为什么，这书实在是看不进去，可能是自己还没到哪种层次吧. -
thoughtful suggestions. -
原来以前只知语法 -
不错的书，推荐给每个软件工程师 -
good book -
好书 -
书评留坑 -
知道这本书的感觉，就好比大学毕业10年以后才知道未央歌一样，早过了这年纪了, WTF。
现在每次给新人上课，必推荐。希望他们可以不必像我那样，付出很多年的代价，才理会书中提到的一些浅显但是重要的道理。