昨天上午，我在Twitter上提出了这么个问题：
有没有人写过关于恐惧+编程方面的文章？（这种害怕做出重要改变的思想如何使你成为一个更差的程序员？）
以及
我觉得在小心翼翼（优++）和恐惧（让你不敢去做一些必要工作）之间有一条重要的分界线。
然后各种有趣的讨论接踵而至。
我发现，当我们害怕担忧的时候，思想就会趋于保守，也不敢做任何改动，生怕有个万一。但是这会导致软件变得更糟！它实际上是另一种灾难。要是你害怕做出任何改变，那么你就不能改善软件，也做不了大型的代码清理工作。也许你甚至都不能利用你已经写好并经过测试的代码，因为你自己首先杯弓蛇影，害怕了！你会只想畏缩于此而不敢越雷池一步。
更好的工具&流程=>少一些恐惧
很多人都提到了工具和流程。
Kelsey:
我知道你谈论的应该是倾向于心理方面的因素，但是我相信早期的代码测试是非常重要的。
[……]强制监控、CI、canary 部署、chatops、dogfooding、selfserve info。
下面给出的一些工具和流程或许可以使得我们少一些忧虑：
版本控制意味着你可以无所畏惧地改动代码而不必担心回不到旧版本。这对于现在的我而言已经是必备工具了——我无法想像要是我在编程的时候没有版本控制的话，得有多惶恐。
很多人还提到测试也能增加一个人的信心。我就曾经读到过这样一本有关于测试的书，非常的好《Working Effectively with Legacy Code》，书中每一章的标题都是关于使用遗留代码的可怕和困难。（书中定义“遗留代码”为“没有测试过的代码”，以便有一种韵味）。例如，“在没有彻底了解代码之前我没法改动它。”“我怎么知道我没有破坏了某些东西？”“我时间不多，但是不得不硬着头皮改代码。”
下面这条来自Uncle Bob Martin，很好的阐述了这个概念。
即使有好的设计和W / O测试，你依然会害怕改变，然后这些代码就会渐渐地生锈腐烂。只有经过良好的测试，你也不害怕，才能好好地整理这些代码。
但是，测试和版本控制并不是我们唯一的工具！我们还可以建立
允许和鼓励破坏的QA环境 一次只允许改动一点点的部署 轻松恢复原部署的能力 职责就是详细测试软件的QA团队 要是程序出现异常能发你邮件的工具以及更多。
害怕责怪（以及无责任的事后检讨）
但是，工具和流程绝对不是唯一的方法。即使我拥有着令人惊叹的工具和QA系统、最好的部署工具以及经过完善测试的代码，我依然会犯错误，而且犯的错误往往相当危险。
Etsy、Google和Stripe（我工作的地方）都有无责任的事后检讨机制。这意味着，要是你做出的改动最终破坏了某些东西，但是其他人在谈论的时候只能关注你做的改变和事实现象，而不能责怪于你。（例如，“这个改动为什么会引发这个问题？”，而非“Julia是怎么搞的，破坏了xxx？”）
因为要是你只管一个劲地责怪别人破坏了某些东西，那会导致他们以后更加害怕做任何改动，然后最终只会给你一个糟糕的程序。
非理性忧虑
有的忧虑是非理性的，而且这还会传染。假设，你做了部署之后，有什么地方出错了，你找到了原因，并修复了问题，就不会有人责怪于你，那么是不是感觉以后面对部署也不怕不怕了？
但是遗憾的是，我们是人而非机器人，在做部署时，总是情不自禁地担忧紧张，然后直到一段时间运行正常，才会放下心头的大石。
关于这类的非理性忧虑还有很多，我就不一一赘述了。
写给自己的话
今年是我生命中第一次亲密接触大型的软件系统，有时候我真心特别忧虑和担心！马上就是新的一年了，希望明年我能越干越顺手，哦也=^_^=