南辕北辙，诬圣师心，背理害道，不可胜数
几年前，记不太清到底什么时候，老有人说，编程其实不难，难的是思想。当时就很不屑，成功后的人，总是那么浮夸。
编程难吗？这是一个很经典的问题，我给不出你想要的答案，建议可以去问”知乎“。今天在知乎上逛的时候，发现了一个讨论GPU和CPU的话题：为什么现在更多需要用的是 GPU 而不是 CPU，比如挖矿甚至破解密码？其中这句话挺有感触的：
至于如何将挖矿和破解密码这种事情分成小学生都能做的简单任务，就是程序员的工作了。所以以后谁再跟你说程序员的工作就是体力活，你可以直接抽他。
非计算机专业的人认为编程本身很难，TA们不了解，科班出生的人大多也认为编程本身很难，TA们了解。
真正进入编程世界的人，是不会认为编程本身难的，难的是模糊的需求，难的是解决问题的想法。这句话还是有些许道理的：编程其实不难，难的是思想。
如果你还认为编程难：
一是：你没有真正进入编程世界。
二是：你没有真正搞清楚需求（这个是真难）
三是：你在解决问题的时候，走偏了方向（这让问题本身更难，这是最可怕的）
最近做项目，没有拿到元信息，需求都是二手的，真正体会到了没有搞懂真正需求的难处。这个经历过的人，都明白。这里主要想说的是第三种。
EG1：总是在猜问题出现的可能原因，而没有先排除根本性原因：
产品入库的时候，如上图，6个必填字段都填写了，保存的时候，提示还有一个必填字段。由于库存模型继承了产品模型，有人的想法就是这个提示的必填字段是继承过来的，解决思路是去产品模型中找这个字段，结果是找不到，于是觉得OE 的inhert更神奇了。根本原因是在本模型中定义了这个提示字段，而且是必填的，而在界面上没有显示。
EG2：总是在猜问题出现的可能原因，没有绝对性的排除：
升级的时候报错：
File "/usr/lib/pymodules/python2.7/openerp/addons/base/ir/ir_model.py", line 865, in _get_id
raise ValueError('No such external ID currently defined in the system: %s.%s' % (module, xml_id))
ValueError: No such external ID currently defined in the system: jp.action_stock_invoice_onshipping
找到了原因name="%(action_stock_invoice_onshipping)d" 类似ref，找不到这个id,注释后还是不能升级
<!--<button name="%(action_stock_invoice_onshipping)d" string="Create Invoice/Refund" attrs="{'invisible': ['|','|',('state','<>','done'),('invoice_state','=','invoiced'),('invoice_state','=','none')]}" type="action" class="oe_highlight a6" groups="base.group_user"/>-->
<!--<button name="%(act_stock_return_picking)d" string="Reverse Transfer" states="done" type="action" groups="base.group_user"/>-->视图文件中定义的name找不到，注释也没有，
解决方案：删除而不是注释，OE在解析XML的时候，可能忽视了注释
小结：
本来是要解决问题的，结果把问题越搞越复杂。只是猜想，没有去验证，或者，没有根本性的验证，这一刻的你就是指针，轻易的指向了下一个你猜想的问题，轻易的指向了未知，未知产生恐惧。有些类是于汉语中的南辕北辙大概就是这样。
研究OE7.0 是一个很痛苦的过程，犯了上面的错误，更可怕了。
南辕北辙, 我认为是一种形式的X-Y Problem.更多X——Y Problem 可参考（http://coolshell.cn/articles/10804.html#more-10804）。