程序员修炼之道（第2版）读后感1000字
《程序员修炼之道（第2版）》是一本由Andrew Hunt / David Thomas著作，电子工业出版社出版的平装图书，本书定价：89.00，页数：2020-4-1，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《程序员修炼之道（第2版）》读后感(一)：《程序员修炼之道》：比技术更重要的是养成底层职场思维
01
作为一个工作两年多的程序员，很庆幸遇到这本书。首先，这本书与常规的技术书籍非常不一样，风格有些类似于《代码整洁之道》，但它们的内容却完全不同。
这本书不是一本工具书，不会告诉你某某某语言的某某某特性，你应该怎么用，它更多的是告诉你成为程序员之后，接下来所有的时间，你应该是怎么做。
翻开这本书的目录，你能明显感觉到，跟你看过的其他书籍也不一样，这里面很大的一个不同是，这本书几乎可以看做是以提示作为目录，全文总共有99个提示（不知道为什么不是100个），然后再把它们归类，划分为不同的章节。
在阅读这本书的过程中，我发现其中的很大一部分，我都有过切身的体验，这更激发了我看下去的欲望。
每看完一个提示，总能想到自己实际工作中遇到的问题，并能进一步延伸思考，很大程度上，增加了我对这本书的兴趣。
目前我还没有读完这本书，因为它提出了太多我需要仔细实践的点，所以这本书之后会是我的长期读物。
02
最开始看到这一节《我的源码被狗吃了》的时候，突然想到了我工作一年左右的时候，发生的很多事情，当然，大部分是坏事。
这一段，提出了两个很重要的点：
要知道在一个团队里面，我们和同事共同合作开发项目，信任是影响成果最重要的因素之一。
我曾在去年参与过公司内非常重要的一个项目，因为某位同事的进度问题，最后向CEO demo汇报的时候出现了非常严重的问题。而出现问题的原因就是，团队内的成员，对于某个拥有五年开发经验的新同事的信任。由于过度的信任，导致没有发现问题，最终项目出现大问题，全组的绩效都受到了不同程度的影响。
团队成员之间要有信任，但更应该及时检验，明晰职责，承担责任。
否则一旦出现问题，会给团队造成不好的影响，甚至，造成公司损失。
不要轻易估算承诺，要留给自己足够的思考空间，降低别人对你的预期值。
我就在这点上受过教训。
之前接了一个项目，和领导许诺了一个截止日期，但我高估了自己的完成能力。
他说：“在职场，不要轻易承诺别人，特别是在自己没有120％的把握能够完成的时候。你在别人那里的信用，是你最大的隐形资产，别随意挥霍。”
自此之后，我便懂得了要高度珍惜自己的诚信。
当我接到一项任务时，不再急着向领导承诺，而是留足时间给自己评估完成这项任务所需的时间。
不轻易做出承诺，但只要承诺了，就一定完成。
无论是同事，还是上级，你都需要合理管控他们对你的预期。
俗话说得好：没有期望，就没有失望。
不要夸下海口，让别人对你有高期望，因为你一旦没有达到许下的承诺，对方就会很失望。
经常给对方超乎预期的惊喜，能提高他们对你的信任度，也能增强你在他们心中靠谱的形象。
03
给出选择，而不是找借口。
初入职场的年轻人，总会受学生思维的影响，遇到问题就想找领导，把领导当成了老师。
但领导往往很忙，没那么多时间帮你解决问题。
这个时候，带着问题以及两三个解决方案去找领导，让领导做选择题，而不是问答题。
成熟的职场人，都深谙此道。时间宝贵，请勿浪费。
以上就是我从《程序员修炼之道》中学到的几个比较重要的底层思维。
比起“术”，“道”才是支撑我们长远发展的重中之重。
《程序员修炼之道（第2版）》读后感(二)：《程序员修炼之道：通向务实的最高境界》|开发过程中的避坑指南
《程序员修炼之道：通向务实的最高境界》|编程“江湖”中的武林秘籍
在软件开发的江湖上，新人如过江之鲫，许多人为了能够脱颖而出，往往“兵行险着”，无论在编码技巧上还是在团队中，都标新立异，常有炫技之举，这是好事，值得肯定的，但是有没有如常人的修炼之法呢？有的。如同郭靖一般，踏踏实实，稳扎稳打，最后也能够脱颖而出。
《程序员修炼之道：通向务实的最高境界（第2版）》一书就从务实的角度，用通俗的语言，有趣的示例，将作者多年功力倾注于字里行间，为后来人提供了修炼的法门。
读完此书，我也对自己感觉比较深刻，结合实际开发经历，谈谈自己的想法。
一、邪恶的DRY
DRY（Don't repeat yourself 不要重复你自己）原则与OAOO（once and only once 一次仅且一次）原则实际想表达的意思是一致的，但是也有人不认同这个原则，相关分歧可以自行搜索。
这里的重复不仅说的是代码的简单重复，也说功能或者是说需求实现的重复，举个例子，身份证的正则匹配，会因为角色不一样而有多个后端验证和多个前端验证，当需要身份证验证规则需要变的时候就等改多个地方，不熟悉的人就有可能遗漏，导致不必要的安全风险。
记得原来我们公司为某公司做了个产品，里面有个基类BaseModel，里面包含了工厂编号到生成日期等所有的基础信息，后来发现WorkCalendarModel的实体中，也继承了BaseModel，更奇怪的事情发生了，在BaseModel中已经有一个工厂编号工厂名称了，在子类中重新命名了一个工厂编号和工厂名称，因当时刚接手，看不懂是出于什么目的，只是感觉不对。
对于功能或需求实现重复的地方，便是需求实现变更或是改bug的时候，会需要重复的改，无形中也增加了工作量，最恐怖的重复出现在项目版本控制上，当版本控制失败，那么版本越多，重复的次数就越多，压力就越大。
也许这个时候应该有个基线版本，也或许最好有个主干，代码管理一开始有这样的准备，版本也不至于到无法控制的地步。可以修改之后向其他版本同步；也许是我野心太大了吧，居然想着改所有的版本。切生体会到比简单的代码重复或功能重复更邪恶的就是版本控制失败导致的重复了。
二、“破窗”该如何修理
“破窗效应”虽然是犯罪学的一个理论，描述不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉,所以第一扇破窗往往是罪恶的起点。如何避免破窗的出现，或退而求其次，如何有效的找到破窗并及时修补，便是管理者或是代码开发者应该思考并付诸行动的事情。
在实践中产品按时交付才是滚滚而来的车轮，除了他主动踩刹车，其他的阻力都将被碾压。所以有些破窗是会被容忍的，只要功能堪用，能够及时交付，缺面墙都是可以的。
而且公司为了提高效率，基本上是会按功能模块划分给开发人员负责，老话说“各人自扫门前雪，休管他人瓦上霜”，在自己的一亩三分田里面你是有处置的权力的，但是在其它模块就很难处理了，虚心听的还会改改，有点愣头青的就和你吵起来了，这种事只能找相关负责人协调，当然很多时候都是和稀泥，你要是个强迫症，非被逼疯了不可。
之前就遇到一个事，线上出现bug了，需要排查，后来发现代码中有个关键的参数是写死的，这还不算完，在解析数据接口时，居然还报错，看完代码就哭了，不幸中的万幸是我们的数据推送过去了，返回值什么的就不那么重要了，仅是因为不影响使用。
我们公司的运维遇到个事情，前端有个提示弹窗的请求特别频繁，每秒都有数个请求，多人登录的时候日志更是刷屏了，但是从页面看，这个功能是正常的，而且比原来设计的每分钟访问一次的要求，这个简直是及时推送呀。但是反馈给相关人员，见没影响功能也就没动力去改这个问题了，就如此放任着。
但是我们也应该理解，当一个项目随着代码量的增加，代码质量会随之下降。
开发人员应该都有过那种事急从权的经历，为了短时间内实现某个功能，会使用一些存在风险的方法，先保证功能，相关风险和优化等有时间再调整，其实“有时间再做”基本就是“不做”了。
这时候代码质量会更加急剧地下降。所有的这些破窗都等待着后来人，一群被要求“努力留下一个比你发现时更好的世界”的人，默默忍受着痛苦，这种痛苦只有经历过的人才能体会最深吧。
从公司管理角度来说，问题防范比问题处理更紧要，在修理“破窗”前最好不要再增加“破窗”了，虽然说在需求交付压力面前这种愿景是被碾压的，但是相关的人员培训，编码规范，代码检查机制还是得跟得上管得好，通过问题反馈促进管理水平，或许这比简单的修理更为重要吧。
三、务实的团队
作者David Thomas说：“务实的团队很小，充其量也就10-12人左右吧”。
在很多时候，公司是以小组的形式划分人的，一个小组三四人，其他保障人员如产品、测试、运维、质量管理等都是共享的，或者说与其他小组共享。小组人员是有磨合期的，稳定的团队有助于减少磨合所花的时间。那么一个务实的团队希望达到什么地步呢？
（1）理念一致
开发是实践性很高的工作，是希望将需求条分缕析，弄得明明白白，写好架构设计、写好概要设计、过完相关评审之后，再按部就班的开发，还是缕清主线，骑驴找马，边做边交流，边交流边改进，需求弄清了同时也就基本开发完的方式呢？
如果理念不一致这里面的矛盾就很大了，比如说为项目加个第三方接口调用的提示加日志功能，如果失败弹出提示页面，如果第三方接口的调用失败一时间没法复现（至于是什么原因可以先忽略），这个功能是否需要就成了焦点，一方认为既然没法复现说明这个接口不存在失败的情况，不需要加，即使需要加，我也不知道失败的时候返回的是什么呀，我加了这个功能是不是有用都不知道，那还加什么呢？
所以就把工作丢一边了，计划交付的时间到了，他会和你说，不是我不开发，是没法开发呀，然后把上面的理由复述一遍。
另一方面，安排工作的人觉得，既然已经知道了成功是返回的状态，与此状态不相符合的就是失败了，即使目前没法复现，那么如果不做，当问题真的出现的时候，我们的复现手段和分析日志就没有了，所以不要管目前是否失败，先把功能做出来，为日后做准备。
这时候你会发现，同一件事情，在某些人看来是没法做的，在某些人看来是可以做的，这并不是孰优孰劣的问题，只是思考的方式不一样，或是思考的频道不一致，也就是相关的开发理念不一致导致的。
（2）相互信任，彼此了解
信任是团队长期稳定的基础，相互了解可以可以提高效率。在团队中每个人都有不同的分工，也有不同的水平，也许他们之间互为预备即当对方无法完成任务时可以作为预备人员随时顶上。
因为对组员的了解，你可以把他放到他擅长的地方去，而不是让一个后端去写前端，花了几倍的时间效果还不理想，最主要的还是代码质量会下降，相反的让前端去开发后端也是如此，当然，不乏全栈大牛，但是那毕竟遇到的机会不多。
这时候把对的人放到对的工作中去就显得尤为重要了，不仅提高了开发效率，开发质量也能得到有力的保障。
（3）同进退
务实的团队会同进退，守望相助。团队中，很忌讳的一点是，进退不一，比较常见的现象是，大家都在忙着不可开交，此时却有人偷偷溜了，一两次大家都能理解，次数多了，其他人也就有了想法，凭啥他可以溜了？
如果仅是抱怨和不平，那还算好，最头疼估计是做不到互助了，“他的坑凭什么我来填”成为了直面灵魂的拷问，你会发现，人心散了，队伍不好带了。
（4）学习交流能力好
计算机技术日新月异，不去学习终究被淘汰出局，保持学习的势头，会让大家及时的了解新技术，新工具。相互的交流不仅能相互提高，也会促进相互的了解。
比如我所在的之前的小组，有空的时候会向部门申请预研组的同事给讲讲课，巧的是，没过多久，预研项目被客户看中了，急需转为相关产品，我们小组被选中，负责下一步的开发，因为事前有交流学习，所以项目很快上手，演示产品比预计时间提前了不少完成，也算是一种激励吧。
务实的团队的特点在书中有比较详细的阐述，但是我始终认为，优秀的团队会诞生更多优秀的人才，这或许是“破窗原理”的逆定理吧，谁知道呢？
话说回来，世间哪有那么多的奇才，不过是站在前人的经验之上，学会了务实交流、务实的学习、务实的看待编程过程中的不完美，务实的与身边的同事作为童子军修补着前人的破窗，然后修炼成务实的开发者。
这或许就是职业病吧，程序员已经习惯了各种框架，习惯在大牛们设计的框架中实现着不同的业务逻辑，哪怕框架并不完美，亦如《程序员的修炼之道-通向务实的最高境界》中所提炼修炼过程的务实框架，我们也是可以在里面实现我们职业的进化逻辑，或许你缺少的就是这本秘籍了。
或许听着有些低落了，务实些吧，在程序员修炼的道路上，不仅有骨骼惊奇悟性奇高的天才，但那只是少数，更多的是如郭靖般的“傻人”，不断学习前人的经验，延伸我们的阅历，拓展我们的思维，都是必不可少的。无论选择何种的修炼方式，在成功的山顶，大家所看到的日出都是一样的美。
《程序员修炼之道（第2版）》读后感(三)：《程序员修炼之道》：如何成为一名务实、高效的程序员？
文/Sherlock
程序员是什么？
问了身边同事，不同人不同答案。
一个做运维的小伙子说："程序就是一段上千行的解决问题的代码，有时候为了维护它，痛苦地想打人。编写这段代码的程序员脑袋里装的都是些啥？"
一个发际线已开始后移的做架构设计的同事回答说："程序员就是为了实现文档上指定功能，而搬运代码的高级搬砖工。
整个月不说一句话的做后台算法的同事说："程序员，就是写一堆机器语言，让机器通过认识你的输入完成你想要的输出的高级人机译者。"
我们姑且不论他们的回答是否正确，因为每个人对程序员有着不同的看法与见解。
最近看了《程序员修炼之道：通项务实的最高境界》这本书，书中的许多观点可以为程序员提供更加冷静的视角去重新审视程序员角色，并为程序员的工作提供一些思路与方法。
它告诉我们如何成为务实的程序员，更好地编写软件，探究编程的本质。这本书于2020年再版，与其说是第二版不如说是上一版的进化。书中覆盖了哲学、方法、工具、设计、解耦、并发、重构、需求、团队等内容。无论是初学者还是高级架构师都能从作者思想的洞见中获益。
作者Andrew Hunt，是一位软件开发类作家，同时也是一位冷科幻作家。这本书是他与David Thomas合著的具有开创性的书籍。除此以外，他还著有《程序员修炼之道》、《程序员思维修炼》、获奖作品《高效程序员的45个习惯：敏捷开发修炼之道》等书籍，还发表过许多文章。
Andrew Hunt我从事软件开发工作八年有余，从一开始的"hello World!"入门，到现在的算法设计、架构设计、方案设计，虽没有大牛们服务亿万级用户的经验，但是也编写运行了5年的代码，大大小小的项目也经历过十多个，一路走来小有收获。
直到看了这本书后，才意识到自己很多时候违背了一些原则、犯了完美主义的错误。比如，还没有等到完善功能就重构代码、各个模块耦合度极高，致使出现了牵一发而动全身的情况等等。
一开始很难发现这些错误，直到经历了足够多的项目。这或许就是成长的代价吧。如果能早点遇到这本书，就可以一定程度上避免工作中一些不必要的坑，成为更务实、更高效的程序员。
正如书中所讲："如果遵循我们的方法，你将快速获得经验、提高生产力，并且更好地理解整个开发过程。最终，你会写出更好的软件。"
01.务实的哲学
务实的编程源于务实的思考哲学。
务实的程序员在面临问题时有着怎样的态度、风格及理念呢？从大局着想，越过表面问题，以更宽的视角综合考虑并结合实际，做出明智的妥协和合理的决策。
比如书中提出够好即可的理念，给了我很大的启发，这也是程序员常犯的错误。
为了追求更好，我们损毁了原已够好的。—莎士比亚《李尔王》我几年前参与一个十分重要的十三五升级改造项目，自己承担后台计算部分，与其他同事合作完成一个较为大型的项目，有的同事负责UI，有的同事负责硬件的信号处理，有的同事负责日志处理，有的同事负责数据库部分。
我在项目的开发中，遇到了这本书上讲到的几乎所有的问题。一开始我们总想把软件做的无懈可击，总想以高屋建瓴的姿态去完成该项目，于是在项目过程中一遍又一遍的修改着自己的设计方式。在整个项目开发中，自己查阅了200多篇中外文文献，看到一篇别人做了很好结果的方法总想移植到该项目中。结果导致在项目节点的交付中，虽然完成了所列的功能，但并没有彻底地解决问题，更多的是以一种掩盖问题的方式交付了第一版。
作者指出，“够好即可”这个词并不意味着草率或糟糕的代码。所有系统必须达到基本的性能、隐私和安全标准。你做的东西，从用户需求角度来说是否够好？最好还是留给用户来参与评判。
正如本书所讲的，现实世界不会让我们生产出完美的产品，完全无bug的软件。
整个过程我们缺少让用户（甲方）参与的机会，很多时候细化的需求都是我们小组自己头脑风暴出来的。其实，我们应该倾听用户的需求，因为他们比我们更加理解作为用户的需求是什么。
完成软件项目的过程，更应该像是完成一副绘画作品。从一开始明确整个作品的基调，绘制作品的框架，而不是一开始就去扣作品的细节，比如用什么设计模式，什么算法去实现某些功能。一开始应该明确整个项目的架构，整个项目所用的交互方式，所用数据库等基本问题。
quot;艺术家会告诉你，如果不知道什么时候该停止，那么所有的努力就都白费了。如果你不断地在画布上层层叠加，用细节盖细节，最终的作品就会迷失在各种颜料中。"
02. 务实的运筹
没有作家，故事不会被写出来；没有演员，故事无法获得生命。—Angie-Marie Delsante作者用并发来描述可以并行处理的问题与技术，似乎是讲给小白们听的，老鸟们对并发、并行、多线程、多进程应该再熟悉不过了。对于复杂的程序软件来说，若存在大量可并行的程序模块，起先还是应该采用活动图来确定。一个朋友说，世界上最复杂的软件除了操作系统就是浏览器了，这也就是为什么至今国内还没有一个完全意义上自主的操作系统或浏览器内核。
浏览器说简单点，就是字符串形式的html的格式解析。假如你写出了这样的内核，而且通过你的界面已经渲染出来了。你还会遇到性能问题，为什么别人的浏览器如此流畅，而你的浏览器可能连一个google搜索栏显示都卡得要命。这也就是并发的重要性，它涉及到太多可并发的模块与模块间的纵向与耦合编程。
我正在使用firfox进程的情况图中，倒数第二列为线程数，一共有7个进程，几乎是一个网页一个进程。
这也是我们经常遇见的问题，当你编写一个软件后，你以为似乎完成了所有的功能。可是系统一旦有异常值或边界值的输入，你的软件就crash了。接着你查资料，换了一种方法解决了这个问题。然而在进行其他测试时，程序又crash了，你就会在不断的crash之中崩溃掉。
此时，我们应该停下来想一想，这种打补丁的方式是否存在问题，可否跳出来，用图的方式让我们更加明晰问题的关键节点所在，或者是否可以通过优化程序处理的线程方式与并发来提高工作效率……
Bjarne Stroustrup C++之父我在开发过程中也遇到了作者所讲的问题，比如共享数据队列怎么处理、共享资源怎么做、信号量、资源锁、原子性等问题。这些问题都是实实在在的。
我的想法是，遇到类似问题的开发人员，可以自己编写出适合于自己的通用模块。能自己封装出适合自己的信号量、共享队列、资源锁，那就再好不过了。
因为几乎所有并发资源共享问题，都可以使用自己编写的模块来解决。为什么使用自己编写的模块，而不是使用现有的模块呢？一是你可以提升自己对于底层实现的理解；二是一旦对共享资源队列有什么特别的需求，你就可以修改，甚至可以提升效能。一开始可能比较痛苦，但是你会发现你付出的努力是值得的。
03.务实的依靠
在L组里，斯托弗管理着六个一流的程序员，这在管理上的挑战与养猫差不多。——《华盛顿邮报》杂志1985年6月9日刊在软件开发团队中，合作精神的重要性不言而喻，团队可以只有几个人，也可以有成千上万人，持续时间也可以是一年或者几十年不等，比如Linux内核团队。在大多数开发任务中，根据不同的功能点，把团队划分为若干个小的团队，人员也比较稳定，充其量也就是10-12人左右。团队之间相互信任，相互依赖。
团队交流协作团队是一个整体，团队成员之间的磨合极为重要。能保持合作的默契和沟通的顺畅再好不过了，实在不行还可以通过条约来约束。
团队是一个整体，遇到小问题要积极地修补处理。团队必须对产品的质量负责，质量的保障有赖于团队每个成员的自发的贡献而不是来源于质量管理人员的监督。
团队的交流，包括对内交流与对外交流。大多时候程序员，喜欢埋头根据需求文档在自嗨的高潮中写代码，就像自我陶醉于一个人的摇滚。
然而交流是整个开发中的重中之重，自我陶醉于技术，容易忽略客户的需求，忘记了客户至上的理念。软件开发并不是炫技。客户的需求才应该是我们所追求的，不要认为客户什么都不懂，而是要耐心的听他们讲完，与他们多多沟通，与客户协调。因为只有沟通协调才能让我们技术得以落地。
团队内部的交流与沟通，是落实需求的重要手段。我们不能认为小白就比老鸟菜差，软件开发涉及方方面面，我们也不可能对所有领域都了如指掌。应该养成不断学习的习惯，秉持谦虚谨慎的态度。
团队本就应该是一个整体，若有什么想法，要及时沟通协调。劲往一处使，早日做出满意的产品。把问题留在团队内部消化解决，以最好的状态去完成软件开发，鼓励每个成员积极监控环境变化。保持清醒，对任何有风险的东西，都要留心。积极度量新需求，不要抗拒变化。
结语
读了这本书，我感到它将会给我的职业生涯以有力的指导。
它不仅仅提示了软件开发中需注意的地方和要规避的风险点。其务实的思维方式有着更广阔的适用边界，其他职业的人也可以迁移借鉴。
尽管我已经经历过若干项目，但依然认为这本书上罗列的99个提示，需要多加注意。我期望通过对这本书的研读，好好地总结自己这些年的得失，更好地面向未来，以更加积极的心态与状态去工作。
-end-
《程序员修炼之道（第2版）》读后感(四)：《程序员修炼之道（第2版）》：哲学、工程、技术完美结合的“信仰之书”
“人生是你的。”这唤起了我们自己的力量，它就蕴含在我们的代码库、工作和职业生涯。 ——《程序员修炼之道》序
著名武侠小说家金庸先生在他的武学江湖中，曾写过至高无上的武学宝典《九阴真经》，还有一本与其不相上下的《九阳真经》，两部经法，一个重以柔克刚，以阴盛阳；一个重阴阳调和、刚柔互济。《九阴》和《九阳》都达到了中原武学的高峰，但只有二者相结合的“阴阳共济”才是武学最高境界。
借武学境界推而广之，各行业皆有自己的江湖“绝学”，有的重基础，有的重修养，不一而足，但归根结底，不外乎两个方向：向内修或向外修。
向外修，是修本身，你的技术，你在本职上拥有的能力和级别；向内修，是修心，是为你的外修提供源源不断的动力和供给的源泉，让你的内力自生不息，源源不竭。
在我看来，《程序员修炼之道》就是程序员的《九阳真经》，它理应成为程序员放置手边时时翻阅、研读、参照的枕边书，字典书、信仰之书。
《程序员修炼之道》副标题“通向务实的最高境界”，它不仅从哲学的高度解决了程序的设计思想，程序员的创作思维能力，还务实地告诉你如何更好地写代码，并对围绕代码可能产生的麻烦——设计、编码、启动、团队、版本控制、测试、自动化等等一系列实际问题，给出了解决原则和方案，最终达到取悦用户成就自身的更高一级梦想。
问世二十年来，《程序员修炼之道》一直雄踞程序员图书榜前列，作为一本行业专著，它并没有技术书籍那样深奥的词汇，晦涩的术语和令人难以理解的句子，当你进入编程之门，对编程世界充满着好奇与兴奋，《程序员修炼之道》就是你的《九阳真经》，它一步步把你打造成更好的更务实的程序员，直至你习成巅峰的武功绝学。
01. 程序员修炼的哲学境界——务实
程序员的进阶修炼，与其他职业的进阶之路相比，更强调思考。
弗雷德里克·布鲁克斯说：程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。他们运用自己的想象，来建造自己的城堡。
一切思考，都应该脚踏实地，只有建立在务实基础上的思考，才是有水之源，有本之木。
务实的程序员有什么特质？
他们总是越过问题的表面，试着从大局着想。他们总是为自己所做的一切负责。那么，务实的哲学有哪些？一个是选择的哲学，通过一些跨学科的哲学共识，譬如：石头汤、水煮青蛙、破窗效应等来做出选择，适时改变，积极主动地掌控机遇；
一个是工作中经常性的应用，譬如：够好即可、知识组合、批判性思维、保持交流等来发现问题，找到解决问题之道。
很多时候的很多错误，我们经常遇到，但依旧会犯错。只有内化这些思维成为编程时的本能，才能避免重复错误。
学习新的知识，建构新的知识组合和体系，可以有效避免错误发生的几率。保持批判性思维，是拥有精准知识的能力。
务实的其中一个原则——DRY(不要重复你自己)。
现实生活中，这个很难做到，我们很多时候都在重复自己，不过重复的角度和层次不同而已。有时候，你可能不会简单重复你写的代码，但你无法保证不重复你的设计原则，也许你更习惯重复你的编码习惯。我们能做的，就是努力去减少无意义的重复。
所以，作者不无深意地提醒我们DRY原则：在一个系统中，每一处知识都必须单一、明确、权威地表达。
“千里始足下，深谷起微尘，吾道亦如斯，行之贵日新。”这是一本思考之书，人为了思考才被创造出来，除了思考，还要多实践。
02. 程序员修炼的工具——代码
《程序员的修炼之道》毕竟是一本面对程序员的提升之书，它通过代码和编程来进行实践。而本书的编排是由务实哲学境界的讨论，提升思维能力后，再来讨论“术”的东西。在“术”的方面，对基础工具的运用，掌握正确的方法也不可或缺。
这些方法，原则，或者我们可以称作“元(meta)”方法，融汇作者多年实践和工作中遇到的具体问题，很生动、具体，以至于只有经过反复思考、实践，再思考之后方才能有所感悟。
一切工作，皆可利用工具。程序员或者开发者为了工作顺利进行，也同时开发了很多工具。就像作者说“使用一些工具，使效率比其他人更高。”我们并不缺乏工具，问题往往是，我们不知道该使用哪些工具，在什么情况下使用工具。
就像木工都需要一个工作台一样，Shell指令就是程序员的工作台。在Shell中，你可以调动所有能用的工具，或通过管道用各种方式把工具组合起来，可以启动应用程序、调试器、浏览器、编辑器和工具，可以搜索文件、查询系统状态，并将结果过滤输出，还可以通过Shell编程构建复杂的宏指令处理经常要做的事。
现在图形化编程很风靡，很多程序员也习惯了在IDE中成长，但如果用IDE中的图形界面去完成所有工作，就会错失环境的全部能力，你将无法把常见的任务自动化，或者无法充分利用工具所能提供的强大功能。
图形工具的好处——所见即所得，弱势也显而易见——所见即全部。
所以，就像木工定制他们自己的工作空间一样，开发人员应该定制自己的Shell。
实践出真知。只有实践，是检验真理的唯一标准。作者也利用近一半篇幅，阐述程序员在日程工作中经常会遇到的具体问题，并提供了相应的指导、建议和解决方案。完整地覆盖了程序设计理念、代码实现和项目管理等相关实践的重要事项。
03．编程只是程序员世界的一部分，而这本书探索了整个世界
据说网易、趋势等公司，给新入职程序员的员工手册，就是一本《程序员修炼之道》，希望这些新人，能够对编程这个职业有自己的认知，形成一个优秀程序员的习惯和思维能力 。
大部分新人程序员，都经历过一种盲目开发的阶段：拿到需求文档，原封不动的照着文档去写代码，根本不会去认真思考背后用户的使用逻辑，所以需求文档有一点业务逻辑偏差时，作为程序员竟然毫不知情，导致后面不得不费力返工，需整个团队花费更多的时间和精力重新修改代码。
而事实上，也有相当一部分人，在提出需求时，对自己的需求并不十分明确，他们无法确切地表达自己真正需要的是什么。
因此，程序员和需求文档之间，隔着巨大的鸿沟。
除非，在写需求文档最开始的时候，运用专业知识，多想一步，再多挖掘一步，就有可能会避免。在需求分析时，经验欠缺的开发人员和经验丰富的程序员，对于业务的理解和深入程度，是衡量开发水平的重要因素。
比如客户有一个简单的需求：比如一家以纸质书和电子书为主要业务的公司，提出一个需求“所有49元以上的订单都免运费”。
作为一个程序员，从这个简单的需求中发现了什么问题？
49元含运费吗？49元必须是都购买纸质书吗？还是允许纸质书和电子书统一结算？包邮有地区限制吗？包含境外吗？对快递公司有指定吗？可见，对需求的认知，客户和程序员是有差距的。小到对于工具的使用，大到对于整个项目的理解。需求开始前，需求拆解阶段，不要去搜集需求，而是要挖掘需求。理解需求背后的业务逻辑，不能陷入为了开发而开发的状态。
每个开发人员都是独一无二的，拥有自己的优势和劣势，喜好和厌恶的东西，而通过学习和修炼，提升能力，获得经验，提高生产力，写出更好的软件，却是每个程序员共同的追求。
《程序员修炼之道》，强调的是修炼，这是一个全面的过程，从认知到技能，从具体做法到思维能力，可能不是那么一个愉快的过程，在不断的犯错、总结、改进、提升中，循环往复，只有经历一个个这样的过程，才能够逐渐成长。
著名心理学家艾利克森认为：对于在任何行业或领域中希望提升自己的每个人，刻意练习是黄金标准，是迄今为止发现的最强大的学习方法。
程序员的修炼，同样可以通过刻意练习的方式，有针对性地进行提高：
①以《程序员修炼之道》为标杆，按照书中的做法、习惯、建议去修正自己的行为。
在软件开发这一领域中，书中所说的思维方法、工具用法、设计理念，基本是达到一定杰出水平的表现，可把他们作为最优秀的那批人，进行临摹。
②书中提出一些挑战和练习，并且给出了参考答案，这相当于一位能够布置练习作业的导师。
根据“导师”的要求，在练习的过程中提供反馈，及时找到存在的问题。然后，学会自己检测自己、自己发现错误，并且进行相应的调整。
《程序员修炼之道》中，我最喜欢的两句话：关注你的技艺；思考你的工作。这句话，是适用于任何领域的修炼。
现代管理学之父彼得·德鲁克说过：“星期一的时候，我不希望你们说这个周末过的有多愉快，我希望你们跟我讲，你们做了些什么改变。”
修炼提升，可从今日始。
图片来自网络，侵删。
《程序员修炼之道（第2版）》读后感(五)：《程序员修炼之道》：引领开发者走上务实开发之路的鼎力巨作
《Rails之道》作者Obie Fernandez曾这样评价：“可以说，《程序员修炼之道》完全改变了我的职业轨迹，为我指明了软件领域的成功方向。正是这本书，开阔了我的视野，让我意识到自己不仅仅是庞大机器上的一枚齿轮，有朝一日也能籍由修炼成为匠师。它是我生命中最重要的一本书。”
Obie Fernandez如此高度赞誉《程序员修炼之道：通向务实的最高境界》（第2版）（以下简称《程序员修炼之道》）这本书，可以看出这本书对于IT研发和技术人员来说是多么难能可贵，它是一盏程序员之路的指明灯，将带领我们更深入研究程序设计和方法。无论是新手，还是经验丰富的实践者，都能从每次阅读中发现新的见解。因此，本书值得经年累月多次揣摩阅读，它对我们都是非常值得信赖的工具书。
《程序员修炼之道》这本书作者为美国人David Thomas和Andrew Hunt，他们两人从1999年开始，以此影响巨大的作品，帮助诸多客户创作出更好的软件作品，并且重新挖掘出编码的乐趣。
本书中的这些课程内容，均凌驾于任何特定的语言和框架，或者方法之上，启发了一代代程序员，探索软件开发的本质。二十一年后的现在，第2版本精品力作再次引发IT业狂潮，我们从书中可以审视到，作为一个21世纪的现代程序员，究竟意味着什么？更可以从书中体会到不一样的编程世界。
《程序员修炼之道》这本书每个章节都分别由一组独立的话题构成，每章节的开篇几乎都以一篇哲理故事或名人名言开头，再引申到具体的编程案例，告诫程序员在软件开发中多个方面的技巧方法和需要避免的陷阱。
可以说，《程序员修炼之道》这本书与以往技术工具类书籍不同，它充满了可读性和趣味性，使读者能抓紧书中的内容，跟随作者的脚步去探索有趣又有价值增量的技术。
学会务实思考的哲学，可以让开发员的工作事半功倍
就如我们尽量充实自己的人生，因为人生是我们自己的；同样的，尽力做好自己的事业，因为事业是通向未来人生的轨道。想要成为一个优秀的开发员，首先需要做一个具备务实思考的程序员。
实际工作中，许多开发员喜欢稳定和一成不变的工作，他们很少受对外界事物的影响，他们大脑中思考的对象都辖制在长方形的显示器内。长此以往他们忘记了怎么去改变，忽略了选择的权利，甚至为了坚守自己的代码不被动摇，找借口逃脱承担责任和团队信任。因此，严格审视自己的工作和代码，发现问题及时处理，能积极参与集体协作，互相信任，都是务实的态度啊。
本书中讲到许多务实的好方法，对开发员来说具有提示和警醒作用，比如在开发一款软件项目中，做到够好即可的软件，并让用户参与权衡，在开发过程中将软件质量要求视为需求问题，可以避免底层架构的缺陷产生。
程序员在编写代码之前需要对项目结构进行设计，实践表明，优秀的设计比糟糕的设计更容易变更。学会良好的设计习惯，可以使程序员在编码过程中体会到更多的便利之处。
比如避免过多的代码重复，创建一个支持复用的开发环境，利用正交性设计组件，通过制作原型来积攒经验，在开发前做估算提前发现程序的潜在问题等，这些都是程序员在开发任务中非常实用的务实方法。
作为一个标准的程序员，不断学习新知识和技术是一项不可或缺的重要工作。
知识的力量是无穷的，更是未来人生的加油站。程序员通过学习避免停留在原地，学习可以在工作领域方面有收获和创新突破。比如学习一门新语言、每月读一本技术书籍、上技术领域的网课、尝试不同的开发环境等。
学会务实思考，完善开发流程，对程序员来说做到这些，既可以提升你的工作效率，又可以让项目进展顺利，这样事半功倍的方法何乐而不为？
不存在有完美的软件，但学会务实的偏执，可以把遗憾变为优势
这个世界上没有任何事情可以达到十全十美，同样，也不可能有完美无缺的软件项目。虽然这是一个比较令人遗憾的现实，但作为一个务实的程序员可以利用某些偏执的方法，把这种遗憾变成另一种优势。
正如世界上没有完美的人，软件也不可能是完美的，对于在所难免的软件缺陷，最主要的是保护代码和用户对象避免受缺陷的影响。因此，为自己代码中可能产生的缺陷建立一个防御机制，是务实的程序员必有的保证措施。
这种务实的预防措施可以让你的代码质量更高效，很大程度上保证了代码的安全性和可靠性，让你在编写代码过程中条理清晰，软件质量和工作效率事半功倍。
1. 契约式设计：这里包含了第一个防御措施。契约是对双方共同的权利和责任的规定，在软件模块中，对于代码是否能正好完成它宣称要做的事情，就可以使用契约进行检验和文档化，这也是契约式设计的核心内容。
2. 死掉的程序不会说谎：程序员在编写代码时，会意识到某些程序出现问题，有可能是不小心给库传了一个空值或空表；可能是哈希表中缺少一个键值；也可能有一个系统文件没被捕获，得到一个空数据等。诸如此类情况，都是一些微小的细节问题，许多程序员都曾经忽略它们。而一个务实的程序员一定不会错过这些问题细节，即使有错误漏出，他们也会查看详细的错误信息，因为死掉的程序要比有缺陷的程序造成的损害小很多。
3. 断言式编程：务实的程序员应该会使用断言来预防假设的事情，断言能够校验你为避免错误而写下的假设，因此断言实际上是为了保护你的代码而来。在许多编程语言中都有一些检查布尔条件的断言语句，这大大方便了程序员对自己代码的正确判断。比如，一个参数或返回结果永远不该为null，则用以下显式的检查：
assert（result ！=null）；同样地，断言也能用于检查算法的操作，例如你写了一个排序算法，名称为my_sort，检查一下它工作是否正常：
books=my_sort（find（“scifi”）） assert（is_sorted？（books））4. 如何保持资源的平衡：正如厄休拉·勒古恩在《地海巫师》所说过的经典语句：“点亮一盏烛火，便投出一道阴影”。对于软件中的资源，一直使用遵循可预测的模式，那就是先分配资源，再使用资源，最后释放资源。因此，分配资源的函数或对象，也有责任去释放资源，我们通过本书第119页一段Ruby程序例子可以搞懂它的具体方法。这也说明如果将灵活多变的变量维持在一个范围内，那么打开资源的过程会短暂并且明显可见。
5. 不要冲出前灯范围：一个长期保持务实编码习惯的程序员来说，永远小步前进，在前进中不断的自我检查和及时反馈，并能做到在推进之前先做好调整是一个良好的偏执行为。在对软件做维护设计时，一定要保持在你能预测到的范围内进行设计，对于未来不可预测的设计，一定要在可控范围内适时更替，如此才能避免犯更大的错误。
只有做到把版本控制、测试和自动化完美组合的“魔法三连”，才能做出真正务实的项目
软件项目的开展少不了团队成员的互相协作，而一个务实的团队需要建立一些务实的基本规则，依靠规则将项目的各个部分分配给对应适合的成员，才能保证最终软件项目持续可靠的交付。
这其中最为关键的一个环节就涉及到版本控制、测试、自动化的“魔法三连”，这也是务实的入门套件。
正如阿尔弗雷德·诺思·怀特海所说，
“文明的进步是以增加那些不需要思考就能完成的重要操作来实现的”。在软件项目开发中，无论是项目构建、发布、测试还是项目中可以重复工作的任务都应该是自动的，这使项目能够确保一致性与可重复性，这也是自动化存在的重要意义。
《程序员修炼之道》一书的作者认为，每个团队需要的最基本、最重要的元素是什么？而不去考虑方法、语言或技术栈。明显可以看出，务实入门的“魔法三连”具有非常重要的地位和价值。
1. 版本控制：版本控制可以将构建项目所需要的一切都囊括其中，它重点用于项目级别驱动构建和发布流程。一般来说，通过提交或推送到版本控制触发构建、测试和部署，完成最初的创建过程，一直到生产和交付阶段，都可以在版本控制系统中务实完成。这样项目发布流程变得自动而条理分明，构成了项目持续交付必备阶段。
2. 测试：测试是程序开发中不可或缺的重要组成部分，它关乎软件项目的质量保证，在软件生命周期中起到举足轻重的作用。有些开发员为了一鼓作气尽快写完代码，并不在意代码中出现的小问题，然而一旦完成项目模块的代码后，再去测试修改bug，则要浪费许多时间，延误项目进展。
因此，本书中提示只要开发人员写出代码，就应该尽早开始测试，要知道过多的bug也会聚沙成塔，要等到完成模块代码再开始测试，小问题也会变成棘手的大问题。因此尽早测试、经常测试和自动测试，不仅会能及早检测问题修复bug，也能提高开发人员的工作效率，从长远来看还能降低项目成本，提高项目质量。
在测试中有一种破坏测试，能更有效的测试应用程序的韧性。比如可以从源代码中剖离出单独的分支，有针对和目的性引入bug，来验证测试能否正确捕获到。还可以使用如Netflix的Chaos Monkey破坏服务，以便更确切地侦测到问题所在。
3. 自动化：一般说来手动测试比较随机，覆盖率虽广但也难免有漏网之鱼，况且在网络流量日益倍增的现在，对程序的性能和压力也有更多的需求，在此前提下，自动化测试就不可避免的出现。自动化测试需要编写一些脚本语言来完成测试任务，它可以反复定时定量来运行测试代码，在高强度循环重复执行代码中，能够找出手动测试无法完成的工作任务。自动化还可以在云服务器上自动构建项目、部署任务，因此在版本控制之下，开发人员可以根据时间线检查构建或发布过程的修改。自动化测试为务实的项目增添了便捷服务和高效的工作，节省时间提高效率，让开发人员省心省力又省时。
在《程序员修炼之道》这本书中，我们可以深切体会到，作为一个务实的程序员拥有良好的编码习惯和高效便捷的工作流程，他们富有责任心，与团队协同合作，乐于挑战任何工作上的困难，积极探讨更好的敏捷开发方法，并在开发中加以实践，积攒更多更好的工作经验。
如果有一天，你看着自己务实设计的软件，从心底认同它是可靠的、编码优秀的、性能卓越的、充满期许的，那么你将会发现这是一份多么专业多么值得自豪而骄傲的工作。