也許有些人早就是這樣做了，也許有些人還在和我一樣，也許有些人認爲這樣挺好的，總之我認爲這是我要改進的地方。程序開發應首先統觀全局，然後再逐個深入。
舉例：要實現某一功能，在開發過程中，往往需要將功能分成多個模塊，每個模塊下有衆多子模塊，再拆分成多個相互配合函數，然後是子函數，嵌套函數等等。
這個設計過程中，有時候往往由於頭腦太過投入，而讓思維不斷的遞進深入到某一模塊下無法自拔。
而當真正開始編碼的時候，也是跟着思想走，首先完成最低層的函數，然後再逐步上推到頂層，然而當辛辛苦苦做到頂層後突然發現，自己當初在某處想得其實不夠全面。於是，前面的辛苦就算是白費了。雖然通過不屑的重構調整最終還是完成了，可是，最終的代碼已經被改得面目全非，不成人樣了。
這一開發過程可以用下面的圖示來形容：
我經常犯這樣的錯誤，甚至是自己在家裏做一些小實例程序的時候也是如此。這也反應了思維方式的一些缺陷。
在橫向實現的過程中，程序的設計及開發應當是對系統功能樹的橫向遍歷。同樣以上面的功能舉例，在完成所有模塊（模塊A、模塊B、模塊C）的設計前，不急於設計或是實現某一模塊的具體子函數或是子模塊。
這樣的好處是，當發現自己出現錯誤的時候，調整的幅度會是最小的。就像軟件開發過程中的瀑布式模型一樣一個階段一個階段的完成。
另外補充一點使用條件：以上開發方式，適用於對項目中所用到的技術或相關業務邏輯比較熟悉的情況。
如果一個開發這第一次接觸此類功能，對技術或業務邏輯不是很清楚。基本上無法做到合理的進行模塊拆分，也就不可能一個階段一個階段的進行了。
這個時候就要先做一些假設的模塊拆分方案，然後動手分塊做小實驗來驗證一下。
一個問題又出來了，如何才能確定自己對這個功能是否熟悉呢？
答案：個人經驗，我會問自己這樣一個問題：這個功能如果我來完成，你能夠多長時間實現它？如果回答不出來這個問題，那就是說裏面的東西我還有很多不熟悉的。
最後，還是希望如果那位GGJJ有好的見解或寶貴經驗能夠供小弟分享，不勝感激