南轅北轍，誣聖師心，背理害道，不可勝數
幾年前，記不太清到底什麼時候，老有人說，編程其實不難，難的是思想。當時就很不屑，成功後的人，總是那麼浮誇。
編程難嗎？這是一個很經典的問題，我給不出你想要的答案，建議可以去問”知乎“。今天在知乎上逛的時候，發現了一個討論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）。