我好像比较习惯于比同学们晚一天更新，不过因为年纪大了，就原谅自己吧 (不好意思，违背了原则4)。继续修炼，今天的三个主题是选择，还是选择和破窗。
第一个选择讲得是自主的选择，似乎没啥感觉，就说说第二个选择和破窗。
提供选择，别找借口。对于我们这样持续进化的产品来说，这是非常非常非常重要的特质。我们面临修改别人已有的代码的机会远大于从头构建一组新的代码。那么这就有了一个非常强有力而容易得到的借口叫 “原来就是这样的”，或者更猛一点的叫“xx年以前就是这样的”。诚然我们可以接受这样的事实，不过最好在后边加一句“我建议如何如何来改”，别小看这句话，这是有思考，有担当的行为。
此外我也想区分一下借口和“甩锅”的区别，借口是该我干的我没干好，寻求理解和安慰。甩锅是不该我干的我把他扔到该干的人那里去，所以甩锅的前提是界定边界，如果边界不清，锅是甩不出去的。界定清楚边界是始终都应该做的事。包括接口的双方，前后台交互，甚至系统的正确用法。
破窗也是我们面临很多的情况，通常自己刚写好的代码总不会觉得是破窗，看别人遗留的代码往往觉得哪里都是破窗。收拾破窗肯定是必要的，不过我们借用昨天急诊医生的思路理一理整理破窗的建议流程。
首先是发现，要有发现破窗的心，和看出破窗的能力，做到这一点已经成功了一半。
第二步要确认一下是不是破窗，复杂的遗留代码大部分有存在的必要，要确定你看破窗的眼光高于留下破窗人的精妙设计，确认了破窗当然也就有了修理的方案，这一步也至关重要，完成了这一步就成功了90%了，
最后一步就是多找几个人来确认破窗和修法，包括更资深或者交叉的开发人员，产品经理，QA，一起推进，完成最终的提升，这一步在我们开发过程中有一个简单的操作，叫报一个story，自然有其他开发同学，产品人员和QA来关注和确认。
虽然最后一步只占10%，但却直接决定了这个破窗要不要，能不能补。是不能跳过的一步。
