这段时间，一直很少有机会写写代码。因为项目的性质本来就不是垒代码，而是玩一些危险、刺激的动作。做个比喻吧，比如你有一个房子，很多项目的性质是给它加个阳台，或者做个屋顶绿化，再或者扩建一间之类的，我们不玩这个，没意思，我们玩的是：恩，看来一楼有根柱子是可以省掉的，我们把他拿掉吧~~~
好，拿掉了，预制板要塌下来了，旁边墙也要倒下来了 ---- 我的大量时间就花在了这上面， 寻找方案，讨论方案，选择方案，以保证其不塌不倒。
这种事情纠结啊，痛苦啊，有时候实在累了烦了，就写几行代码，fix几个bug，算是休息休息。
关于如何寻找方案，讨论方案，我也没啥没啥好的提议，这里有篇很不错的文章可以参考：Introduction to Decision Making Techniques
对于如何选择一个技术方案， 倒是有一些感受，我觉得可以从以下几个方面来考虑的：
1. 最终效果
采用这个方案最好能达到什么效果？ 那样的效果是可以接受的吗？
这一步的优先级比较高，不然你做了很多其他的研究，结果发现这条路就算走通了，也没有什么意义，那就太悲剧了。
2. 可行性
这个方案可行吗？技术上有没有什么risk或者roadblock。
这是非常困难的一步，为了省时间，你可能需要咨询一些人；为了搞清楚问题，你可能需要读很多资料与代码；为了确认，你可能需要做个prototype试一下....
3. 工作量
这个方案需要多大的工作量？ 会不会牵扯到下游代码的大规模改动？ 尤其在framework一级的修改，这点更要注意。
4. 可控性
这里的可控性，是指是否所有修改都可以由你们自己team完成? 有没有对其他team的dependency，如果有，要尽量避免 --- 当你依赖于其他team时，很多东西就不可控了，问题可能会拖得旷日持久。
5. 可靠性
这个修改可靠吗？ 会不会很容易被破坏？
或者要强制要求大家按照某种新定义规范来修改，用别人的时间和整个系统的丑陋来为你的愚蠢买单?
6. 全局性
你的设计符合全局的架构吗？你不会为了方便，搞个hard code，或者贴块补丁上去吧？
可以把各个方案和这6个因素做成一个表格，分析比较起来就会比较清晰。
这里几个关键词是写给自己记忆的：addin，translator，prompt string，applet extension, customize dialog...