# Joel On Software
[Joel On Software][1] Joel谈软件 / 软件沉思录；
我想:只有真正经历过大规模软件开发并且在其中痛苦挣扎过的人才能体会到这些软件方法论的精妙之处吧！ 如果是刚开始学习编程的我，大抵会对这种文邹邹的东西嗤之以鼻:“软件需要什么方法论？” "talk is cheap, show me the code " “这些东西肯定又是文科生弄出来的吧”。 然而零零散散的参与了几个中等规模的软件项目之后， 我总结出一个规律： 软件项目无一例外的让人觉得充满苦楚，参与项目开发的我们总归是在和各种各样的痛楚作斗争，并且最终作出妥协。 我也开始反思项目苦楚的源泉究竟源自何方。 所有谈软件工程的人或多或少对这些问题有独到的见解， 唯独Joel的文章读起来几乎每一篇都有相见恨晚的感觉， 于是一个被神化的Joel形象在我的心中树立起来， 我开始一篇篇翻阅他的文章， 就像哥伦布当年发现了新大陆一样， 然而翻开第一页的时候就发现：原来Joel的这番话早在10年之前就已经说过了。
我知道：光光读一遍是不能加深我对这些问题的认识的；光光像读小说一样读一遍是不够的，后来刚好看到ruanyifeng的博客上贴出某家出版商要集结出版软件沉思录的第二版中文翻译，觉得这是个不错的机会。 一来，可以加深我对这些问题的理解。二来，能参与翻译一本喜欢的书确实是一件荣幸的事情。 于是不假思索的就给ruanyifeng先生发了封电子邮件表达自己对这件事情的兴趣，ruan先生很快帮我联系上了出版社。 试译还算顺利，然后开始正式翻译。没曾料第一遍交稿的时候一下子就被出版社拒绝了。 事情发生的就是这么突然， 原因是因为译稿质量达不到他们要求。 我的翻译水平确实有待提高，不过这跟双方的期望也有关系， 我原来设想的模式大概就跟写代码一样，初稿，然后一遍一遍改。 现在的出版社哪儿经得起这样的折腾， 一看初稿质量比较低，然后就直接结束了这件事情。 当时心有埋怨，现在想想还是我的想法太幼稚了。不过我始终觉得我的想法没有错，我甚至觉得未来的翻译必然会走这样的路线，整个翻译流程就是像github上面合作项目一样的，一遍一遍的改，每一遍修改的痕迹都会被保留下来。 对比第一版和最后一版肯定是完全不认识的感觉。
参与翻译的这些文章虽然出版是无望了，我还是按照原来的思路来翻译这些文章。 这本来就是件有意义的事情嘛， 而且起笔的时候Joel在我心目中仍然是”神“一样的存在，我能感觉到文章里程序员之间的那种共鸣。 到2013年底我终于粗粗翻译完了所有的文章。 到这个节点为止始终没有我理想的工具来完成我想的那种工作流，我所有的翻译都是使用word完成，没有办法留下修订的历史，这个过程已经损失了很多对原文的修订历史了。 直到2014年 gitbook进入我的视线， 我更加坚信我原来的观点是对的， 图书/翻译会越来越像一个软件工程。（截至写稿时已经有大量gitbook的fork产生）
这些是翻译这些文章集合时发生的小插曲。回到Joel谈软件，Joel现在运营这fogcreek,stackexchange,trello 封笔多年，博客几乎没有再更新了。 虽然Joel现在已经不怎么谈软件了，不过10年前他对软件开发的那一系列博文引起了无数开发者的共鸣， 其中很多直到今天仍富有借鉴意义。 日常构建/代码评审/缺陷追踪 依然是当下的热门话题；为什么要写需求文档/如何写需求文档 让你重新审视程序员永远不写文档这个问题；大公司是如何制定软件策略的；Joel用他风趣的语言把所有枯燥无味的东西解释的活灵活现。 再往下看你发现对.NET架构的前后不一致评论无疑也体现了Joel对某些他所坚持的观点的妥协。 在后面的一些文章中Joel也会时不时的打脸，原本”神“形象的Joel也慢慢趋于平庸。 毕竟软件工程这样复杂的怪兽是没有所谓的银弹能对付的，不是Joel的一番话就能消除所有复杂性的。 但是那些经典的观念却时不时在心中浮现。 于是，当初翻译这本书的目的也就达到了。 现在我能记起Joel的文章里的那些小故事，甚至拿来说服别人；
不过这本用gitbook构成的电子书绝对就是所有稿件的初稿， 我的打算就是一遍遍重读的时候来一遍遍修正那些翻译。 希望这些文章能引起更多人的共鸣，帮他们找到对付软件怪兽的方法。