眼前有個包含多層bom的成品，怎么統(tǒng)計它需要（哪些，多少）原材料？

?

要解決這個問題，很喜歡自己掛在嘴邊的一句話：寫個遞歸有多難嘛？你寫就完事了。

遞歸函數(shù)可謂是面試題里的常客了，例如當年“請對列表進行求和（不能出現(xiàn)關(guān)鍵字：while、for）”之類的《最后一題》我直到現(xiàn)在還記得。

遞歸有多難呢？就看調(diào)試有多煩。

小弟看了直搖頭，不知道需要哪些參數(shù)，怎么接轉(zhuǎn)傳，只會自己調(diào)自己；

大哥一想也搖頭，再清楚需要哪些參數(shù)，怎么接轉(zhuǎn)傳，代碼沒法一遍過。

?

一般來說，遞歸函數(shù)需要關(guān)注的無非就是，一層過，兩層過，層層過，這3個階段。然而，現(xiàn)實情況是，往往錯的不是遞歸本身，而是其中的業(yè)務(wù)方法。而由于遞歸函數(shù)往往伴隨著上下文的傳遞，以至于單獨對特定實例業(yè)務(wù)方法的斷點行為缺乏意義，最終還得回歸遞歸方法本身，結(jié)合參數(shù)與實際業(yè)務(wù)一起考慮，那就討厭了。

?

舉個例子，如果所有原材料都有各自基于數(shù)量的階梯價格，而這個數(shù)量在遞歸函數(shù)中是通過自身物料明細的數(shù)量（3） 及 當時的上下文系數(shù)（2）來共同決定，那甚至哪里錯了都不能定位了。

成品=>半成品*2； 半成品=>原材料*3；

成品=>原材料*2*3；

?

某種程度來說，原材料價格表的方法最終會接到的這個數(shù)量6。如果與期望不符，它最好2*3中的3錯了-_-||（但愿吧，祈禱）

?

綜上所述，遞歸不是重點，調(diào)試才是。而且我不會為了調(diào)試而遞歸。我會為了面試而遞歸。

?

回歸正題（簡單問題），如果有這樣一個 包含多層bom的成品，我會姑且將它每一層的展開結(jié)果視為一個這缺那缺的扇形圖。那么基于每個bom節(jié)點的遞歸方法，無疑就是從最左至右進行掃描，將原來一個空有輪廓的扇形圖一筆一劃的填充而已。以我多年填充圖形的經(jīng)驗來看，在我畫完最后一根豎線的那一刻，我就畫完了。

?

等等，別忘了還要自測和調(diào)試。我可看不清每個節(jié)點跟其他節(jié)點的關(guān)聯(lián)關(guān)系，但起碼我能一眼看出這個復雜結(jié)構(gòu)到底有多少層。

如果可以豎著畫，那我就來試試橫著畫。

?

基于常識而言，我必須畫完倒數(shù)第二層才能花最后一層，推導回來，我必須先畫完第一層，才能去畫第二層。讓我們來看最后一層需要畫成什么樣吧。

如果我把最終的結(jié)果以 {原材料:數(shù)量} 的形式來定義（用來合并重復原材料所需要的數(shù)量），那它必然需要[(原材料/半成品，數(shù)量)]的支持（即便這個概念只在程序運行時有所體現(xiàn)）。推導回來，我們的第一層也需要以這樣的形式傳遞給第二層。

?

問題是，第一層既不是原材料，也不是半成品?。吭捳f回來，第一層不就是個點嗎，哪來的層？

現(xiàn)實邏輯告訴我，當老板/客戶需要的時候，它就是原材料/半成品，它就是一層。

因此，我們將從第一層的[(成品，1)]，慢慢推導至最后一層的[(原材料，數(shù)量)，(原材料，數(shù)量)]

?

說白了就是在while True里面通過bom進行數(shù)據(jù)映射（也方便卡斷點），僅此而已。寫過的都說好。好！

?

最后來歸納一下中心思想吧，關(guān)于遞歸

低情商：你寫的很好。

高情商：下次別寫了。