今天继续学习本书的提示6-8。还是先看提示：
提示六：做推动变革的催化剂
提示七：牢记全景
提示八：将质量要求视为需求问题
作者一开始用法国故事石头汤的例子说了万事开头难的道理，提示我们在推进项目遇到困难的时候可以先尝试做出点什么来。但接着作者又从反面村民的角度分析我们日常容易陷入俗事缠身的状态都是一件件小事累积造成的。接着作者通过温水煮青蛙的寓言告诫我们要牢记全景，不要只埋头于自己的一亩三分地。最后作者从一个完美控制质量的笑话入手，说明想要提升产品质量的难度。有时候过度重视质量也会导致一些不好的结果，这时候让用户参与决策，快速迭代才是更好的软件开发模式。这时候引出了提示八：将质量要求视为需求问题，需要去权衡利弊，既不能事前满目承诺，到时候删掉边角料来敷衍了事，也不要精益求精，一定要做到尽善尽美才把产品推向市场。知道什么时候适合停止，适当留白才能更好地前进。
石头汤的故事我早就听过，却没有认真思考过故事背后的深意，特别的是作者还能从反面村民的角度提出一些想法更让我耳目一新。我也试着从不同的角度去解读一下这个故事。有时候协作中我做一件事情会感到无从下手，还有一些情况下我会胸有成竹，认为自己已经找到完美的解决方案，压根不想浪费时间听别人的想法，可是如果开展一次头脑风暴，我总能从中获益良多，永远不要小看群体的力量。同时，就和培养一个习惯类似，一件事最开始的时候可能是最艰难的，一旦开始按部就班执行下去反而会容易许多，所以想要做什么事情就抓紧行动起来，哪怕先尝试一次，哪怕就五分钟。
温水煮青蛙的寓言相信大家都耳熟能详，有趣的是这仅仅只是寓言而已，有人真的去做了实验，发现现实中青蛙总能跳出锅去。但是生活中跳不出来的人们不知凡几，真正能毫不留恋迈出舒适圈的人又能有多少。回到代码中来，不要对一个个小问题熟视无睹，那些让人望而生畏的屎山都是从每次几行的修改累积而来。那我自己举例，遇到那种情况的罗列，经常习惯写一两个if了事，想着如果以后这块改复杂了，我就用XX模式来重写一下，可没有这么多如果，常见的是我自己又在别人的if下面继续写着if，想着反正这块代码都这样了，也不差我这几个if。如果从一开始就放眼未来，没有第一个if，或许情况就不会这样发展。
做够好的软件这块感觉作者表达的逻辑有点绕，我读了好几遍以后感觉作者就是表达质量问题也需要权衡利弊，并不是一定要做到完美无瑕的软件才是好的软件。有时候用户也不知道自己想要的是什么，但是尽快交付可用的产品，反复迭代，敏捷开发，智慧演进能帮助我们完成人月神话。记得有一次接口开发，调用了dmtp一个不成熟的接口，导致我调试两天却总是时好时坏，还被framework认为是网络问题，严重影响了我的开发进度。后来我花了10分钟去掉了dmtp的接口，改成直接调用用户的webService，就再也没有遇到过问题，虽然牺牲了dmtp提供的安全性，日志可视化服务，可是避免了继续在泥潭中挣扎。最后由于需求变更，这个接口也废弃了，庆幸没有花费更多的时间来研究这个问题。
尽信书则不如无书，作者提出的都是基于自己的理解，只有自己对每个问题都进行深入的思考，才能真正把书本的知识转化为自身的能力。更进一步，只有在工作生活中去进一步锻炼这种能力才能真正有所收获，期待自己能够真正学以致用！
网友评论