從黑盒白盒看架構

        我也有時要進行編程，可是總以爲彆扭，彆扭在哪那？就是本身修改某個功能的時候，感受內心仍是比較踏實，由於有一個明確的目標，但當我去完整的作一個項目的時候，就感受本身像是在沙漠中努力前行同樣，作出來的東西沒有任何的規劃，不是實現不了，而是感受很費力，像是逆水行船，還不知道到底能怎樣。

      看編程的書，知道每一個軟件都是通過規劃後才作成的，也看了不少範例，感受人家作的是成竹在胸，那步怎麼走都想的很好，但當本身要作的時候，我就又像陷入了泥潭。怎麼走也吃力。學習了信息系統項目管理師教程，知道我應該把軟件分解，而後按分解的任務去作，一個任務一個任務的去作，這樣就好作多了，方向也很明確了。這個方法不錯，但老是掌握不了。根本就不知道怎樣分解任務。

      前兩天看了系統架構師高級培訓，學到了很多東西。裏邊給我最深印象的就是關於架構的理解。

作成什麼樣就是架構作好了那？這個問題想了好久，終於有所悟，不知道對與不對，但也是本身的一點點認識，若是想作架構，就必須掌握黑盒思想，實際上架構就是黑盒思想的具體實現。若是咱們進行詳細設計，咱們就必須掌握白盒思想，在這兩個思想的基礎上，咱們要提出本身的基礎服務概念，也就是咱們把那些常常用的功能，收集成基礎服務，這樣這些基礎服務就能夠支持白盒思想指導下的詳細設計了。到這裏我歸結成一句話，就是白盒思想和黑盒思想就是在編程中的實際的兩種思想。由於咱們知道基礎服務函數也是按照黑盒思想來設計的。。

想明白了上邊的問題，就看是否是在實際應用中有所收穫了。咱們編程的兩個思想，其實是微觀的兩個思想。

由於在宏觀上，咱們還有兩個東西就是，關於敏捷方式開發仍是瀑布模式開發，實際上，這個問題也是混合出現的，只有在瀑布模式和敏捷模式相互相成的狀況下，才能真正作到規避風險的同時提升效率。

在基礎服務提供的實際設計中，咱們應該考慮的就是維護，健壯，效益，等等內容，讓咱們在黑盒的思想產生的模塊內部，精巧的實現白盒的實現策略和方法，就能讓咱們的編程更加的穩定和容易維護，這個就是設計模式裏邊要解決的問題了。

不知道是否是理解的有誤差，歡迎你們指證和交流。我是但願進步的一我的。