《程序员修炼之道（第2版）》是一本由Andrew Hunt / David Thomas著作，电子工业出版社出版的平装图书，本书定价：89.00，页数：2020-4-1，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《程序员修炼之道（第2版）》读后感(一)：写得好，翻译得好
这本书写得好，翻译得也好，不过不太适合经验太少的技术人员看，因为大概率没有共鸣。我十几年来几乎每天都看英文资料，但看这本书的英文版时，还是感觉比较拗口，云风翻译后，读起来顺畅很多了。感谢云风大神的付出，我连续看了几天，估计有4、5遍吧，之后我会在同名微信视频号(技术人成长)中对书里面的一些章节谈谈自己的看法。
《程序员修炼之道（第2版）》读后感(二)：《程序员修炼之道》：比技术更重要的是养成底层职场思维
01
作为一个工作两年多的程序员，很庆幸遇到这本书。首先，这本书与常规的技术书籍非常不一样，风格有些类似于《代码整洁之道》，但它们的内容却完全不同。
这本书不是一本工具书，不会告诉你某某某语言的某某某特性，你应该怎么用，它更多的是告诉你成为程序员之后，接下来所有的时间，你应该是怎么做。
翻开这本书的目录，你能明显感觉到，跟你看过的其他书籍也不一样，这里面很大的一个不同是，这本书几乎可以看做是以提示作为目录，全文总共有99个提示（不知道为什么不是100个），然后再把它们归类，划分为不同的章节。
在阅读这本书的过程中，我发现其中的很大一部分，我都有过切身的体验，这更激发了我看下去的欲望。
每看完一个提示，总能想到自己实际工作中遇到的问题，并能进一步延伸思考，很大程度上，增加了我对这本书的兴趣。
目前我还没有读完这本书，因为它提出了太多我需要仔细实践的点，所以这本书之后会是我的长期读物。
02
最开始看到这一节《我的源码被狗吃了》的时候，突然想到了我工作一年左右的时候，发生的很多事情，当然，大部分是坏事。
这一段，提出了两个很重要的点：
第一点：团队信任
要知道在一个团队里面，我们和同事共同合作开发项目，信任是影响成果最重要的因素之一。
我曾在去年参与过公司内非常重要的一个项目，因为某位同事的进度问题，最后向CEO demo汇报的时候出现了非常严重的问题。而出现问题的原因就是，团队内的成员，对于某个拥有五年开发经验的新同事的信任。由于过度的信任，导致没有发现问题，最终项目出现大问题，全组的绩效都受到了不同程度的影响。
团队成员之间要有信任，但更应该及时检验，明晰职责，承担责任。
否则一旦出现问题，会给团队造成不好的影响，甚至，造成公司损失。
第二点：被要求估算时回复：我等下回复你。
不要轻易估算承诺，要留给自己足够的思考空间，降低别人对你的预期值。
我就在这点上受过教训。
之前接了一个项目，和领导许诺了一个截止日期，但我高估了自己的完成能力。
到最后，实在是完不成了，只好和领导老实交代。
领导没有责备我，但和我说了一段话，我至今记忆犹新。
他说：“在职场，不要轻易承诺别人，特别是在自己没有120％的把握能够完成的时候。你在别人那里的信用，是你最大的隐形资产，别随意挥霍。”
自此之后，我便懂得了要高度珍惜自己的诚信。
当我接到一项任务时，不再急着向领导承诺，而是留足时间给自己评估完成这项任务所需的时间。
不轻易做出承诺，但只要承诺了，就一定完成。
无论是同事，还是上级，你都需要合理管控他们对你的预期。
俗话说得好：没有期望，就没有失望。
不要夸下海口，让别人对你有高期望，因为你一旦没有达到许下的承诺，对方就会很失望。
经常给对方超乎预期的惊喜，能提高他们对你的信任度，也能增强你在他们心中靠谱的形象。
03
给出选择，而不是找借口。
初入职场的年轻人，总会受学生思维的影响，遇到问题就想找领导，把领导当成了老师。
但领导往往很忙，没那么多时间帮你解决问题。
这个时候，带着问题以及两三个解决方案去找领导，让领导做选择题，而不是问答题。
成熟的职场人，都深谙此道。时间宝贵，请勿浪费。
以上就是我从《程序员修炼之道》中学到的几个比较重要的底层思维。
比起“术”，“道”才是支撑我们长远发展的重中之重。
《程序员修炼之道（第2版）》读后感(三)：传世经典
如果在网上征集软件开发经典书单，《程序员修炼之道》应该会是出现频率最高的书目之一。因为它不局限于特定语言、框架、技术，而是凭借更深层、普遍的思想和理念，持续地给不同领域的软件开发者提供启发。唯一的缺憾是，这本书出版的年份太早了（中文版2004年，影印版2003年，原版1999年）。
得知该书的第二版（20周年版）面世，简直是一件值得喜大普奔的好消息。立刻下单，第一时间通读，读完之后，我忍不住借用 Top Gear 评价 Ford Fiesta ST 的词来形容这本书：All Time Classic，传世经典。
与第一版相比，第二版中与时俱进地更新了许多——
比如第一版中遍布各处的 DRY 原则和正交性，在新版中由更深层的理念统合在了一起，那就是 ETC 原则（Easier To Change，更容易变更）。由此引出“提示14：优秀的设计比糟糕的设计更容易变更”。也许对于编程初学者来说，这一条原则似乎没有给出太多有用的指导。但是，如果带着这个原则去学习软件设计方法，或者结合已有的项目经验来回顾，会有醍醐灌顶之感：为什么要 DRY 或 KISS，为什么要正交或者解耦，为什么要遵循 SOLID，为什么要提出分层架构或 DDD，为什么命名很重要——所有这些设计原则，无非都是为了使软件更容易变更。
比如新版中的继承税一节，反思了面向对象设计中被广泛使用的继承，如果被不合理地滥用，会带来什么不良后果，并给出了更推荐的方案。
比如关于测试，作者指出了测试的好处不止在于运行测试，更在于对测试的思考会带来更好的设计。同时作者也指出了 TDD 的缺点。经过这样的对比反思，会对测试的理解更加深入。
比如在务实的入门套件一节，作者总结出了支撑项目的三剑客：版本控制、回归测试、完全自动化。在 Git、自动化测试、CI 已被广泛认知的今天，初看作者似乎被没有给出新的信息，然而当这三个要素被总结为入门套件，仔细一想，会发现项目交付的痛苦程度，基本上正是与这三要素的实现程度成反比。
除此之外，作者还谈及了需求之坑、敏捷的本质、项目与团队的管理、如何让用户满意、软件开发者的伦理等问题，以及对于程序员来说最重要的几样东西：态度、学习、交流。
richyzhang 的短评说“这属于程序员职业技能关注点的比较轻松的一种读物。好处是各方面都点到了，而且确实基本上是过去20年最被主流接受的做法；坏处是都是点到即止，已经明白的人看了没什么用处，初次接触的人可能还要去补充看其他很多东西。”私以为中肯。本书的优点在于面面俱到，并且轻松易读。但这本书当然不可替代各方面的深度书籍，比如设计模式、DDD、敏捷软件开发或者并发模型相关的专著。如果以武侠作比喻，这本书好比心法，带着书中给予的思想和眼光去学习各门各派的方法理念，更容易领会各家的精妙和不足。
相关资料：
官网：https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition
译者云风的博客——易于修改原则：https://blog.codingnow.com/2019/11/etc.html
一段关于团队正交性的废稿（很可惜删掉了）：https://book.douban.com/annotation/95080672/
《程序员修炼之道（第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. 自动化：一般说来手动测试比较随机，覆盖率虽广但也难免有漏网之鱼，况且在网络流量日益倍增的现在，对程序的性能和压力也有更多的需求，在此前提下，自动化测试就不可避免的出现。自动化测试需要编写一些脚本语言来完成测试任务，它可以反复定时定量来运行测试代码，在高强度循环重复执行代码中，能够找出手动测试无法完成的工作任务。自动化还可以在云服务器上自动构建项目、部署任务，因此在版本控制之下，开发人员可以根据时间线检查构建或发布过程的修改。自动化测试为务实的项目增添了便捷服务和高效的工作，节省时间提高效率，让开发人员省心省力又省时。
在《程序员修炼之道》这本书中，我们可以深切体会到，作为一个务实的程序员拥有良好的编码习惯和高效便捷的工作流程，他们富有责任心，与团队协同合作，乐于挑战任何工作上的困难，积极探讨更好的敏捷开发方法，并在开发中加以实践，积攒更多更好的工作经验。
如果有一天，你看着自己务实设计的软件，从心底认同它是可靠的、编码优秀的、性能卓越的、充满期许的，那么你将会发现这是一份多么专业多么值得自豪而骄傲的工作。
《程序员修炼之道（第2版）》读后感(八)：程序员的修炼之道
关于作者 这本书的两位作者分别是大卫·托马斯和安德鲁·亨特，他们不只是非常资深的程序员，还是《敏捷软件开发宣言》17位创始人中的2位。他们为敏捷软件开发建立起了价值观和基本原则。 关于本书 《程序员修炼之道》被一代代开发者奉为圭臬。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。 核心内容 需求不清，是程序员面临的真正挑战，高手程序员重新定义了交付软件的价值到底是什么。每次开发出来的软件交付给用户，它的价值不再只是把实现了某个功能的软件产品交付给用户，它更是探寻用户真实需求的催化剂。催化剂是什么，它虽然不是我们需要的结果，但它却是促成结果的关键要素。 点击查看大图，保存到手机，也可以分享到朋友圈 前言 你好，欢迎每天听本书，我是王木头。今天为你解读的这本书是《程序员修炼之道》。 你别被这个名字吓到了，程序员的修炼之道，名字听起来很玄，其实非常实用。这本书就是一个清单手册，有100条，每条都是一个实用原则。如果你去读的话，可能都不相信这是程序员写的书，字里行间透着幽默感。就比如其中一节的标题是“我的源码被猫吃了”，这不是告诉你程序员别养猫，猫会咬坏你的硬盘。这其实是说，如果某天你不小心把代码删掉了，别着急找借口，甩锅给自己的猫，而是要积极地寻找替代方案。这样的幽默感在书里面到处都是。 2020年4月这本书迭代了第二版，更新了很多内容。它的第一版是在20年前出版的，在这20年里面，全世界有很多程序员，都把这本书当作自己的进阶手册。这本书并不是一本程序员入门书，而是让一个程序员从菜鸟进阶成高手的书。 说到程序员，很多人可能会觉得程序员就是一群手艺人，不爱交流，就是闷头做自己的事。虽然看不懂他们在干吗，但是总能看到他们在学习，提高自己的手艺。 不只是普通读者，就连很多刚入行的程序员也都是这么认为的。他们认为程序员就是一个手艺人，只需要实打实地精进自己的手艺，让自己的程序运行得更快更好，更少出现bug，就一定可以成为程序员高手。他们认为程序员本质上和其他手艺人没有区别，就像是日本的寿司之神小野二郎一样，年复一年地精进自己的寿司手艺，最后就能成为顶级大师。 其实，程序员和手艺人还不一样，手艺人追求的是完美，他们会把经过自己手的创造物，不论是一个寿司，还是一把宝剑，或是一个机械零件，都要尽可能地做到完美。而程序员，更准确地说应该是软件工程师、“码农”，他们不像手艺人那样有强烈的理想主义，总是追求完美，相反地，他们是一群务实的高手。 通过后面的讲解你就会明白，在务实这件事上，软件工程师不只是有精湛的技艺，还有深刻的哲学思考。 这也是这本书的中文版副标题，为什么会叫“通向务实的最高境界”。 我这里说有哲学思考不是夸张啊。这本书的两位作者，分别是大卫·托马斯和安德鲁·亨特，他们在软件界可是非常有名的。他们是《敏捷软件开发宣言》17个创始人中的2位。什么是敏捷软件开发你先不用在意，你听到“宣言”先想到的是什么呢？《美国独立宣言》或是《世界人权宣言》，每一个宣言的背后都有着深刻的哲学思考。 《敏捷软件开发宣言》也经常被称为是《敏捷宣言》，它就是程序员务实哲学的集中体现，可以说是现在程序员高手的必修课了。你也别觉得《敏捷宣言》是一小撮程序员的自嗨，其实这个宣言里面的敏捷思想早就已经破圈了。 如果你在公司里面每天都开十几分钟的站立会议，或者总是从领导的嘴里听到要快速迭代，还或者一个产品还在创意阶段，负责人总是要求先把最小可行性产品做出来，这就说明你和你的团队已经被程序员的务实哲学深深地影响了。 如果用一句话来概括程序员心中的务实，那Facebook，也就是脸书贴在墙上的一句话最能代表程序员务实的价值观，那就是“完成大于完美”。 这本书里面，作者们也一直在强调这件事，不论是告诉读者们应该交付“够好即可的软件”，还是嘱咐读者说“你无法写出完美的软件”，其实都是在提醒程序员，放弃对完美的执念。对完美的执念，可能就是阻碍一个程序员从菜鸟走向高手的最大障碍。 为什么说对完美执着反而会成为程序员成长的障碍呢？接下来我就为你详细解读。 第一部分 我相信，当你第一次听到“完成大于完美”的时候，一定会很惊讶，放弃对完美的追求，这好像不是什么好事吧。如果是一个普通的互联网产品，软件不做到完美，可能就是用起来不方便，但是如果是银行的管理系统，或是航空调度系统，这要是不完美，那就会出大问题。这是对客户不负责啊。 不只是对客户不负责，也是对自己不负责。乔布斯不就要求自己的工程师，就算是客户看不到的内部电路板也必须设计得像艺术品一样吗。虽然这份执着，对客户、对功能没有真正的价值，客户可能根本不知道，但是自己知道啊，这么做是对自己的负责。 甚至你可能会想，“难道高手程序员要放弃追求完美，变成一个世俗的、没有原则的人吗？那样的话，我宁愿不做高手。” 你想错了，高手程序员放弃对完美的追求，不是不负责，反而是最负责的做法，不只是对自己负责，更是对客户负责。 我举个例子，17世纪的著名荷兰画家伦勃朗，有一副经典的画《夜巡》。这幅画可以说是艺术史上的精品，不过它却是一件非常失败的产品。 《夜巡》这幅画，本来是伦勃朗受到了阿姆斯特丹民兵队的委托，给民兵队成员们画肖像。伦勃朗也的确用自己的高超画技完成了这幅画，但是他的委托人们却非常不满意。因为支付了同样报酬的人，有的人在画里就非常不明显，甚至还被人挡住了脸。所以说，伦勃朗追求了画作本身的完美，却完全没有考虑客户的需求，这其实就是没有对客户负责。 然后客户就把伦勃朗告上了法庭，让他的声誉大跌。这也成了伦勃朗人生的转折点，后来他一步一步地走向了破产的边缘，临死的时候贫困潦倒，连一个像样的墓地都没有。这也可以说，伦勃朗为了追求完美没有做到对自己负责。 程序员之所以用不追求完美的方式对客户负责，就是因为在这件事上吃过太多的亏了。我自己就是软件工程专业毕业的，我记得非常清楚，当时学习的所有软件工程的教材里面，都会介绍一个软件项目的流程模型，瀑布模型。瀑布模型就是说，软件开发的过程，从需求分析开始，设计、开发、测试、部署每个过程都必须按照步骤一个结束了再进行下一个步骤，就像是瀑布一样，上游的工作完成了才能流到下游。 这个模型可以说是最有名的模型，但是也是最不实用的模型，20世纪80年代之后，这个模型就几乎不再被使用了。相反，后来所有的软件开发模型，都会把瀑布模型当作一个靶子，可以说都是针对它的问题进行的改进。 其实现在的软件开发，瀑布模型里面说的几个步骤也都需要，就比如需求分析，要想开发软件，那得先知道软件给谁用，实现什么功能，有什么性能要求等等。知道了这些，后面的设计开发才不会做无用功。万一需求没有搞明白，等设计开发完了才发现错了，到头还要重来，浪费时间精力。 所以，按照这个开发模型去做的话，程序员要想对客户负责，对自己负责，那么就必须把每个步骤都做到完美。需求完全搞清楚了，设计才不会出错，设计完美了，开发才可以有效率。如果任何一个步骤有一个小问题，那么在后续的过程中这个问题就会被放大，导致软件无法满足需求，甚至返工重做。 可是，没多久，程序员们就开始因为这个模型吃亏了。因为软件开发要做的事情发生了变化。在计算机刚开始商用的时候，软件开发要实现的产品，一般都是仓库管理系统、财务管理系统等等这样的商业项目。而且，当时主要做的也是把原来需要人在纸上做的事情搬到计算机上。所以，这个时候，程序员要是实现什么功能是很明确的，仓库管理、财务管理，业务流程等等都已经非常成熟了，程序员要做的就是把它们在软件上重做一遍。 但是，再往后就不是这样了，计算机不再是只满足商业需求，也就是2B业务，开始进入个人和家庭，也就是2C业务。尤其是当互联网发展起来之后，很多程序员要开发的软件需要满足的是个人需求。这里多说一下，软件的交付对象，在2B业务时一般称为客户，2C业务一般称为用户，后面更多的是在讲2C的业务软件，所以我就使用用户这个词了。 个人市场上的需求发展变化很快，按照原来的方法开发，需求分析、设计、开发等等一套流程下来，一两年过去了，个人市场的需求早就变了，做得再完美也已经过时了。更要命的是，软件用户自己都说不清楚自己需要什么。你可以想想，微信做出来之前，你会想到自己需要这么一个软件吗？是不是觉得短信和QQ完全就可以满足自己需求了？ 需求不清，这才是程序员面临的真正挑战，而他们的“务实”，就是在解决这个问题。怎么做呢？这其实也是《敏捷宣言》里提倡的一个核心，它重新定义了交付软件的价值到底是什么？每次开发出来的软件交付给用户，它的价值不再只是把实现了某个功能的软件产品交付给用户，它更是探寻用户真实需求的催化剂。催化剂是什么，它虽然不是我们需要的结果，但它却是促成结果的关键要素。 如果把软件的价值定义成交付给用户产品和功能，那么的确需要提供完美的产品，因为要对用户负责。但是，如果把软件看作是催化剂，看作是探寻真实需求的工具，那么追求完成而不是完美就会是一个更好的选择。 我想我们都有过这样的经历，和朋友们聚在一起，到了吃饭的时间，想约着一起去吃饭。可是到底去吃什么，大家都说不知道，一直僵持着。只要这个时候，有一个人提出“要不还是吃麦当劳吧”，局面马上就打开了。有人就会接话说，麦当劳距离太远了，还是附近的川菜更好，然后又有人说，最近就是想吃辣，最好还是肉多一点。于是很快就能定下来，去吃了火锅。 这里第一个人提出的麦当劳，就是那个不完美的产品，它的价值不是真的让人去吃麦当劳，而是给了所有人一个靶子，让人以它为基础，提出自己的需求。软件开发也一样，当面对的是一个不确定的市场时，越早喊出“麦当劳”，就可以越早地打破僵局，发现用户的真实需求。不论是不完美的软件，还是“麦当劳”，它们的价值，重点不在用户使用它们，而在于程序员可以通过它们发现真正需求。 很多人都听过，最小可行性产品，也就是MVP，这其实就是用产品当作催化剂的最佳实践之一。开发一个新产品时，不要只相信创始人的个人经验，也不要相信用户调研。有一个想法之后，要尽快把一个功能最精简、开发时间最短、成本最低的产品做出来，从真实的用户那里获得反馈。 当然，关于最小可行性产品的具体内容，可不是我这里说的这么简单，什么样的产品算是最小可行性产品，如何获得真实反馈，又如何从反馈中发掘真实需求，这是有一整套方法论的。这里推荐你去阅读得到电子书里的《精益创业》，我这里就不详细介绍了。 当了解了这些之后，我们回头再看“完成大于完美”这句话，为什么这句话是程序员务实的体现。因为它让程序员别把目标放在结果上，只想着结果要完美，更重要的是过程，别光想着要做什么，还要知道怎样才能做到。高手程序员，不是放弃了完美，而是用更快的速度更少的成本先完成，用真实的产品让用户反馈。 第二部分 当然了，要想成为一个高手程序员，可不是把思想转变一下，从原来的“追求完美”变成“完成大于完美”就可以了。通过前面的介绍，我想你应该也明白了，说是完成，其实只是实现最终目标的第一步。快速完成最小可行性产品，用它获得了真实反馈，然后呢？肯定还想需要持续地变更和持续地改善。每一次完成，其实都是实现最终目标的一小步。 那么问题来了，怎么才能做到持续变更、持续改善呢？这就是程序员务实的另一方面了。 在这本书里面，作者就强调了一个编写代码的核心原则——ETC原则，也就是Easier To Change的缩写，让变更更容易。可以这么说，所有的编程技巧本质上都是在实现ETC原则。 举个例子，对于程序员来说，普通台式电脑的硬件设计就符合ETC原则。如果内存不够了，可以打开机箱增加一个内存条，如果速度慢了拆下CPU换一个。也就是说，你的需求发生变化后，通过很少的变更就可以继续满足自己的需求，不用把整台电脑都换掉，那样成本会很高。相反地，现在的手机就不符合ETC原则，别说增加内存了，就是电池都不能随便换，如果你需求变了那就只能买新手机。 当然了，这里是用硬件来举例子，硬件更新周期长，不那么容易变更也是没有问题的。但是软件就不一样了，前面讲了程序员可不是做到“完成大于完美”就完了，最重要的是能持续改善。软件的持续改善，那很可能是上午发布的内容下午就有了反馈，就需要进行改善了。如果程序员写的代码不能应对这样的变更，每次都要把代码重新写一遍，那么成本可就太大了。 所以，别看前面说了，要先做一个最小可行性产品，要赶快投放市场获取真实反馈。这的确没错，但是这也只能说对了一半儿，还有另外一半也必须保证才行。那就是这个最小可行性产品的实现，要符合ETC原则，容易变更。 当你听别人说，他有一个绝好的想法，现在正在做最小可行性产品，很快就要上线投入市场了。你可别马上就认为他很了不起，他很务实。你一定还要去问问他，对于变更他还做了什么。如果他什么也没做，只是单纯地追求最小可行性产品，那么最后的成本反而会很高，甚至还不如最直接的做法，把所有功能做全了再上线。 其实ETC不只是实现持续改善的一个简单原则，它本身就是一个实现持续改善的解决方案。如果给程序员最深恶痛绝的事情排个序，需求变更绝对可以排在前三。这其实可以理解，假如说老师给你布置作业，说今天晚上要把《出师表》背下来，第二天检查。结果你晚上都快背完了，收到了老师发来的信息，说作业布置错了，明天不是考《出师表》，而是考《鸿门宴》。知道这个消息，你是不是也得崩溃。 程序员也一样，每当产品经理提出需求后，他们恨不得让产品经理签字画押，承诺一定不改需求了。可是，需求不是产品经理说了算的，真正决定需求的是用户。要想对用户负责，那就要允许需求变更。 在《敏捷宣言》提倡的价值观里面也有一条，响应变化高于遵循计划。其实这也是普通程序员和高手程序员的重要区别，只有先具有了灵活的意识，才能有灵活的解决方案。当一个程序员认为一个需求就应该是板上钉钉的时候，错误的种子就已经被埋下了。 一个高手程序员，面对需求变更，想到的不是让产品经理签字画押保证不变，而是利用ETC原则，让变更更容易，为变更做好准备。 就比如说吧，假如你去学习编程了，那么你一定会学到一个六字真言“高内聚，低耦合”。高内聚的意思就是说设计代码模块的时候，内部功能的聚合程度要尽可能地高，低耦合的意思是说模块和模块之间的耦合程度要尽可能地低。 形象点理解的话，你可以把程序的模块化想象成是给快递打包，要想打包得好，首先必须把快递盒子给塞满了，不能晃荡，这就是高内聚；然后还要把盒子封装好，多缠几圈胶带，不能让里面的东西漏出来，这就叫低耦合。快递漏出来了，最多就是丢东西，代码暴露出来了，影响的那可是模块和模块之间的调用。如果代码模块没有封装好，更新、更换起来就会特别麻烦。 实现了高内聚低耦合，就能保证代码模块有良好的设计。万一需求变更了，那就会出现两种情况：要么是代码模块本身可以不变，变的是模块互相之间的拼接，就像是乐高积木一样；要么是某个模块性能跟不上了，那只需要更新这个模块里面的程序，不会影响其他模块里的代码。前面讲的给台式电脑换CPU就有点这个意思。 不论需求是不是会发生变化，当一个程序员在按照高内聚低耦合编写自己程序的时候，其实就已经在为变更做准备了。 不只是高内聚低耦合，还有一个原则也是程序员实现软件要遵守的。这就是代码模块要尽可能地复用。比如说，你用一个代码模块实现了搜索功能，可以快速地把符合条件的内容找出来，那么不论是在做电子书内容的搜索，还是网页内容的搜索，就别再重新发明轮子了，需要搜索的时候调用同一段代码就可以了。 在应用复用原则的时候，普通人或是菜鸟程序员可能都会误解，感觉复用就是程序员的合理“偷懒”，已经有了的功能就不用再做。其实，对复用来说，节省成本只是附带结果，它更重要的功能是管理一致性。 什么意思呢，就拿前面搜索功能来说吧。如果这个功能没有被复用，而是程序员很“勤快”地把它复制了两份，一份用在了电子书搜索功能里面，一份用在了网页搜索功能里面。那要是遇到了变更，比如这个搜索模块的技术落后了，需要用更好的技术增加搜索速度，那最开始的“勤快”就会给变更带来麻烦，必须把两个复制的模块都做同样的修改才行。 而如果这部分代码是被复用的呢，就没有这个麻烦了，只需要一次修改，全部调用这个模块的代码都可以用到最新的搜索技术。而且这还不是麻烦不麻烦的问题，现在普普通通一个软件产品，都可能会有几十万行的代码，需要上百人的协作，如果没有把复用原则执行好，那么就是一个小更改都可能让整个产品出现bug，导致崩溃。 前面讲的这些方法，还都是程序员在编程技术上做出的应对。为了应对变更，程序员高手的方法，可不只是停留在技术层面，他们还会在组织团队和制定流程的层面上给出自己的解决方案。就比如，站立会议，这是在很多敏捷开发方法里都会用到的技术。 你别觉得站立会议只是把原来坐着开会变成了站着开会，其实这是用站立的方式倒逼缩短开会时间。因为坐着开会比较舒服，不自觉地就会拖延开会时间。保证每次站立会议不会超过15分钟，这样才能让站立会议成为每天的日常会议，每天十几分钟还是可以承受的。这样，团队里面的每个人每天都能和其他人做一次同步，知道其他人都做了什么，项目都发生过什么变化，自己是否需要做相应的调整。 还有看板方法，除了让编程这种看不见工作量的工作变得可见可衡量，它也是所有人同步进度的公告栏。有了看板就不需要刻意通知，团队里的每个人也都能知道项目的进展情况。 其实《敏捷宣言》就是程序员应对变更的指导方针。这个宣言不是我们这次解读的重点了，感兴趣的话，你可以自己去了解相关的内容。 总结 讲到这里，这次解读的核心内容就讲完了。通过前面程序员面对完美和变更的态度，我想你会和我一样有这样一个感觉，高手程序员，都是一群能给自己重新设计议题的人。他们本来是用编程的方法实现用户需求的一群技术人员，但是，他们并没有把自己限定在一个确定框架范围内去解决问题。当他们发现无法获得确定的需求时，不是要求用户或是产品经理必须把需求确定下来，而是跳出编程技术的框架。他们重新定义了产品的价值，产品不再是简单地给用户提供功能，而是变成了探寻用户需求的工具，在更高层上把解决问题掉。 面对持续改善问题时也一样，程序员也没有停留在原有的议题里面，想着怎么能减少变更，而是跳出了原有问题的框架，想着如何可以适应变更。为了做到适应变更，不只是在编程技术这一个层面给出了自己的解决方案，在团队建设和流程制定上也有自己的解决方案，甚至都总结出了相应的指导思想。 所以，如果让我说什么是程序员的务实，我会说，不是死磕、追求完美的精神，而是为了实现最终的目标，总能跳出框架为自己重新设计议题的能力。 撰稿、转述：王木头 脑图：刘艳 划重点 1. 高手程序员，不是放弃了完美，而是用更快的速度更少的成本先完成，用真实的产品让用户反馈。 2. 一个高手程序员，面对需求变更，想到的不是让产品经理签字画押保证不变，而是利用ETC原则，让变更更容易，为变更做好准备。