《Joel谈优秀软件开发方法》读后感锦集
《Joel谈优秀软件开发方法》是一本由Joel Spolsky著作，清华大学出版的296图书，本书定价：39.00元，页数：2007-7，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《Joel谈优秀软件开发方法》精选点评：
●2年前读过。
●伟大的黑客，激情，团队补偿以及群是其自身最大的敌人等几篇挺不错，其他的感觉一般。
●不错，可以在睡觉之前看...
●泰达图书馆
●Joel点评的杂文集。其中几篇文章的主题倒有不少启发意义。
●'A Group Is Its Own Worst Enemy'
●不错
●非常赞的一本书，作者大部分很强大，Bruce Eckel在其中也只是一颗星而已。
●虽然翻译得一般，但是Joel的编著的此书中的短文对中小开发团队是很Practical的。
●凑凑
《Joel谈优秀软件开发方法》读后感(一)：还不错
书的内容还不错，不过书名实在是有点挂羊头卖狗肉。估计是出版社为了跟Joel套套近乎，Joel的博客和那本大名鼎鼎的《Joel on Software》实在是威名赫赫啊。本书的各章是相互独立的，都是一些大牛写的关于软件开发的东西，再加上Joel的点评。书中的大牛包括：Bruce Eckel，我认为是个书贩子，不过他的Thinking in Java实在是有名；Raymond Chen，《Windows编程启示录》的作者，微软Win32编程的大牛，诸如此类，等等等。由于各章是相互独立的，所以随便什么时候有时间都可以拿来翻翻，获益良多。
www.gossipcoder.com
《Joel谈优秀软件开发方法》读后感(二)：近似无聊的、充满创新的书
从图书馆里看到这本书，想到我在豆瓣上好像也看过，而且评价还不错的，于是怀着千分的期待借了出来，打算好好看一下。
前言，不知道他在罗嗦什么，前面讲了很多莫名其妙的故事，然后又讲了一个很大段的故事，而且故事后说了句“我打赌，您一定宁可看10篇这样400字的故事，也不愿意听人唠唠叨叨地讲...”，纯属放屁，你的故事我一个字也没看，莫名其妙的还不如直接入题，开门见山，我这里没时间听你啰啰嗦嗦。
第一篇，讲的是编程风格，我可不喜欢一辈子做编码人员，因此对你那些啰啰嗦嗦讲的“为什么不在C中用空格表示代码结构”的原因，虽然持非常赞同的观点，但是我敢肯定，在实际中根本无法实现。我是个超级实用主义的人，讨厌这种学院派，到极点。
最让我喜欢的是第二篇文章，两页，而且字数也不会超过300字，两幅大图片，讲了windows的搜索界面如何糟糕，像个不会解决问题的老婆婆。虽然字数很少，但是我却思考了很长时间，并且受益匪浅。
另外一个是用Excel做数据库用的文章，因为我在研究用户界面设计的时候，领略过用户界面需求的荒谬程度，但我在这里还是接受不了作者给我讲的故事——太夸张了，作者是在编故事讽刺一些人还是在说实际的东西？我是个实用主义者，不喜欢编造这么假的故事，即使是真的，我也不会相信在中国这些事情的概率会超过0.001%。
最受不了的是，一篇写C++的文章，我最喜欢的语言，他却说一些人选择C++的唯一原因在于使用了//作为注释，不管他的思想有多创新，但这在让我感到极度吃惊的同时，也让我极度恶心！！而且这篇文章完全偏离了书名所说的“软件开发方法”这个主题，我被作者欺骗了，阅读了那些我实在不感兴趣的c、c++发家史。
《激情》，这个标题完全吸引了我，我知道在软件开发过程中如果一直充满激情，是没有任何困难能阻止得了我的。作者的思路也跟我很相似，他是一名极限拥护者，但是在看他的文章的时候，有些文字让我出离愤怒：“尽管食物大都具备两面性，然而在那段日子里，新的想法总是能够不停地涌现出来，以解决那些原来看起来还不错的负面问题”，“然而有些人开始对我们进行恶意中伤，说我们的想法太激进，不会产生实际作用，还说我们一定是疯了。而实际上我认为这是实际末的狂潮”——一个生活在自己世界里的自恋狂，一个自信地为世界创造“知识”的烂人。我这么说吧，这位作者可能会认为将程序员放到高空位置上强迫他不再乱动可能会提高它的编码效率，他在团队里施行了，而且也确实在一段时间内提高了团队效率，然后他就拿出来掰活，这样这样很敏捷，提高效率。他不知道提高效率的不是这个新的机制，其实这个机制使效率降低，而恰恰这种令人感到新鲜和刺激的改变提高了团队的激情，两者融合才提高些效率。但我敢保证，继续实行，等团队的新鲜感降下来，效率会降到比原来更低的水平。
我就说，程序员思考问题，喜欢创新，但这种创新多半是泡沫；喜欢思考不全面，喜欢钻牛角尖。
最后同样以《激情》中的一段文字结束我的文章，毕竟批评不能将里面的精华也一起扔掉：
·我希望与那些可以和我深入交流的人在一起，而不是那些对此不感兴趣，随波逐流的人；
·我希望能够进行激烈的争辩，就事论事而不带有任何感情色彩。
·我希望可以充分的尊重他人，让他们按照自己的意愿发展。
·我愿意和大家共享我的想法，我坚信我小小的灵感能够带来成倍的回报。
·我愿意通过各种方式与我的同事进行沟通，从而使我的想法可以传播出去，并同时了解他们的想法。
·我愿意尊重他人的激情，尊重他人的信念与思想，就如同尊重我的一样。
·我相信我们这么做是出于真心，互相关心对方。我们欢迎真正的激情，真正的工作以及真正的思想交流。
《Joel谈优秀软件开发方法》读后感(三)：若有所得，仅此而已！
我将此书定位为工作之余，闲暇读物，偶有所得即可。
读每篇文章时，我常常想该文大致对哪种读者有益，如果您有兴趣则听我慢慢道来，请往下看。或许这样您可以按您的兴趣选读文章，既不会错过精彩的文章又可以节省您宝贵时间。
---------------------------------------------------------------------------------------------------------------------
编著者简介，对于有志于软件开发及创业者，可以体味其发展路线，或许会有所领悟。
作者简介，对于欲了解软件行业的职业分布者，则可以借此窥视一斑。
前言，归结为一句话，对于意欲写作者，可以学到优秀作品规则：展示，而不是讲述（Show，don't tell）。也就是学会讲故事。
Ken Arnold，编程风格是主旨，对于想创造或设计一种语言或困于代码标准难以实现者，会有所启示，通过编译器实现开发者遵循统一编码风格。
Leon Bambrick，最愚蠢用户界面颁给：Windows 搜索界面，值得所有软件从业者深思，软件易用性是何其的重要。
Michael Bean，程序员外包的隐患，对于软件企业而言，需要明白核心和战略是不能外包出去的道理，因为这就是您的优势所在。
Rory Blyth，把 Excel 当数据库用，作者尽管有些夸张，但对于开发人员来说，说明需求与实现两者分离确实有益的。
Adam Bosworth，ICSOC04 讲座，对于通过从人性的角度来把握和看清技术趋势的说法，对于每个软件人员来说都是有益的，若是您需要看清技术趋势的慧眼您不妨细细体味其中观点。说的是，一项“简单、灵活、随意的”的技术或许更能够创造价值。
Danah Boyd，自闭的社会软件，对于开发社交软件或社交社区者，或许可以从中体味，技术如何满足人们真正的需要，焦点放在用户上的深刻观点。
Raymond Chen，为何不禁用依赖于未公开机制的应用程序，作者一语道破兼容性与升级及商务之间的问题是其关键，嗯，微软就是如此。
Kevin Cheng & Tom Chi，踢骆驼，谈的就是软件易用性问题！
Cory Doctorow，从 WIPO 中拯救加拿大的 Internet，作者认为这个法律不公而需要修改，而我在想如果谁有办法突破，谁将获益，Apple有点苗头，iPod+iTunes是个好商业模式。
ea_spouse，EA：关于员工的故事，印象深刻的一篇文章，超时加班工作是软件行业的普遍现象，在此我祝愿您在一个有社会责任感的企业就职，在此我同样谴责无良的企业！
ruce Eckel，强类型与强测试，是的，我同意程序是否稳健，并非在于选择语言而是在于您是否充分测试，如果作为开发人员的您还没测试，那您就该好好想想了！因此，我觉得测试驱动开发很必要，当然，作者并没有提出这一点。
aul Ford，Processing Processing，如果您想优雅地编写软件，这一篇虽然长，却确实需要反复阅读，细细体会。
aul Graham，伟大的黑客，如果您想成为一名出色的软件开发人员不妨看看，我最欣赏这一句：要想成为一名伟大的黑客，做自己喜欢做的事情！当然还有其他，好奇心、专注、质疑。如果您是企业家，则您可以从中看出如何找到最合适的人及使其留下来并用好他们的一些门道。
John Gruber，地址栏就是新的命令行，“能用，且用得方便。”这就是历史潮流！换句话说，技术都是为这服务的，而不是相反！
Gregor Hohpe，星巴克不使用两阶段提交，作者以此来说明，观察日常生活（星巴克处理订单方式）有助于我们设计（异步消息处理体系结构）。
Ron Jeffries，激情，作者说为“激情而生”，如果您还想有激情地工作，那么不妨看看，该如何与周围的人相处，或是创建激情的氛围。
Eric Johnson，C++——被遗忘的特洛伊木马，我透过C++的历史，更加理解“伟大而持久的变革也可以通过一系列有目的、有选择的微小步骤来实现。”。
Eric Lippert，更换一个灯泡需要多少名微软员工，“官僚主义”并不是一个贬义词，至少在这种情况下：引入一个特性可能会引起复杂而不可预知的行为或是后果。
Michael "Rands" Lopp，事情搞砸了怎么办，我们通常也会面临责任、雇用、开除和解雇的问题或是教训，这些事您可能也会遇到，过来人如何处理的呢？
Larry Osterman，Larry 的软件工程规则之二：用测试指标来衡量测试人员是行不通的，作者的答案是真实的，这种做法必然局部优化，自然行不通。如果您需要衡量测试人员，您不可不知这一点。
Mary Poppendieck，团队补偿，绩效衡量是一个难题，作者就此做出建议，如果您关心如何激励团队，您一定要看这一篇，相信您会有所启发。
Rick Schaut，Mac Word 6.0，产品因其自身和政策决定成败，对于参与产品开发者不可不知。
Clay Shirky，群是其自身最大的敌人，群作为用户：社会软件的结构与设计，社会软件的成功不在于软件技术而在于是否懂使用软件的群相关的社会学和人种学。可谓是功夫在诗外。如果您是做社会软件或社交网站的，这两篇值得一看。
Eric Sink，填补鸿沟，如果您是ISV或是独立开发者，对于产品与顾客之间的鸿沟如何填补，读此文章应该大有裨益。
Eric Sink，雇佣的风险，说的是招人，反之，求职者读之也会受益。
Aaron Swartz，PowerPoint，说的是PPT，做PPT时可以有些启发。
Why the lucky stiff，与卡通狐狸来趟快速（且希望无痛）的 Ruby 之旅，程序语言入门也可以写得有趣，这是真的，不信你看。如果您想写作，不妨考虑一下这种风格。
----------------------------------------------------------------------------------------------------------------------
倘若您想从书中找优秀软件开发方法，我想大抵会很失望。
倘若您抱着书中各作者的观点对自己有一点启发就满足的想法，不妨可以看看，我就这样看完本书。
若有所得，仅此而已！
《Joel谈优秀软件开发方法》读后感(四)：Joel's shared items with notes
或者你已经知道 Joel Spolsky 是谁，一位有名的开发者，他的 blog 受到不少开发者的欢迎。或许译者认为 Joel 的知名度能为此书赢得更好的销量，所以直接把书名译作“Joel 谈优秀软件开发方法”，与原名“The Best Software Writing I”偏离甚远。或许书名翻译为“优秀软件开发文选”较为妥当，当然这名字很土，词穷的我也想不到更好的名字了。
既然是“文选”，编选者自然是 Joel，而每篇文章之前，Joel 都加上一些文字描述，当作导读也罢，当作是他的读后感也罢，或许给你这像是 Google Reader 中 shared with note 的感觉，当然，分享的对象自然是这书的读者了。我认为此书的英文版本是不值得阅读的：因为原文都能在网上找到，文中也附有原文的网址。但中文版本是值得一读的，这能让因为英文阅读不佳而错失阅读这些文章的人们也能一读这些文章。
这些文章说的是什么呢？
有论述编程风格的，如 Ken Arnold 的“编程风格是主旨”；有讨论开发过程中一些细节的问题，如 Michael Bean 的“程序员外包的隐患”和 Rory Blyth 的“把 Excel 当数据库用”；有关于开发目的一些思想，Adam Bosworth 的“ICSOC04 讲座”和 Danah Boyd 的“自闭的社会软件”；当然也有评击不公允法制，Cory Doctorow 的“从 WIPO 中拯救加拿大的 Internet”就详述地解释了为什么这个法律是不公而需要修改的；有与软件销售以及管理有关的；也有一篇 Ruby 的入门教程节选，你想不到原来程序语言的入门教程也能这般有趣（当然，这是面向入门者的教程，若是想深入了解，自然是需要去钻研一番了）。可以说，对于一个有一定经验的开发者来说，这书能让他/她认识一些新的观点，不管他/她是否接受这些观点。
说这么久，似乎我成了这书的书托儿，拼命地在赞誉这书，希望这书能卖得更好。好吧，我承认这书翻译得并不怎样，一些细节确实需要反复阅读数次，才能理解其中意思。这里附上书中各文的原文地址，看原文也是不错的。