好书推荐，《程序员修炼之道》
这本书里包含了很多的看似粗浅朴素的道理，实则是若干经验的心血总结。
比如谁都知道不要对自己家的破窗户置之不理，可实际中听到太多的妥协：这个代码已经这样了，只能继续在上面贴上丑陋的workaround，这其实是一种对责任的推卸和对未来的不负责，当然现实不是完美的，有时救火队员也不得不放下破窗户而迁就其他，但最为一个pragmatic程序员，保持追求完美的心态还是很有必要的，正因为这个心态，我们才会去追求代码的优美、设计/实现的正交、DRY(Dont' Repeat Yourself)原则...
我们看到太多重复造*的故事。
正如书中提到“鞋匠的孩子没鞋穿”，作为一个pragmatic程序员，合理地使用工具/库/以及自己积累的开发的*，会让自己的productivity不断提升。这让我想起公司里一个让人崇拜的“牛”，产品一直想把进程内cache做成多进程共享，正在大家还在讨论该怎么做的时候，“牛”已经用短短几天时间完成了，众人再次崇拜一把，原来“牛”是备有很多现成代码的，完成这个功能只是把之前积累的封装良好的模块重用就可以了。
记得四年前刚开始工作时从公司拿到的第一本书，就是这本《程序员修炼之道》(英文版)，作为新入职员工study group的学习材料，当时在senior engineer带领下和其他同事一起学习了这本书。虽然之前就听说这是一本好书，但当时看的时候只是觉得，讲的都有道理，但这些是很自然的阿，干吗花这么大的篇幅说来说去？所以只是囫囵吞枣地翻过也就扔在一边了。
之后也看过很多类似的书籍，《修炼之道》也一直是公司新人的必备学习材料，而我却一直再没重拾这本书仔细通读一遍，直到最近周筠老师发给我中文电子版，我才又从书架上翻出当年的英文版，对照着中文电子版仔细通读了一遍。
此次重读，感受颇多，也颇能理解为何公司一直选用此书作为新人教材。
这本书里包含了很多的看似粗浅朴素的道理，实则是若干经验的心血总结。比如谁都知道不要对自己家的破窗户置之不理，可实际中听到太多的妥协：这个代码已经这样了，只能继续在上面贴上丑陋的workaround，这其实是一种对责任的推卸和对未来的不负责，当然现实不是完美的，有时救火队员也不得不放下破窗户而迁就其他，但最为一个pragmatic程序员，保持追求完美的心态还是很有必要的，正因为这个心态，我们才会去追求代码的优美、设计/实现的正交、DRY(Dont' Repeat Yourself)原则...
关于DRY，我想说，不但don't repeat yourself，也don't report others，我们看到太多重复造*的故事，正如书中提到“鞋匠的孩子没鞋穿”，作为一个pragmatic程序员，合理地使用工具/库/以及自己积累的开发的*，会让自己的productivity不断提升。这让我想起公司里一个让人崇拜的“牛”，产品一直想把进程内cache做成多进程共享，正在大家还在讨论该怎么做的时候，“牛”已经用短短几天时间完成了，众人再次崇拜一把，原来“牛”是备有很多现成代码的，完成这个功能只是把之前积累的封装良好的模块重用就可以了。
另外一个书中推崇的方法：曳光弹，自己之前用prototype，但一直犹豫于代码是否需要重用，原则上prototype的代码是应该抛弃型的，但在有时候前期做的一些工作其实是为了确定方案、构建框架，而这些其实是会作为后起工作的基础的。事实上在项目先期是值得仔细考虑究竟该采用prototype还是曳光弹，它们的适用场景会有所不同（对于产品开发，曳光弹的应用场景可能相对会更多一些）
当然，至于书中提到的对知识资产的管理（知识投资）、沟通和交流的重要性等等，我想这就不单单对于程序员适用了，任何一个人要想有所作为的，这些方面的重要性都毋庸多说了。而对于自动化和文本处理等方面的经验，也是在很多书中都提到的经验之谈（Unix编程艺术、卓有成效的程序员...）
最后，说一下这本书的翻译，译者马维达，最早是在学校时读过他翻译的ACE文档及相关资料，收益颇多，ACE可谓网络编程技术的集大成者，而这本《修炼之道》则可谓编程的集大成者，从项目管理、软件架构和设计、代码编写和测试，各方面在此书中都有精到的阐述。此书的翻译质量应该说很是准确，基本很实在真实地表达了原书的意思，但正因直译，可能有些语句理解上会有一点难度（比如P146, "只要对于那些被耦合在一起的模块而言，这是众所周知的和可以接受的，你的设计就没有问题。"），但细读这本书，这些有所晦涩的内容还是能理解的，当然一点建议是作者可以适当加些“译注”，这样会让理解更容易和顺畅（比如书中直接用古鲁来翻译Guru，如果能加些解释可能会更好，又比如Law of Demeter，原书没有解释得太清楚，如果能多加些解释可能会更便于理解）
感谢周筠老师让我有机会重温这本优秀的书籍，为了完成作业，也为了让自己认识提升。